Rust is a systems language that is a pleasure to build. This "how to build on Mac/Windows/OSX" is a non-issue and should be a non-issue. Solving how to build something is an utter waste of time and is complete bullshit.
Please, for the sanity of the rest of us, stop using C build systems. They are just unbelievably terrible; people have tried and tried, but you can only do so much with a fundamentally flawed bad idea.
That's not an argument. You do not even try to explain why it is terrible.
C build systems are terrible because they handle 30 years of legacy, 10 different compilers and 100 of platforms that all have their specific non-sense to handle at different compilation stages.
You can also add on that the non-standard build system specific way to handle things like debug/release builds or dynamic/static linking because every system created its own for fun... ( --release/CMAKE_BUILD_TYPE=Release/make release/-Q release=1/etc/etc, .lib files/so/a/dylib/rpath/dt_runpath, lto/not-lto, -Wl,-Bdynamic/-BStatic, etc, etc, etc )
And you get the mess you are in.
The real question on that is: Will Rust be any better in 20 years ?
My hope is that the community will be smart enough to not fragment. But history told us that every OSS project big enough fragment soon or later.
> The Rust programming language has become a serious contender in the space of "systems" programming languages, and has recently been adopted by many of the tech giants for "serious" projects. In response to this, more companies are now considering whether they too should add Rust to their tech stack. This talk hopes to help you make that decision. We go through how the language compares to many current alternatives and what the language has to offer, but also what it's primary drawbacks are and its long-term viability prospects.
https://jon.thesquareplanet.com/slides/considering-rust/expo...
I found his Rust live coding sessions on YouTube[2] to be an enjoyable introduction to Rust.
[1] https://github.com/mit-pdos/noria
[2] https://www.youtube.com/channel/UC_iD0xppBwwsrM9DegC5cQQ
Certainly can, especially compared to JavaScript. The way I've come to view this (and across more languages than just Rust) is that it's a trade-off between providing more information to the compiler which it can use to catch errors, and verbosity. You can't provide the information without some input, though things like type inference can help cut down on this. IMO, it's worth it: my Rust code, once it compiles, I feel has less bugs than my equivalent Python; I'd rather fight with the compiler than with runtime exceptions.
As I've learned Rust, I also find that sometimes you can elide some parts of things. E.g., in collect() calls, you can say Vec<_>, eliding the item in the Vec, because the iterator you're collecting it from already knows it, and it can be inferred from that.
Of course, sometimes, I think it's nice to provide the type anyways, as I find the compiler is better at inferring than I am. I've definitely spent a fair amount of time in Python looking at a variable and wondering what type IS this?
I just can't go back. Typescript gives me most of this. But Python feels just awful to me now. It's like an entire kind of cognitive load is being eliminated from my day.
Are there any anecdotal stories about how Rust programs have fewer errors?
Facebook, for example, rewrote Messenger with ReasonML:
https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...
And it had a lot fewer bugs:
"Messenger used to receive bugs reports on a daily basis; since the introduction of Reason, there have been a total of 10 bugs (that's during the whole year, not per week)! *"
https://www.rust-lang.org/static/pdfs/Rust-npm-Whitepaper.pd...
Excerpt:
> npm’s first Rust program hasn't caused any alerts in its year and a half in production. "My biggest compliment to Rust is that it's boring," offered Dickinson, "and this is an amazing compliment." The process of deploying the new Rust service was straight-forward, and soon they were able to forget about the Rust service because it caused so few operational issues. At npm, the usual experience of deploying a JavaScript service to production was that the service would need extensive monitoring for errors and excessive resource usage necessitating debugging and restarts.
My hobby projects are in Rust and Go. Its personal taste, but I prefer programming in Go. I actively dislike programming in Rust.
In Go, I usually I start a debugger once a week because I need to understand the cause of a bug or panic. I have no idea how to debug Rust, because in 2 years of Rust, I haven't had that type of low level bug.
In my previous gig, we had a premium website hosting platform, and our incoming clients would usually want their old inbound links to keep working. Over time, this meant a few hundred thousand autogenerated rewrite rules in Nginx. This was causing Nginx to use about 10G of memory, so restarting it, which we had to do every time we added a redirect, was an issue.
I replaced this with a small reverse proxy written in rust that loaded all of the redirects from postgresql into a cuckoo filter. Adding a redirect was an INSERT, followed by a NOTIFY to let the proxy know to add the redirect to the filter.
Putting it all together took about 2 weeks of swearing at the compiler, but it never had an issue in production, and used about 1M of memory, while adding less than 1ms of latency, or about 4ms in case of a filter hit. Cuckoo filters can have false positives, so if a redirect was found, we still had to check in the db table before returning 301.
As far as I know it's still working fine, and I use rust whenever I can.
My anecdote is that programming in Rust intuitively "feels" like programming in languages like OCaml or Haskell, which have a reputation for "you'll often spend a lot of time fighting the compiler, but when your program finally does compile, it's much more likely to work correctly on the first run than other languages (e.g. C, C++)."
It's wholesome development, if there were such a thing. I feel good and proud of the code I write in it.
Ruby: Quick fun building the classes and methods. A bit trial and error on dynamic errors. Processing was 40x slower than golang implementation though, so felt a bit discouraging after the fact. But was fun language to prototype OO in! Nice for quick'n dirty projects.
Golang: I didn't find need for OO or interfaces, so simplified for processing code mostly. The language helped in this regard, as it is quite imperative-driven. Golang was the fastest language to develop in, and showed Ruby version to be a bit over-engineered.
Rust: Never coded in Rust before, I searched SO for most relevant code examples and patched it up from several examples. I didn't go into the deeper end of things or optimize anything, but instead spent 90% of the time writing naive processing code while battling the compiler. If I'd been proficient, perhaps no battle, but this required the longest dev time and processing was noticably slower than Go, though not by a factor.
From this short anecdotal experience: Ruby for quick'n dirty fun or OO modelling. Golang for prototyping and initial versions. Rust for where you know you need safe parallellism and special optimizations. Right tool for the job!
If I were to compare Rust to Python/C++ which I'm proficient in, Python would be the fastest because there's zero setup time, tons of quality packages and notebook environment; C++ would take a lot longer due to having to set up builds, and due to lacking stdlib and ecosystem.
Sure there are companies that use it, but I bet you'd have a hard time convincing your manager that Rust is widely accepted in industry.
Anyway, I certainly appreciate all of the posts.
I think it would be interesting to see a breakdown of the blog posts and talks posted to HN by language.
Scala is a strongly typed, very-well vetted, functional programming language in the JVM. It pretty much has everything going for it. It's even adopted by twitter.
Might as well ask why Scala didn't take over from C++.
Is it fair to say that the significance of those points are these?
no JVM: easier deployment
not garbage collected: less latency
zero-overhead abstraction: smaller in memory
The list of complains grew big, but again: all in all, I think Scala was quite fine to work with.
Hard to respond to that as it is so general.
> It's even adopted by twitter.
And larger companies than Twitter use Rust (though to be fair not as extensively as Twitter uses Scala).
They're really not comparable. Rust is a lower-level language with no garbage collection (yet with guarantees about memory safety due to ownership rules). Scala runs on the JVM and has significantly more in the way of OOP (depending on how you use it obviously).
That said, I've found that my extensive Scala experience does come in handy when learning Rust as some features of the type system, pattern matching, threading failures through with ?, etc. These are things you won't have any familiarity with from Java, but do from Scala.
Scala is a disgusting mess compared to Rust in just about every way I can think of. Please for the love of everything good, consider at least Kotlin.
