pkolaczk

There is a huge semantic difference between sharing an object by providing a reference to it, passing the ownership of the object and passing a copy. It’s not a technical low level detail because the results can differ. Many developers use those distinctions in Rust to encode business rules, not to optimize memory use.

Similarly there is an important semantic difference between something you can change and something you shouldn’t change. Again - this can be used to express business logic constraints, similarly to how you can use static types to enforce other properties like e.g. „age must be a number”.

While you may say you can get away with just sharing references everywhere like Java or JS do, and not care about immutability, that’s like saying the only type you need is string and hashmap and you can code everything. And you just document in comments when strings contain numbers. I saw code like that in PHP once. Fun.

As a heavy user of Java I can assure you that Java is very very far from boring, especially when building it with maven or gradle. There are millions ways something can screw up the build. Rust (and Go too) in comparison is much more boring actually - it maybe I was just lucky, but the majority of stuff just builds with zero issues.

Especially the number of times I had to clean all the caches in order for maven and gradle to build the project is just far too high for me. It shouldn’t ever be needed if an ecosystem is meant to be considered boring. I feel like Java doesn’t build when I look at it wrong.

Only if you ever deal with one future at a time. But async allows things like awaiting one of N events in a very natural way. Those patterns are much less readable when done with threads.

That code was optimized for performance for 1980s hardware. It’s very far from optimized for modern CPUs.

Threads are neither better or worse than async+callbacks. They are different. There are problems which map nicely to threads and there are problems which are much nicer to express with async.

Rust (and Scala) type systems are somewhat stronger and more expressive in some areas than Haskell. Weaker in some other. But it’s not a clear cut that Haskell type system offers more safety guarantees.

Java escape analysis is very weak, much weaker than what stack allocation and moving allows in languages like C, C++, Rust.

They do work for me either, but I have learned to double check the locations of POIs with Google Maps to make sure I’ll arrive at the correct place.

The interface and the direction instructions on Apple Maps are way ahead of Google Maps. The app performance is also much smoother / snappier, it connects to the car instantly and reliably, where with Android Auto it’been always waiting and pain. But the accuracy of maps is indeed worse.

However my biggest gripe with Apple Maps in Poland is that Siri does not understand Polish and cannot be told to navigate to a Polish address. It just can’t understand the street and city names :(

Btw: I haven’t counted the times Google Maps wanted me to go through the worst possible traffic jam (where the traffic jam was not visible on the map) or a closed road. I guess it just happens with every navigation system that errors happen.

It still is an unbelievable memory hog. It got faster though.

What do you mean it would destroy the valuable part of the signal?

If the signal has a carrier (like in AM or FM) or some other regular pattern (e.g. digital signal) then the typical the way to recover it from under the noise floor is to use a narrow-band PLL.

I’m experimenting with it right now and just found that a quartz/ceramic oscillator pulled by a varicap controlled by a PLL gives pretty good results - low phase noise, good noise rejection and ability to recover the carrier from a very noisy signal. But for that to work, the signal has to be shifted to a constant frequency through heterodyning first.

That’s why you probably want to use it in an oscillator rather than a filter. Then some of those problems go away. Although, some new ones appear like having to add a mixer … Some time ago I thought making a double superhet would be too complex but apparently it turned out quite a nice DYI project.