Mostly yes and good.
One thing I don't appreciate is nonorthogonality of certain uses and control structures that cannot be refactored into a function despite structural equivalence without introducing a multiple borrow conflict.
Was Rust Worth It?
71–80 of 736 posts
Re: Was Rust Worth It?
#72Do you need memory safety? Then why use Rust when you could use Java, JS, Python, etc? You can't "disable" memory safety in those languages. Do you need bare metal performance? Then why use Rust when you could use C or C++, which have much larger ecosystems, platform support, more mature tooling, etc. Do you need BOTH memory safety and baremetal performance at the same time? Then there really aren't many other option…
> Do you need memory safety?
I think that’s an unusual way frame that requirement.
All programs need to handle memory _correctly_. Very few seg fault as part of expected operation.
Re: Was Rust Worth It?
#73"Rust screams at you all day, every day, often about things that you would have considered perfectly normal in another life."
A good C compiler does this when you turn on all the flags. I like languages/compilers that let you selectively disable the screaming and let you write bad code on purpose. Bad code that works but can be written fast is often better than perfect code that takes forever to write. Once you have a bad but working POC, you can make it less bad.
"It’s got no problem attracting new users, but it’s not resulting in dramatically improved libraries or tools. It’s resulting in one-off forks that handle specific use cases."
Age has nothing to do with that. Attracting core devs is hard, and putting lots of effort into making it attractive is necessary. On top of that, cultural conventions are set by the early adopters, and a lack of convention is often just as sinful as a bad existing convention.
Take Python for example. They took a lackadaisical approach to development and runtime environments, and as a result there's 50 competing ways to develop or run a Python program. Their most-used package repository, PyPI, has been a mess for years. Nobody builds on top of existing packages, names make as much sense as a random word generator, the ecosystem is rife with malware, you can't even search for a package on the command line, etc etc. None of that is the language's fault, it's the community and core team's fault for sitting on the sidelines rather than leading. Culture matters more than the tech it's centered around.
(I'm not trying to pick on them, I just know their problems better. C has been around for a half century and its community never really put together half the solutions more modern languages did)
Re: Was Rust Worth It?
#74Perhaps my biggest critique is that crates.io has no namespacing. Anyone can just claim a global and generic package name and we mostly have to deal with it (unless you avoid using the crates.io repository, but then you'll probably have more problems...). Some of these globally-claimed generic packages are not really the best package to use. Maybe it was a reaction against the Java-style reverse DNS notation, which i…
This is a common critique, and although I don't have insight into why the original decision to not have namespaces was made, the current outlook is that until issues related to continuity are resolved, it's a no go: https://samsieber.tech/posts/2020/09/registry-structure-infl...
That article starts with the premise that “it’s a feature, not a bug” then goes on to describe a whole bunch of things I consider to be anti-features of a packaging system that has a flat namespace.
The first section says it discourages forking. I consider this to be bad. Nobody’s code should be more important purely because it squatted a better name.
The Identity section actually makes the case that flat registries make naming harder.
The section on Continuity is “we’ve tried nothing and we’re all out of ideas”. Make up an org name and grandfather all packages in the flat namespace into that special org. Also this is already a problem because packages in the flat namespace do get abandoned, then forked, and then we have the associated issues.
The section on Stability seems to take it as a given that crates.io should be the only registry. I don’t. It also seems to conflate cargo with rustc for the benefit of the argument.
The squatting section describes only anti-features and I don’t consider the author’s legitimate use cases to be legitimate reasons to squat.
I think the only legitimate problems that need addressing are the ergonomics of accessing namespaced packages throughout transient dependencies and backwards compatibility with non-namespaced code. But the fact that these are real problems does not, to me, make a flat namespace a “feature”. It’s just easier to implement.
It’s okay for it to be a mistake that takes effort and time to fix.
Re: Was Rust Worth It?
#75"Programming in Rust is like being in an emotionally abusive relationship. Rust screams at you all day, every day, often about things that you would have considered perfectly normal in another life. Eventually, you get used to the tantrums. They become routine. You learn to walk the tightrope to avoid triggering the compiler’s temper. And just like in real life, those behavior changes stick with you forever." This is…
Yeah, blaiming the compiler for pointing out potential runtime bugs is just shooting the messenger.
Re: Was Rust Worth It?
#76As an outsider, I often hear about async Rust being less than ideal. Perhaps I don't understand, because I haven't dipped my toes in the water yet... but I do most of my work in Kotlin with Coroutines, and concurrency is everywhere in the UI. I can't imagine working in a language having a major deficit in this space. Are there any efforts to overhaul or completely rethink this?
It’s pretty much the same issue all languages have, that async functions are colored. I don’t think it is unique to rust. Algebraic effects would solve this, but I don’t know any language other than OCaml that is working on that approach.
Can't scala, haskell, (kotlin?) you just lift functions into Async?
You can convert colors simply but only one way, and practically that works, functional core imperative shell, etc.
Re: Was Rust Worth It?
#77Earlier quoted context omitted.
It's a bit of an oversimplification, but a little quip I've used when talking about developing in Rust vs. other languages is, it's a question of where/when do you want the pain. In Rust, it's at development time (and hiring and ramp-up time); in C++ it's at runtime; and with GC languages it's at billing time when you have to pay for that extra compute and RAM. There's no way to get rid of the pain entirely.
if it were that simple, I'd take the "billing time" payment every time. Engineers' time is the greatest cost for just about any tech business
Sometimes billing time is your customer's patience, their phone battery, or other things like that which make your product worse and give your competitors an edge.
Re: Was Rust Worth It?
#78> It also looks like (soon) you’ll finally be able to configure global lints for a project. Until now, you had to hack your solution to keep lints consistent for projects.
> I questioned my sanity every time I circled back around to the Clippy issue above. Surely, I was wrong. There must be a configuration I missed. I couldn’t believe it. I still can’t. Surely there must be a way to configure lints globally. I quadruple-checked when I wrote this to make sure I wasn’t delusional.
You create a .cargo/config.toml in the workspace root so it covers all your crates.
inside the file:
[build]
rustflags = ["-Wclippy::lint_name_to_warn", "-Dclippy::lint_name_to_deny"]
Re: Was Rust Worth It?
#79Programming in Rust is really not like being in an abusive relationship. The compiler is trying to help out as much as possible, especially since rustc has the best error messages in the world.
Re: Was Rust Worth It?
#80Do you need memory safety? Then why use Rust when you could use Java, JS, Python, etc? You can't "disable" memory safety in those languages. Do you need bare metal performance? Then why use Rust when you could use C or C++, which have much larger ecosystems, platform support, more mature tooling, etc. Do you need BOTH memory safety and baremetal performance at the same time? Then there really aren't many other option…
If you're remotely sane, you'll always want memory safety. That's not really an optional property, because even in C/C++ compromising memory safety throws you straight into the land of nasal demons. The question is whether you want the compiler to ensure memory safety, or to do it completely on your own without language support.
Personally, I've never met anyone who can ensure memory safety in their C/C++ without onerous restrictions even more severe than those rust imposes, but maybe you're superhuman.