My condolences, haha (I'm honestly not a big Java lover ^^).
The curse of OOP (java style...).
I mean why do you need to write getter and setter methods. I have wondered at the beginning of university 10 years ago, and am still wondering why you would need something like that...
lack of btrfs support was disappointing
NixOS supports Btrfs
AFAIK NixOS supports every filesystem, that other linux distros support, and often with easier/better configuration, e.g. I'm using ZFS, which seems to be easier to setup on NixOS than on most other distros.
I have hopped rather rarely. I think my journey started with Debian -> (all kinds of flavors of) Ubuntu -> Arch -> NixOS.
Maybe I missed a few (started with linux at probably ~2005). I've stayed on each of these for a few years, I think I switched between Ubuntu flavors a little bit more frequently. Stayed on Arch the longest for ~7 years. And I think I have basically settled now since 3 1/2 years on NixOS without plan to hop any further distros (unless there comes a distro comparable to NixOS that has less quirks and is generally nicer to use (e.g. tooling, strong, strict static typing etc.)).
NixOS is quite different than other distros (which IMO are all very similar) but does package-management+system-configuration basically how it should be done (in hindsight). It's a rather steep learning curve in the beginning, but it only gets better over time, since your system continuously improves, compared to different distros that accumulate dirty state over time and in one way or the other break after some time. This was often the reason why I hopped on a different distro, since I wanted a clean fresh install, which I get with something like Impermanence+tmpfs on root after each reboot.
It could definitely use integration with a linter so it doesn’t generate subtle bugs around generative naming mismatching actual methods/variables, but it’s become remarkably good, particularly in the past few weeks.
Maybe I should try it again, I doubt thought that it really helps me, I'm a fast typer, and I don't like to be interrupted by something wrong all the time (or not really useful) when I have a creative phase (a good LSP like rust-analyzer seems to be a sweet spot I think). And something like copilot seems to just confuse me all the time, either by showing plain wrong stuff, or something like: what does it want? ahh makes sense -> why this way, that way is better (then writing instead how I would've done it), so I'll just skip that part for more complex stuff at least.
But it would be interesting how it may look like with code that's a little bit less exotic/living on the edge of the language. Like typical frontend or backend stuff.
In what context are you using it, that it provides good results?
I would actually encourage it to be extremely verbose with comments
Yeah I don't know, I'm not writing the code to feed it to an LLM, I like to write it for humans, with good function doc (for humans), I hope that an LLM is smart enough at some day to get the context. And that may be soon enough, but til then, I don't see a real benefit of LLMs for code (other than (imprecise) boilerplate generators).
Yeah my thinking as well.
Addtionally, why I think other system language competitors like Zig or Nim aren't succeeding long-term, is because of fast growth and already big ecosystem of Rust. Zig may be better though for some use-cases (when you want to avoid all the mental overhead, and the application stays simple).
Just learn whatever you currently need. If you know a few paradigms, learning a new language of the same paradigm is easy-peasy and can be done rather quickly (well at least being be productive with it, doing stuff idiomatically often takes a little bit longer).
That said, Rust IMO is a language that makes sense to learn anyway, since it also teaches you to program in a nicer way (not just true for Rust, there are other languages that have this effect as well, such as Haskell etc. generally languages that introduce something really new (i.e. a new paradigm)). Generally it makes sense to learn multiple languages, as each brings you new ideas. But on the other hand it makes sense to learn one language really well (I'd recommend that being Rust, as it can cover so many use-cases and is generally designed nicely (it fills a sweet spot between mutability and functional programming IMHO).
I don't understand...? I think I never explicitly run a method/function that is called copy (there isn't at least not for the trait Copy
)
Do you have equivalent experience in both? I consider myself being faster in Rust nowadays than in Typescript (most likely because of the good tooling and the nice composable way the language is built.) But it probably depends on the type of the task I guess (e.g. if good libraries are available). But this stands obviously only in backend, writing UI as fast as with React or Solidjs or Svelte or vue or whatever (damn there are just too many frontend frameworks...) is certainly faster in Typescript.
I think the key is finding companies that are inherently technical (e.g. the CEO is a rockstar dev). I think if I see good code I do not care so much about how humble the developer is, I see it in the form of beautiful code.
It's more than just being Rust memory safe, the whole language just feels more I don't know how to phrase that... well/better-designed.
Regarding predictability, what do you mean with it? Regarding performance (memory and cpu) Rust easily wins because of the lack of GC and the power of the ownership system (RAII).
If you mean with predictability "not changing so fast". I think Rust has slowly reached maturity and the current focus lies on increasing the ergonomics of the current features. The major upgrades (switches between editions) are also absolutely painless IMHO, I never had any issues with it. The current trend (see SO survey) also shows that Rust will likely be a good long-term investment for a company (it's still the most loved and fastest growing major language).
I'm totally aware of the benefits of encapsulation, but the way java does it seems so unnecessarily boilerplatey (C# is better, functional programming makes encapsulation even simpler, but that's a different paradigm...)
I like how Rust approaches this via the module system and crates (you have
pub
for the public interface,pub(crate)
for crate/lib wide access and no modifier for being only allowed to access in the current module and submodules of that module)