Hacker News Reader

> I wish there was more stuff like this out there about rust, something, anything to counter what feels like blind optimism and fanboy-ism for the language.

I use Rust and I also use C/C++ and other languages as appropriate for each situation.

The fanboyism is a huge turnoff for me, too. But the anti-Rust complaints are also getting old.

Really, I’m just getting tired of everything in software engineering being turned into a competition, as if we’re cheering for our chosen sports team and we can’t stand to see the other team win anything. So much online discussion is wasted on Intel vs AMD, Mac vs Linux vs Windows, Rust vs C/C++/Go, React vs Remix vs 10 other frameworks.

It’s getting really hard to extract actual useful info from these permanent debates when the fanboys from different sides pour in to compete.

The best resources I’ve found are from people who aren’t afraid to use multiple platforms and acknowledge that they all have pros and cons. If someone can’t describe something in terms of tradeoffs, they’re probably not trying to make an honest evaluation.

Very much agreed. It's not like the anti-Rust comments are much better. They're often quite biased in the other direction and rest upon arguments that boil down to "if you write C++ correctly, it's a very good language". But of course, Rust has flaws and design decisions that make it a poor fit for many people/usecases. Really I'd love it if people kept an open mind, did their research and tried to not let their biases rule their judgement.

All those arguments, as usual, also fail to discuss the existing ecosystems.

Sure one can somehow write Rust-CUDA but is going to have an uphill fight versus someone just crusing along focused on the actual problem, instead of building infrastructure.

That is just one example.

What weirds me out is to see your comment grayed out within minutes of posting. Have an upvote, it's a valid point you are making.

I survived USENET and Slashdot, and am the first generation out of a 40 years dictatorship, downvotes on Internet forums don't bother me.

Thanks for the upvote anyway.

Oh yeah that's a valid criticism. Same reason why I don't plan on writing a CRUD API in Rust. It's an uphill slog compared to Rails or Node.

I thought that's the one part that had a bunch of frameworks already made

> It’s getting really hard to extract actual useful info

The info is still there, you just need to use a different extraction technique.

Even so, “if a text wants to be understood, someone has to do the work, either the author or the reader”. Putting all the work on the reader is a turn-off.

I still learn a bit from those sorts of debates. But for me they're meaningless because what I need from a language has nothing to do with nerd debate hour. I need a job, so it has to be out there, not just in my city but small cities in case I move. Next I care about good tooling. Otherwise the only debate I feel strongly enough is static vs dynamic typing, and that's mostly because I don't think I'm a good enough programmer to build a 500KLOC+ application without compile time type guarantees. Give me a language with the above 3 things and I think we have a deal, and all of them are about making my life easier.

Most languages and ecosystems greatly benefit from network effects, I don't know how that will ever be different.

I love using Rust, but I also get a bit annoyed by the hype. It's absolutely true, for example, that there are highly useful programming patterns that are extremely difficult to express without tools like garbage collection -- including many classical ideas from functional programming. But Rust users sometimes give you the impression that wanting to write any code which doesn't fit the specific shape the borrow checker expects is morally wrong.

Does using Rc or Arc feel morally wrong?

Having shared mutable state, or doing bare pointer arithmetics is "morally wrong" in the sense that it's a constant source of bugs in production, sometimes dangerous. Any language that reminds you about that is doing a useful thing; C++ is very much capable of that, too.

Meh, bare pointer arithmetic (and shared mutability, for that matter) can be quite morally OK if it's properly isolated to a self-contained module, with detailed specifications on its behavior. That's why Rust has an `unsafe` facility. It's morally wrong to use it across modules (because it's obviously non-compositional), but that's not what Rust devs are doing. This is not C/C++.

And good OOP is exactly about encapsulating that mutable part.

It's a bit silly to say shared mutable state is morally wrong. Rust programs have shared mutable state in that indices often refer to mutable data, and Java programs allow more conventional shared mutability without memory unsafety.

Shared mutability can enable some bugs, like the existence of a CPU enables bugs, but that doesn't mean CPUs are morally wrong.

Raw shared mutability is a mine field the moment mutations that depend on the current state occur.

If incrementing doesn't always increment you are in for a bad time after all.

You are always going to have data that is shared and changes. Any non trivial system will. Rust just discourages the naive "just point to the heap" method that tends to work until it doesn't.

Except Rust can only help when the heap being pointed to isn't shared across processes, possiblity written in multiple languages, e.g. NUMA shared memory.

If you do a crazy enough thing it will break isn't material to my statement "naively accessing the heap as if that is thread safe is bad anyway".

>is morally wrong

That is the problem not just with Rust but with today's tech. There is moral story or ideology everywhere. My definition of "engineers" is basically trade offs. Unfortunately that doesn't seems to happen much in software. The Rust Evangelism Strike Force.

Huh? "Morally" here is just shorthand for "practically, as a rule of thumb, for most intents and purposes" - it is the opposite of "morally correct". There are solid technical reasons for these concerns although they're a bit tedious to describe in detail (which is why we resort to these rules of thumb); they're not arbitrary or "ideological".

>Huh? "Morally" here is just shorthand for "practically, as a rule of thumb, for most intents and purposes"

There was an era when any rust code that use Unsafe is considered "morally wrong" regardless of whatever technical reasons or personal preference.

