Ask HN: What's the Deal with HN and Rust?

Personally I'd take a job based on the pay & how much you like the company vs what specific tech stack they're currently looking for. When I'm getting paid to do it, I like just about any language; getting to use rust is just a bonus. You might also be able to select rust for a new project in the future.

That said, I see postings from time to time in /r/rust. Maybe check the monthly HN hiring threads?

Good point.

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.

The current issue is really to prevent rebuilding of entire compilation units. Incremental compilation helps somewhat but I haven't found it to be good enough when the size increases. My gut feeling is that it comes from linear or n^2 searches across the entire module due to e.g. parts of the trait system. There's no issue depending on huge crates, when they have been compiled. The first compilation can be painful though. This is especially a problem in CI environments where you need to be clever about the caching vs. clean builds.

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...

IMO C++ was and is still the leading language for writing performance-intensive and memory-intensive applications (excluding Rust), and C++ is really flawed. Like, I know that Java and JavaScript and Python get criticism, but the fact is those languages are still usable compared to C++:

- 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++.

HN is about interesting stuff.

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)