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.
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.
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.
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.
If you can afford losing a bit of frequency stability, you can use a varicap instead and control it by voltage. Precise multiturn potentiometers are much cheaper. Or just buy a programmable clock signal generator based on PLL and then make it into a superhet (you can still have analog filtering and detection, but digital frequency synthesis so it can look more like a modern radio with frequency display).
There are so many options and all are very cool to explore.
> Which is why when folks nowadays say "you cannot use XYZ for embedded", given what most embedded systems look like, and what many of us used to code on 8 and 16 bit home computers, I can only assert they have no idea how powerful modern embedded systems have become.
Yet, I still need to wait about 1 second (!) after each key press when buying a parking ticket and the machine wants me to enter my license plate number. The latency is so huge I initially thought the machine was broken. I guess it’s not the chip problem but terrible programming due to developers thinking they don’t need to care about performance because their chip runs in megahertz.
I’ve had that bug a few times. I think it’s related to some roads being closed and/ or under reconstruction. I’ve seen this happen multiple times on the same route, and it always fixed itself after I passed the construction site.
Technically it's not a pause as the pauses introduced by a typical STW tracing GC. It does not stop the other threads. The app can still continue to work during that cleanup.
And it pops up in the profiler immediately with a nice stack trace showing where it rooted from. Then you fix it by e.g. moving cleanup to background to unlock this thread, not cleaning it at all (e.g. if the process dies anyway soon), or just remodel the data structure to not have so many tiny objects, etc.
Essentially this is exactly "way more deterministic and easier to understand and model". No-one said it is free from performance traps.
> And free itself can be expensive.
The total amortized cost of malloc/free is usually much lower than the total cost of tracing; unless you give tracing GC a horrendous amount of additional memory (> 10x of resident live set).
malloc/free are especially efficient when they are used for managing bigger objects. But even with tiny allocations like 8 bytes size (which are rarely kept on heap) I found modern allocators like mimalloc or jemalloc easily outperformed modern GCs of Java (in terms of CPU cycles spent, not wall clock).
We don’t need it in Poland. We’ve been using a similar but official government issued app with ID, driving license, car documents for years now. Works both on Android and iPhone. Can be also used for logging into government web apps like taxes, for document signing or for voting. And it reminds me whenever my car insurance expires or it needs the annual check. Pretty impressive IMHO.
Oh, thanks, good to know. Now I feel more motivated. Because actually it’s not as easy as it looks from the text books. It’s like with drawing an owl. Yeah, pass the signal through a mixer and feed recovered carrier to its LO port and you’re done. Sure. Simple. Now just recover the carrier. So far I have built a PLL that locks to a clean signal but stops locking when the signal is modulated too much. Aargh.
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.