These Rust discussions typically contain grains of truth wrapped into exaggerations while downplaying or ignoring the two big issues of Rust, which are complexity and out of control dependency trees.
For the first issue of complexity, the reply is along the lines of show me the code and then either nitpicking that to pieces or explaining in several paragraphs how the behavior is perfectly reasonable and in fact quite easy to understand. Beginners get intimidated, professionals don’t have time to write novels on HN.
Complexity in Rust is systemic. It’s little things accumulating and amplifying each-other that add up to having to spend significant time just designing types to satisfy the static analyzer. Many Rust programmers seem to see the type system as a hammer to be used liberally, an predilection also known in the C++ metaprogramming community.
On the second topic (also present in this thread) the counter-argument is that other languages do it too and nothing bad happened so far. The former is not valid, because Rust is uniquely bad in its competitor group and security by waiting is not a valued approach.
I would argue that what you call complexity here is better referred to as explicit or visible complexity, as compared to hidden or implicit commplexity. The complexity as such comes with the domain and its application; but with Rust you can see it and you are forced to deal. With C++ you can get away with pretending that it is in fact not there.
This is honestly not intended to pick on C++ as a Rust fanboy, however. It really isn't.
For instance, to be a little unpolished, I would shrug off the unwrap incident as doing it the C++ way and pretending that the complexity does not need to be solved right then and there because ItShouldNotHappen or IKnowWhatIAmDoing.
I prefer Rust over C++, but I do not hate C++. This isn't even about C++ anyway.
When it comes to out of control dependency trees, I agree with you. But there is a trade off here too and that is that either you implement the thing or you externalize it. I use both approaches myself and am in no way excusing anything or attempting to be Rust's defense lawyer. There definitely seems to be a leftpad-problem brewing in the Rust community.
There are certainly good parts in Rust that force you deal with inherent issues explicitly. I do not think this justifies a language with the complexity of Rust, but I would agree it is preferable to C++ in this regard.
I reject the whole Rust has a high complexity premise, but I would gladly continue our conversation around it here but I would need a little more definition for that to be possible.
What do you mean by complexity in this context and in what way does Rust carry a lot of it?
I did not know this was disputed, as even developer surveys in the Rust community highlighted complexity as a concern. But seems it is the overall summary of features that make it complex: lifetime, borrowing, a polymorphic type system, traits, multiple tools to manage lifetimes, macros, proc macros, async, unsafe, panic, unwrap, etc. But I agree it is much cleaner than C++.
Still not picking on C++ here. I would claim that these concepts pretty much all exist in C++ too, but often implicitly so. You would solve them by "braining them", with good rules of thumb, patterns, tests and deep knowledge and skill. In fact, you _have_ to solve them this way.
In Rust the compiler is going to have a problem with your code unless you are explicit about borrowing/ ownership, gcc won't care. Which is the more complex thing there?
Same goes for the polymorphism. Looking at languages without parametric polymorphism, you instead see casts and inheritance trees. Not picking on old Java here, but is this more or less complex?
Let's talk some about unsafe as well. In C or C++, for instance, there is a global unsafe surrounding all the code, so if someone has problem with unsafe, why would they pick on Rust where "unsafety" is optional?
Same goes for unwrap. Unwrap is basically a deref combined with a _safe_ crash if the deref was not successful at runtime. Do that in an unsafe language and you have an access violation best case. Or just silent corruption. Which is more complex?
I'm a really big fan of Rust, but I have to challenge this, GP was clearly talking about the complexity of the language itself, and that one is high.
Extra features and extra static checking add complexity. Extra complexity in the language can make simple programs harder, and they make complex programs easier to code and maintain, like you said.
However, nobody will ever be able to make a Rust equivalent of TinyCC, the language's rules are insanely complex, especially for things like GATs and the other tricky concepts it's trying to tackle.
First of all, Rust is default safe. In C++ developers always trade performance for safety, in Rust they just swallow the penalty (which is often still performant enough). C++ code will often not be as memory safe as it could because someone decided to not use particular checks (like compiler-driven integer overflow checks).
Secondly, Android C++ code is not particularly high quality, also when it comes to memory safety. A lot of it is also quite old.
I would consider it your average massive project, not a masterpiece coded by amazing engineers.
Thirdly, it has a massive target on its back and is under attack by pretty much everyone. They have to use whatever they can to keep up with the attackers.
Several companies have these issues and approach them in different ways. Rust is a very attractive approach for developers, since it’s just another programming language. It’s also quite ugly, people complain about its complexity and is unfortunately suffering from dependency explosion.
I hope it’s a stepping stone to something better.
> In C++ developers always trade performance for safety
A "trade" implies care which isn't actually taken. What WG21 does is they assume that safety costs performance and so they throw away the safety hoping that this means they get performance. They don't measure, which is why you get to see first Herb Sutter explaining that C++ doesn't do bounds checks because they're unaffordable (notice he presents no data) and then a few years later Herb Sutter explaining that the latest C++ will offer bounds checks because they're actually affordable after all (now Google has collected the data)
In most cases it's much worse than the bounds checks, which actually did have a small cost, it's often net negative to throw away safety, C++ chose the less safe and slower option, assuming that this "trade" exists when it doesn't and if they'd measured they'd have seen the news before making the decision.
> First of all, Rust is default safe. [...] in Rust they just swallow the penalty
The borrow checker runs at compile-time, not run-time. Safety doesn't slow down your code except in a few small, specific ways like array bounds checks and UTF8 validity checking - but these checks also happen in unsafe rust too. The overhead is also mitigated by some of rust's other choices increasing performance. (For example, rust uses noalias everywhere, has larger codegen units by default and a better, faster standard library).
There was a really great analysis a few months ago looking at the performance impact of rust, C++ and hardened C++. They patched the compiler to see what happened when all runtime safety aspects were removed - and the result was about a 2-3% improvement. Measurable for sure, but nothing to write home about.
> Secondly, Android C++ code is not particularly high quality, [..] Thirdly, it has a massive target on its back and is under attack by pretty much everyone.
Most code isn't particularly high quality. But I suspect google has better resources and processes than most C++ dev teams. As for security - just about all code is a target now that LLMs can find vulnerabilities so easily. I want all the software on my computer to be hardened against attacks that can be found and exploited in under $5 of compute.
> [Rust is] also quite ugly, people complain about its complexity and is unfortunately suffering from dependency explosion. I hope it’s a stepping stone to something better.
As Stroustrup once said, "There are only two kinds of languages: the ones people complain about and the ones nobody uses." It's a good sign that people are complaining about it. But otherwise I agree - I look forward to seeing how rust's borrow checker inspires new languages going forward. There's a lot more good ideas in the programming language space that we haven't scratched.
Yours is a good book (got both editions myself), but sadly language learning books will be hit the hardest by AI. Partly it’s what you said regarding copyright washing, but the other big reason is that people will code less; I am writing little to no golang and am prompting it instead. The book is still useful to me, since I want to continue to understand what’s happening, review code, etc, however I expect that my kind of software engineer will be in the minority in the future.
If you publish a 3rd edition and I’m not replaced by AI by then, I’ll buy it. :)
On other topics, using AI can fill some gaps, but books summarizing years of hard-won knowledge are priceless. NoStarch is amazing when it comes to such resources. They have an upcoming book on Linux kernel Memory Management for example, the classic Linux tome from Kerrisk and very specialized security books.
On the other hand I cancelled my O’Reilly sub because I didn’t read enough to make it worth the price and now I purchase DRM-free e-books individually, as needed.
I'd bet money I have more experience in this than you. Culture shock is very real (I've lived it), but culture's ain't countries and hell, I get culture shock when I go to the south here in America. It's just some old timey 1940s "we gotta keep these different cultures separated" nonsense. It's nationalism and racism (though it purports to be otherwise).
Things don't have to be this way, we choose them to and I'm getting awful tired of people keeping making the same choices over and over again because they think an imaginary line is somehow sacrosanct.
> I get culture shock when I go to the south here in America.
Or even from urban to rural areas.
> It's just some old timey 1940s "we gotta keep these different cultures separated" nonsense.
That's a huge mistake right there. Those who want to keep their culture should be free to do so, as long as they don't try to force theirs on others - that's a common and traditional American value which is now being attacked by both extremist segregationists and extremist pot-melters.
> It's nationalism and racism (though it purports to be otherwise).
You should learn what these words mean and stop purporting they mean something else.
> It's all made up. Even culture.
Bro, not only culture, the entire human civilization is made up. The issue is to make it good, not bad, but you seem to be all confused about it.
No, it's racism, because 9/10 times when someone says, "well these cultural differences are so vast" they really mean "I don't like people from that culture" which becomes "I don't like people from that country or who look like that."
Almost always. It's always the same thing. Fear of the outsiders and disdain for change. I'm not going to debate you on it, I'm just tired of hearing it.
And yet with all that experience you’ve still managed to come up with a conclusion which describes the exact opposite way humanity evolved and currently lives.
One of the authors commented below that the “teams” were actually persons and the Rust person was an intern.
This is even less serious than the typical pattern of grabbing random students for experiments and then drawing conclusions about the general population.
Not sure about your life experiences, but every new, from-scratch project I have undertaken has looked like 1-2 or at most 3-4 people on good terms who really pulled their weight, with the rest being basically not dead weight, but the management overhead they caused ate up most of the productivity they brought to the table.
All of these didn’t prevent Go from competing with Rust and I’m guessing that Fil-C will be the better choice in some cases.
Rust has managed to establish itself as a player, but it’s only the best choice for a limited amount of projects, like some (but not all) browser code or kernel code. Go, C++, C with Fil-C) have solid advantages of their own.
To name two:
* idiomatic code is easier to write in any of these languages compared to Rust, because one can shortcut thinking about ownership.
Rust idiomatic code requires it.
* less effort needed to protect from supply-chain attacks
To handle supply chain attacks, you need to know where yiur code comes from. That is often not a given when working with languages where it is easier to copy and paste in code from random other projects.
I have seen so must stuff copy and pasted into projects in my life, its not funny. Often it is undocumented where exactly the code comes from, which version it was taken from, how it was changed, and how to update it when something goes wrong.
When code is not copy and pasted it is over rewritten (poorly).
Code sharing does have its benefit. So does making it obvious which exact code is shared and how to update it. Yes, you can overdo code sharing, but just making code sharing hard on the tooling level does mote to hide supply chain security issues than it does to prevent the problem.
I doubt that ideomatic code is easier to write in C once you switch to Fil-C. Your code will just get killed by the runtime whenever it does something it should not do (and the compiler does not catch). You need to think about that stuff when your runtime enforces it.
Indeed, however Rust solves two problems in one language, the safety of managed languages, without having to use any form of automatic resource management, even if reference counting library types might be used, additionally.
As my comment history reveals I am more on the camp of having rewrites in Go (regardless of my opinion on its design), Java, C#, Haskell, OCaml, Lisp, Scheme,... Also following experiments of Cedar, Oberon, Singularity, Interlisp-D, StarLisp,....
However you will never convince someone anti-automatic resource management from ideological point of view.
Now would someone like that embrace Fil-C, with its sandboxing and GC? Maybe not, unless pushed from management kind of decision.
They would probably rewrite in Rust, Zig, Odin,... if those are appealing to them, or be faced with OS vendors pushing hardware with SPARC ADI, CHERI, ARM MTE,... enabled.
> However you will never convince someone anti-automatic resource management from ideological point of view.
It's generally accepted that 'explicit is better than implicit' and what you want in the end is deterministic, machine checked resource management. Automatic resource management is a subset of machine checked resource management. There is a large, somewhat less explored space of possibility (for example seL4 lives in this space) where you have to manually write the resource declarations and either the compiler or some other static analysis checks your work.
Except languages like Rust and C++, are full of implicit behaviour, so it is kind of interesting argument.
Even C has its implicit moments, with type conversions, signal handling, traps, setjmp/longjmp possibly hidden in libraries, thread handling across forks,
First you need to figure out if it’s a surface infestation because of condensation or if it’s a constructive thermal bridge. The latter can be solved by raising the surface (wall, ceiling, etc) temperature through insulation or more inefficiently special heaters designed for this purpose.
In both cases, the contaminated material is removed down to the plaster or masonry. Wood, wallpaper and similar materials will likely be deeply contaminated and must be removed. For areas larger than 1 sq meter, it’s better to get a specialized contractor which will use HEPA vacuum cleaners, special bags, etc to ensure that the mould spores don’t spread in other rooms.
For small areas the agents of choice are bleach or hydrogen peroxide, both available in products for home use.
For the first issue of complexity, the reply is along the lines of show me the code and then either nitpicking that to pieces or explaining in several paragraphs how the behavior is perfectly reasonable and in fact quite easy to understand. Beginners get intimidated, professionals don’t have time to write novels on HN. Complexity in Rust is systemic. It’s little things accumulating and amplifying each-other that add up to having to spend significant time just designing types to satisfy the static analyzer. Many Rust programmers seem to see the type system as a hammer to be used liberally, an predilection also known in the C++ metaprogramming community.
On the second topic (also present in this thread) the counter-argument is that other languages do it too and nothing bad happened so far. The former is not valid, because Rust is uniquely bad in its competitor group and security by waiting is not a valued approach.
reply