Ask HN: What's the Deal with HN and Rust?
Just curious, I see so much "pumping" around Rust, and as an engineer myself, I beg the question: why the hype here specifically?
Compare it to Rust, which has one build tool/package manager. No more hunting down dependencies, arguing make vs cmake vs 20 other tools. 99% of projects just use cargo and building a project on every platform is just one cargo build run away. Compiler is smart and can show you many errors in your code that C++ never could. Old mechanisms like header files are replaced with a modern module mechanism. Also some interesting features like the traits system.
All that with performance close to C/C++ and with increased safety. Also, there is a lot of hype behind the language making it reach critical mass. It's not surprising to see many people flock to it. Some people dumped C/C++ in the past for Java/C#, but these languages don't support the same usecases as C/C++ do. Rust does.
Personally I dumped C/C++ for D years ago and don't regret it. It's not as popular as Rust is, and doesn't have the same ecosystem or big companies behind it, but it works for my needs. If Rust existed at the time I was looking for an alternative, I'd probably be using Rust now.
I don't know where you got this figure from, but I highly doubt 1% of Rust projects use a different build/package system. More like 0.001% (this number is scientifically extracted from thin air).
Regardless parent was implying that almost everyone everywhere uses cargo.
OP doesn't literally mean 99%, they mean "almost everyone". The actual numerical value is irrelevant.
Rust doesn't have these issues owing to the "newness" of the language and the memory model. If you're are a C or C++ dev then this is very exciting. If you are an engineer who was always turned off of native coding due to C/C++, then this is very exciting. If you just like languages, then this is pretty exciting to.
- Native
- Web
- Distributed
- ML
- Service
programming without having to switch toolchains. Rust is surprisingly close to achieving this.
my main issue with wasm is no standard interopt for primitive types. thankfully some sort of FFI is in the works from my understanding.
Rust is VERY interesting: Novel memory management, low-level, great tooling, can ACTUALLY compete against C/C++ across the board, have a lot of modern stuff: ML heritage, functional idioms (but you can do imperative code, not worry!), const/immutability promoted, NOT NULL thank you very much!, UTF-8 string "oh amazing", a lot of edge cases accounted for...
And, with interesting tools you get people, interested, in build things. And things that before, you can't do without get the complain "but C".
Now, there is NOT excuse to get into the bandwagon of Fast, Safe, yet ergonomic.
--
And when something like this happens, it invigorate the "market" and other will try taking advantage of what this do good and what it not much (so, I see zig, Nim, odin, catapulted because Rust/Go/Elixir make people talk about programming languages)
There are many such languages or tools - Haskell (or other FP languages) or Erlang being among them - that have some vocal minorities that actually use them. The reality is that these language are highly unlikely to ever gain the traction they might arguable deserve.
I don't feel like this aspect is debatable. Our systems are miserably insecure and unwilling to trade off performance to become more secure. Without Rust or something like it, there's no chance - that's the difference.
If those here are hoping for the hype to die down, they are going to be waiting a while.
Undoubtedly, the issue of memory safety while remaining performant is a game-changer, but the word need is a bit strong here...
When 52% of curl's security vulnerabilities were due to it being written in C (mostly buffer overreads/overwrites), I say "need" is indeed adequate.
https://daniel.haxx.se/blog/2021/03/09/half-of-curls-vulnera...
I noticed on Manning (http://manning.com) "Rust in Action" was the top-selling book for over a month. I think Rust is just a hot topic right now.
HN Rust articles: 4 in the last 24 hours (not including this one)
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
HN Go articles: 0 in the last 24 hours https://hn.algolia.com/?dateRange=all&page=1&prefix=true&que...
JavaScript: 5 in the last 24 hours - a much more popular language but none of these got to the front page
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Counting comments per article the difference is even more dramatic
For Javascript it's the opposite; only one is about something written in Javascript. The rest are about language or its usage.
Not sure if one can say that that's an indication of pumping. Seems more an indication of usage.
I don't know what "pumping" means in this context.
Should we take this as an indication of community interest? Community members are using JavaScript, but interested in Rust and what it can do.
As you might guess, it's hard to distinguish between a "pump" and general interest in something. And, of course, each probably does feedback into other.
---------
[1] https://en.wikipedia.org/wiki/Pump_and_dump
[2] https://enet4.github.io/rust-tropes/rust-evangelism-strike-f...
Whether its the best solution or "deserves" its hype is not a real fruitful question you can ask, as there are many things you need a computer to do, and some of them aren't systems programming. Some things benefit from different kinds of ergonomics, thats ok.
Is there a language that is more funded out there right now?
I don't think Rust is being promoted more than any other language people feel passionate about, but these things tend to go in clusters, so it may seem that way. I think if something specific to a language makes it to the front page, the discussion leads people into looking up things about that language, which then makes them discover, or remember something they think is worth sharing and repeat. The last few weeks I've noticed more Ruby than usual, I see clusters of Python and Go very often, and every year or so there are a few lisp stories in a row. Sometimes this also coincides with conferences.
You don't generally see stuff advocating for bigger languages because they don't need advocates. Instead you might see particular libraries or techniques. I suspect the hype around Rust specifically is people that really like rust hoping that it catches on before it dies out like so many other technologies.
You have those two findings from Google and Microsoft that roughly 2/3 of the vulnerabilities that they find in their code are memory related, so it is definitely something that someone finds important. Also, if you have large scale codebase that is serving millions of people, the assurance of less bugs is much better starting proposition than maybe it won't fail.
The memory safety thing seems to be appealing to some people who believe it will dramatically reduce the security issues found in many software. (they usually know very little about actual security exploits)
Rust is building a cult-like community around it, and I think it could be its demise, I personally hate it (the community)
https://www.chromium.org/Home/chromium-security/memory-safet...
> As was pointed out in our previous post, the root cause of approximately 70% of security vulnerabilities that Microsoft fixes and assigns a CVE (Common Vulnerabilities and Exposures) are due to memory safety issues. This is despite mitigations including intense code review, training, static analysis, and more.
https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...
Removing 70% of security exploits, especially those which can easily lead to arbitrary code execution compared to e.g. logic bugs or DoS issues right at the compiler seems like a huge win?
But I am not convinced that Rust is the solution.
There's a cycle to these things, e.g. a few years back "XYZ in Go" was a lot on HN, because that was the new cool thing people were curious about. Now probably more people use Go, but it's not as interesting anymore as something people don't really know yet. And thus projects written in it don't highlight it as often, so even if they are discussed its not as obvious. OCaml and Haskell also aren't new, but haven't reached the saturation of "many people know them", so if something about them pops up its still interesting to more people.
New C++ indeed is a lot better, but the chance that your codebase was created recently is quite low. You will have to deal with al the old C++ in there. The conflict between new and old C++ will cause some lavaflow architecture as a bonus.
Even if you've got a greenfield C++ project, you're not going it alone. If you're a team of 10, it's almost guaranteed at least 1 of them will be programming like it's 1999 with no intention to change. Code samples by your vendor will not be up to date. A quick google will deliver a working answer from the good old days.
It's like hydra. Every time you axe a block of old code, 5 new ones have sprouted up.
That is just not true. Go submissions rarely reach front page. Ocaml has one in months if not years. Go is used a lot, while OCaml appears in comments mostly for programming language comparison purposes along with Haskell and Erlang. C# and Dot Net ecosystem is fifth most popular language on Tiobe and Stack Overflow. Ada mostly get brought up in the context of Pascal and sometimes in the context of Rust competitor. I would even put it to 1:100 appearance compare to rust and people are already put off by it.
There are may be one or two submission about Zig every one or two months that made it to front page and some are already "asking" why are there so many zig submission on HN.
The only real downsides are in the library availability and deployment vs. more established languages.
I'd choose to use it if I could though, it has the least downsides of any language IMO.
Edit to add: https://foundation.rust-lang.org/members/
Interested in reasons to believe Amazon are not going to determine the future of the language, I'm at least six months out of date.
the rest of just smirk at the pump articles, as we have achieved state of Zen and realize _all_code_is_garbage_ and that nobody, other than minuscule amount of people who ever had a git write access in their life, actually care or will ever care about code let alone a programing language the app was written in
It is possible to recognize that "all code is garbage" and "it is a miracle anything works" while also still pushing our industry forward and improving lives for software engineers. A language like Rust is about a particular kind of ergonomic fix. It gives engineers tools to prevent certain kinds of bugs from the beginning if they properly utilize them. It gives you tools that other languages do not have built in so will require more work to use in a disciplined way.
For some people they won't care. They aren't craftsmen they are factory floor assemblers. They glue stuff together and quality isn't the top concern. This is not meant to be a critique. There is a large market for that. IKEA serves an actual need for many people. By all means there is still a place for the Java, Node, Ruby, or Python developer out there. There is more of a market for factory floor assemblers than there are craftsmen.
I personally though still prefer to be in the craftsmen category and for that reason Rust is exciting because it gives me tools that I would formerly have had to reach for OCaml, Haskell, or Lisp to use but makes them more ergonomic without introducing other issues at the some same time. It's a pragmatic application of concepts that we've been exploring since the 70's and finally get to see bearing fruit. Brushing it off as just the "next shiny thing" is doing it a disservice.
And of course: the enums, match, Option/Result, performance and a handful of other great stuff.
There are tools that explicitly exist for this use case, such as cargo-geiger [0]. There was some drama with a large framework called Actix a while ago due to the maintainer having a bit of a cavalier attitude towards unsafe usage. Etc.
More experienced people will generally be happy to offload ownership tracking to the compiler and save some of their brainpower for other things.
For me, the great benefit here is we can explicitly mark down in the code if a parameter is mutable vs immutable. This is a gain since you know explicitly if what you pass in will be changed or not inside the function.
"nobody, other than minuscule amount of people who ever had a git write access in their life, actually care or will ever care"
So nobody, other than nearly every software engineer out there. Nobody, except the majority of people working in our field. Okay...
I think it has some problems as well (the learning curve is still steep, and I don't know if that's solvable).
However I think the reason Rust gets attention here is because it is heavily used in crypto, which is regularly pumped in HN as well as in other places.
(ducks)
That said, I see postings from time to time in /r/rust. Maybe check the monthly HN hiring threads?
What are Erlang days for?
Erlang days are where we live.
They come, they wake us
Time and time over.
They are to be happy in:
Where can we live but Erlang days?
Ah, solving that question
Brings the priest and the doctor
In their long coats
Running over the fields.
It can be a lot worse too. Java lacks the ability to have really compact data structures and can not lean in too much into the hardware acceleration without becoming incompatible. You can't exactly set `--fast-math`. Shame GCJ got dropped.
> strcpy in C is Turing complete
Not something I've heard of - is this an abuse of Unicode?
> most code has to portable to at least x86 and ARM (often both 32 and 64 bits) so assembly is out…
(I've not looked into this deeply) - It should in theory be possible to offer translation from one architecture to another, but I guess it is much more effort than it is worth.
Seems like if you could translate your assembly into LLVM equivalent assembly (or just use it directly), you could then build for the target architecture [1].
[1] https://stackoverflow.com/questions/7773194/is-it-possible-t...
Maybe GP meant printf [0]?
I was curious too, but my google-fu did not succeed. The closest I found is about printf being Turing-complete [1], which is also new to me.
How so? You've made this claim twice (https://news.ycombinator.com/item?id=27910640), but I can find nothing else to back this up. We know about C++ templates "accidentally" being discovered to be Turing complete, but I've never heard of strcpy() being so...
while((*p++=*q++));
Honest question, can you shed light on how this can be?
It's fair to say that C allows unsafe calls. It's useless to point out that undefined-behavior and unsafe calls could result in Turing completeness. Strcpy() is not Turing complete - it doesn't automatically detect and protect against unsafe usages. That are evil.
- There are several different ways to do everything and half of them are wrong. For example, you can define an unsigned int type with "unsigned", "unsigned int", "uint32", "uint32_t", "unsigned long". Why are there 5 different types for unsigned integer? C++ also supports C-style arrays and pointers and casting, but most of the time you end up using std::shared_ptr and std::vector or std:array or static_cast or dynamic_cast instead.
- Speaking of which, C++ is even more verbose than Java. Most classes will require 2 files, the .h and .cpp, and it's not exactly clear which code belongs in which.
- The C++ compiler and parser is probably the most complicated compiler that ever existed. There is seriously no other language as complicated as C++.
- C++ errors are very long, very verbose, and it's hard to even find where the error is. I literally had projects where I had a simple error (e.g. calling a standard library function with the wrong arguments), and I spent time trying to debug it because I couldn't even find the error location since the error messages were so long they went past the terminal buffer limit.
- CMake is really bad. I can't speak much to how bad it is because I don't even really know how to use it despite working on multiple C++ projects. But I do know, trying to clone C++ projects with CMake they often fail, and that out of all the build systems I've worked with (including npm, Maven and Gradle), CMake is the one I still don't really understand.
- The C compiler is also really slow. Static analysis is also not very good, even with the effort put towards it, because C++ is so complicated.
- There is no easy way to declare a tagged union (excluding third-party libraries). There are also a few other features that Rust does which take a lot of boilerplate to implement in C++.
- And on top of that, you have buffer overflows triggering security vulnerabilities.
In conclusion, C++ is basically broken, which is why so much time and effort has been put into Rust. In fact, a lot of Rust design decisions (good error messages, simple package manager, tagged unions, the entire borrow checker) were put in precisely because of how badly they were handled in C++. Rust definitely has its own flaws, and is a lot newer and more unstable. But it's the best alternative that allows programmers to write performant and scalable applications which is not C++.
Go: Too much Google influence and GC/allocation being constrained by it's authors. Swift: Same for Apple, see above Nim/Zig/Crystal/Elixir: Too behind in terms of widespread support and development. (At least not as good as rust)
I've not personally spent much time in it, but I hear the biggest complaint is still the compiler support/performance being somewhat random. Can anybody here speak to that?
To solve this you can move to a workspace structure with internal crates, this makes local changes and tests very fast to compile. For the larger structure you only recompile what is needed starting at where the change originates in true DAG form. On the other hand you can't create dependency cycles.
For a workspace setup look at for example Rust-Analyzer:
https://github.com/rust-analyzer/rust-analyzer/blob/master/C...
> Also that the HN bubble will always make readers feel behind when in reality 90% of the industry hasn’t even begun to catch-up. I felt behind with K8S in 2016, for example, not realizing we were just seeing the wave form when I felt like it was cresting. [0]
That being said I do have a goal of learning more Rust in 2022 :) I don't care for all the macro usage so I want to learn more about it so it feels less magical to me.
- learn to hate memory safety issues
once you master both of those bullet points, rust starts looking very attractive.
You do not question or criticise The Rusted Holy Grail and the Riscy Silver Bullet.