The brouhaha about Rust Unsafe was about code that used it where it was not needed (because you could write safe code that would optimize to the same thing), or used it incorrectly (not marking code that was only conditionally "safe", thus exporting unsafety to "safe" code potentially across Rust modularity boundaries.) And the actual issues got resolved rather quickly.

This is my largest issue with Rust right now too. I’m happy to use it for personal projects on my own computer, but I don’t feel comfortable shipping a huge pile of code I don’t really understand onto someone else’s computer. I trust a self-contained standard library (like those distributed with Go and Python) much more than a patchwork of packages that depend on other packages, written by many different people, and which may be in different states of maintained, unmaintained, have security holes… putting my name on software based on these packages means taking responsibility for all that mess.

All valid concerns -- but you have to worry about bringing in other code in your supply chain in almost any language, unless you are always doing everything from scratch!

Thank goodness cargo audit (for https://crates.io/crates/cargo-audit) in any case.

> shipping a huge pile of code I don’t really understand

Isn't this right for any language, though?

Yes. One glance at Log4j fiasco shows no one really understood all of the code.

Log4j is not a standard library, it is just very popular, and it proves the original concern. It is treated as standard but it is not, and package muddle the waters even more. Remember leftPad.

The lack of a stable ABI is also a problem. For example, on my Linux distro, if a library has a bug, I just update the library and all software using it are fixed. No need to recompile everything.

So, essentially, the cargo system makes it easy to import weak code and hard to fix it later.

I am not saying that cargo is terrible, but it is a problem with rust that is not to be dismissed.

It still doesn't negate my point.

You need to rely on other people's code. Whether it std lib or not. Left pad is because of:

A) ease of modularization

B) problems with tree shaking

C) people want small easily understandable library

Which tbh works more often than not.

----

Stable ABI is a curse as much as blessing. Once you have stable ABI, you will never want to break it. Even if breaking ABI would be beneficial long term. See

https://cor3ntin.github.io/posts/abi/

And if you desire Stable ABI there is option of exposing C API in Rust.

----

> So, essentially, the cargo system makes it easy to import weak code and hard to fix it later.

Hard for who? Cargo can easily fork a package and recompile it. It makes it harder for distros. But you can ship static linked dependencies, easily.

You’ll find that a lot of software that runs large, enterprise applications is comprised of “pet projects.” Node.js and Python both started as pet projects.

If your criticism is that there isn’t a lot of maturity in the ecosystem, then I would agree. The author also makes this point.

There will always be something the industry is excited about. Rust will eventually find its place and its hype will be eclipsed by whatever new trend/language is cool 4-7 years from now.

If you come at it from c/c++ systems programming and you never even had a decent package management story then of course Rust will be a blessing.

Those that will be confused and wonder what the hell it’s about is those who come from node/go/Java and think that using http is a “hello world” example of what Rust should do with ease.

> I also dont know why npm and node get so much shit for needing so many libraries but rust and cargo get a pass for these small libraries everywhere.

I think one big difference is the less promiscuous (but more frustrating) dependency management. In node I end up with 15 versions of a popular “should have been stdlib” library. In Rust you usually just have to allow one. So the libraries that form core functionality tend to be conservative about changes and get absorbed into std.

Js obviously doesn’t add things to the core platform very quickly.

Why not write a singleton in rust? You can write a lazy global for that. The language does not prevent you from writing anything sane

The state of the ecosystem is concerning, but natural. It always takes some time until the best/standard libraries become visible amongst the noise. Lastly, I was looking for Parser combinators and the first three hits and no commits for years. That's definitely a red flag for me.

What did you get stuck on?

> I also dont know why npm and node get so much shit for needing so many libraries but rust and cargo get a pass for these small libraries everywhere.

Because cargo is a better package manager in every aspect.

Because Rust is a `cargo` cult. /s

[Ice Cube voice]: Started off with too much cargo, dropped 4 letters now I'm making all the dough.

> Because cargo is a better package manager in every aspect.

A piece of software can only help with some of the less important questions when you're working with many dependencies.

It handles the insanely tedious parts of package management like version mismatch.

It doesn't handle the issue that every tiny piece of functionality is a crate, because everyone wants to have one on their CV.

Also there are no namespaces and integration with other languages boils down to writing our own build.rs scripts.

I'm no node developer, but even with ~100 packages in a Python project it was really rare to see "version mismatch problems". There's probably a lot of talk about it because "just install newest spec'd version recursively" is not technically correct and can violate package version constraints, and it's also probably the only algorithmic thing you can put in a package manager, and optimal solutions are of course NP-hard, making it an interesting thing to work on. But practical impact? Far down the list.

I have definitely run into these problem with much smaller projects in both python and js.

I literally just downloaded a Python program that didn't run because I had the wrong version

In Rust, when you compile an earlier edition with the newer compiler it actually works

> Because cargo is a better package manager in every aspect.

It is not. For example, cargo doesn't have namespacing, which makes the issue of name squatting worse. I'd like to have every crate of the tokio-rs organization on Github (https://github.com/tokio-rs) under a @tokio/ namespace or something like that. npm allows that.

Dismissive responses like that are part of why people talk about "blind optimism and fanboy-ism".

I'd love to see that happen, but as I understand it, that's a decision for the crates.io registry. Cargo itself doesn't deal with those types of details and you could host a custom registry that does have namespaces.

You are confusing cargo and crates. Also this was a conscious decision.

The "dependencies" can be written off quickly as the "complaints" about them are ridiculous.