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.
"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."
Yes - of course there is!
You're totally right!
But that semantic difference does not exist in most languages.
For good reason.
That 'semantic difference' only matters in a specific context - wherein you need to have the difference, usually for performance reasons.
There's no need to expose that semantic difference in the surface language, in most cases.
And that 'semantic difference' requires an enormous amount of thinking to process across the system. It's a huge amount of possibly unnecessary work.
Making the AI have to deal with that layer of design concern is a big cost you only want to deal with if it's worth paying the price.
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.
> I feel like Java doesn’t build when I look at it wrong.
Hah, too true! I guess it is boring in the fact that it is not as... move fast and break things... as NPM. But Java build systems are still certainly fun and challenging in their own ways.
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.
Threads offer concurrent execution, async (futures) offer concurrent waiting. Loosely speaking, threads make sense for CPU bound problems, while async makes sense for IO bound problems.
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.
Because if you go down the callstack eventually you won't get the await keyword anymore; you'll get the actual 'waiters' and 'wakers' which define your scheduling
The entire premise of callbacks is that threads were a mistake because they broke sequential reasoning and control.
JK, obviously callbacks became prominent as a result of folks looking for creative solutions to the C10K[0] problem, but threads have a long history of haters[1][2][3].
Async/await implementations usually also come with a runtime to handle the work scheduling as well as manage thread context. You can say that you can do that with just threads and callbacks but that's also essentially implementing async/await.
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.
> But it’s not a clear cut that Haskell type system offers more safety guarantees.
You can log operands in your implementation of Rust's Add trait, or compute running sum of one of the operands. In Haskell it is not possible unless you use unsafePerformIO from System.IO.Unsafe.
Haskell's type system controls effects available to the code. This can be used to implement programs adhering to specific formulas of Linear Temporal Logic or implementing a protocol specification, where operations on any given phase and side are restricted by type system.
I used Haskell's type system to prevent crossing of clock domains in the hardware description eDSL. Also, it was of great help in the CPU simulator description, fixing available commands and resources for different CPU models.
Even the logic of Rust's borrow checker was expressible in Haskell as early as February 2009 - there was HList, there was ParameterizedMonad and that's about what one needs for implementation of borrow checker.
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.
I have my iPhone set up in a way where I have "Apple Intelligence" and that, somehow, manages to pick up Polish VERY well. Might want to try it. Never have expected "play "Oddałbym" by Slums Attack from Spotify" to work - and yet it did first try, way better than any attempt I made on Google Assistant in the past decade.
The pronounciations, though, are indeed something that leaves no other option but to laugh. Expect "Rogozińska" (ruh-goh-tzeen-ska?), recieve something I fail to comprehend :-)
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.
Yes, varicaps are good and there are even varicaps with very large capacitance swings exactly for this purpose.
But it does require a very steady voltage and many more parts than just a single passive to not accidentally load the resonant circuit to the point that it becomes ineffective. You need to de-couple considerably to make this work, especially without injecting (phase) noise. And frequency stability and phase noise can be extremely annoying in particular applications.
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.
One of the problems I'm struggling with is that I'm trying to recover a signal with a known pattern from under the noise floor and every little bit helps. Varicaps will come into play once there is enough signal that the thermal noise and power supply influence would no longer drown out the signal. Interesting project but it is one of those where when you start you think 'how hard could this be?' only to find out that it is in fact pretty hard. We'll see if I can pull this off or not, I give it 10% chance at the moment.
Oh, and superhet wouldn't work, that would destroy the valuable part of the signal.
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.
The exact phase of the input is what I'm after. Using a LO would cause you to read the mixture of the LO and the input signal rather than just the input signal, and that means that you will never see the phase with the same precision as if you were to observe it directly because the two will have slightly different frequencies.
If you were to put both on a scope in XY mode you'd see the phase change directly over time.
But I like your two step approach, use the het to get close and then lock on to the phase.
So far I've not been successful without first bringing the signal up to the point where I can do it directly and then I don't need to add the complication of a PLL.
Injecting various levels of noise into the signal is a good test to see if the system would still work in less than ideal conditions and so far the answer is a hard 'no', it may well be that I'm past my level of competence on this but it's only been a couple of weeks so I will keep trying.
One possible approach is just to use a flash AD and move the whole thing into the digital domain. That has a bunch of other advantages as well, the signal is not particularly high frequency so that should be possible without breaking the bank.
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.