I tried to pick up Rust a few years ago, but there were too many sharp edges. I thought it was a nice language, but was too early for actual use. I played with some libraries (Apache Arrow, etc) and it was nice.
About 2 months ago I wanted to use Arrow within Elixir, which required me to start using Rust again (Elixir uses Rustler to safely convert from Rust <> Elixir without theoretically crashing the beam). I am amazed how far it's come, and I've actually been using it a lot over the last few months and haven't ran into any major issues. There is a fair amount of information out there, and the documentation as the OP pointed out is really fantastic.
The libraries are really good now, and I've had no issues using it on Linux or on my Macbook M1. Incredibly impressive speed results. SIMD is a game changer.
Major shoutouts to arrow2 and Polars, I love using it for data analysis :).
I mean it depends. Many of aspects of Rust that are perceived as sharp edges are in fact the programmer bringing in their preferences and paradigms from other languages and trying to program that way in Rust.
I was one of those and tried to do OOP in Rust. It was a pain. At some point I gave up and was like: "Okay Rust, I do it your way, I just want this to work". And it worked flawlessly and easy. I literally had to overcome my ideas of beauty in code to realize how Rust is meant to be programmed in (more data oriented, less object oriented).
This was a really good lesson for me, as I had to question similar aesthetically motivated decisions I made in other languages in the past.
Rust actually supports most OOP features, with the main exception of implementation inheritance. And implementation inheritance is a nasty footgun in large-scale software systems (search around for: "fragile base class problem"), in a way that just doesn't apply to simple composition and pure interfaces (traits). So it's hard to fault Rust for including the latter and not the former.
Having studied mostly OOP/Java at the uni, and been using mostly C# at work, I realized I might actually start to find programming fun again through Go. I've studied it a bit recently and this idea of interfaces with composition over inheritance etc. made somehow a lot more sense to me, and gave me this boost to try and learn it more because it felt so enjoyable. Not even with some practical problem at hand to solve, but just on an abstract level, not having to deal with OOP classes and inheritance and all the things. Now I just need to find a Go job and get my feet a little more wet. ;P I'm talking about Go because it gives me similar feelings as Rust, but Rust I have a lot less experience with. I hope there's a similar fun and excitement to be found in Rust as well, after unlearning some old habits.
As someone who even structures their Python in OOP, I'd appreciate elaboration on how you organize your Rust code. I've been glancing at Rust for far too long, never finding a weekend to dive in. Save me some headaches, how should I approach e.g. Customer - Product - Order relations without OOP? What is the canonical "Rust Way"?
I had a very similar experience; thought it was an interesting language but I got discouraged around the time the small stuff I was working on required lifetimes, or had weird reference errors (or at least, what I thought was weird at the time).
When I tried again recently I started with the Too Many Linked Lists, which I felt did a better job of explaining both lifetimes and how the compiler views <type>, &<type>, and &ref <type> as completely different types, and that helped a ton.
Combine that with spending more time understanding how Rust handles object composition (compared to "traditional" OOP), the massive compiler improvements W/R/T lifetime elision and auto-derefing within the past several years, and realizing just how damn helpful the compiler and documentation is compared to other languages (again, thanks to TMLL for explicitly showing this), and it's been a downright pleasure to use this time around.
Indeed, I’m rereading The Rust Book , after struggling and finding slight success about around 2018, and am surprised at how much better the presentation is, as though they maintainers have closely studied where people got hung up, and then targeted those areas to add clarity.
This is a somewhat heretical opinion but I don't think having a formal specification is particularly important for programming languages today.
It was very valuable, say, twenty years ago, when there were most programs were written or compiled using multiple closed source implementations of languages coming from competing companies. There were real economic incentives for the implementations to diverge from each other in ways that harmed the larger ecosystem. A formal spec was a forcing function to make those implementations compatible.
Today, programmers simply won't use a language whose implementation isn't open source with a very permissive license. This makes it very hard for an organization to deliberately make the implementation incompatible with others because other organizations and users are able to either avoid the incompatibility by forking the implementation if they don't like it, or making it compatible by using the implementation if they do.
I still think it's very valuable to have a committee with members of all implementations that helps drive consensus for where the language should go. But the document itself I see as secondary to that human process.
I love rust. I didn’t find it difficult to learn and at this point several others I’ve introduced it to also haven’t. I’m baffled as to where that reputation comes from.
I get that it makes you think about what you’re building a little more than something you can throw together like Python or Ruby but if the end goal is software that works correctly, getting there definitely isn’t harder with rust. It’s the complete opposite :/.
I use Rust for more or less everything these days, but I found the learning curve to be fairly tough up front. That was in 2019, though; maybe it's easier today with all the improved compiler diagnostics and new books and whatnot.
> if the end goal is software that works correctly, getting there definitely isn’t harder with rust. It’s the complete opposite :/.
Strongly agree with you here. It takes me a lot less time to put something that functions correctly together with Rust than it does with Python or Go. Maintenance also gets a lot easier as the codebase grows.
I recently started a job at a Python shop, and the kinds of bugs/regressions we hit are super annoying because a compiler with a type system would have had them simply be build errors up front.
> I’m baffled as to where that reputation comes from.
It's a deep language with a mix of borrowed syntax(es) and designs. You can pick up Go or Python or Nim in an hour and have a working application, that's fairly unlikely with Rust.
I'd say it took me a year to feel comfortable with Rust - to the point where I could just sit down and write applications without Googling every five minutes - which is far longer than I've spent with any other language.
Do you have a lot of experience with manual memory management? (Or are you just writing very simple 1-off programs?)
Rust definitely requires a different thinking process than most other languages. If you're already doing that kind of thinking, you'll probably have a very gentle learning curve.
On the other hand, the concept of ownership and borrowing takes a bit of time getting used to. Once ARC is in the picture; the curve gets very steep if you're coming from a language with automatic memory management where all state is mutable.
> I’m baffled as to where that reputation comes from.
Aside from the awesome community that rust has, don't underestimate the power of marketing. Someone should ask Mozilla how much was spent for rust development.
I have been thinking to myself whether I should pick up Go or Rust as a new language this year.
Coming from a NodeJS background, Rust looks a tad more complicated but it looks cooler. There are also more job listings looking for Golang than Rust which makes me wonder if Golang might be a more rewarding investment?
What would be a good use case of Rust than Golang cannot do given its extra complexity and potentially lesser monetary reward? Any advice on which I should pick as a new language to learn?
Rust is the more elegant and powerful language. Creating a new language and repeating the "billion dollar mistake" by including null (sailing under the brand name "nil" in Go) is just crazy. Error handling is another strange thing in Go. And generics have been only introduced recently, but there is hardly any support for libraries in it (now). While Go is definitely fast enough for most scenarios, it is not the best language for low level code like drivers or kernel development.
So, depending on your goals, I think Rust is the better language in general. But if your goal is to get something done fast, then Go would probably be better, since it doesn't require that much learning effort.
As someone with extensive experience with Rust and a teensy bit of experience in Go I can tell you that I adore Rust for every use case I’ve tried it out for *except* for network services. It works ok for low level proxies and stuff like that; but Python/Flask-level easy it is not.
Meanwhile my experience with Go has been the reverse. I’ve found it acceptable for most use cases, but for network services it really stands out. Goroutines <3
Yes. Rust is for what you'd otherwise have to write in C++. It's overkill for web services. You have to obsess over who owns what. The compiler will catch memory safety errors, but you still have to resolve them. It's quite possible to paint yourself into a corner and have to go back and redesign something. On the other hand, if you really need to coordinate many CPUs in a complicated way, Rust has decent facilities for that.
Goroutines don't have the restrictions of async that you must never block or spend too much time computing. Goroutines are preemptable. The language has memory-safe concurrency (except for maps, which is weird) and has garbage collection. So you can have parallelism without worrying too much about race conditions or leaks.
Go comes with very solid libraries for most server-side web things, because they're libraries Google uses internally. Rust crates have the usual open source problem - they get to 95%-99% debugged, but the unusual cases may not work right. Go has actual paid QA people.
Go has limited aims. It was created so that Google could write their internal server side stuff in something safer than C++ and faster than Python. It has a limited feature set. It's a practical tool.
I write hard stuff (a multi-thread metaverse viewer) in Rust, and easy web stuff (a data logger which updates a database) in Go. Use the right tool for the job.
> I adore Rust for every use case I’ve tried it out for except for network service
thats hilarious, my daily driver language is elixir which is the goat for network services. I saw rust as the perfect compliment for that where I need everything else.
I have no experience with Rust myself and a good 2-3 years with Go, so my opinion here is biased but: I think Go is more suitable for general all-purpose programming, whereas Rust is more specialized; I'd pick the latter if you need to do high-quality, close-to-the-metal software, and Go for more generic software, taking the same spot that NodeJS did for you.
That said, Go isn't a very "convenient" language; there's not as much magic or magic libraries that come with the language that take over big chunks of your application, and the community at large actually recommends against using libraries in favor of just using the standard library.
And after a while, I... kind of agree? My HTTP API is gorilla/mux, which is only a thin layer over the standard library's HTTP server APIs (it adds routing / path matching). I started using Ent to abstract away my database, then switched to Gorm when I got annoyed at having to write so much code just to do inserts / updates and manually having to add / remove rows, but that one falls apart as soon as you have a data structure that maps to more than one level of tables deep.
I mean part of my troubles with databases is probably a disconnect between wanting to store items like whole documents but mapping them onto a relational database.
What are you looking for in the 2 languages?
Here are some of my thoughts:
Golang
* Development speed: Golang wins by far. It's closer to Python in that regard, but with strong typing.
* Very nice multi-threading via Go routines and channels. Impressive semantics in simple syntax, requiring no synchronization mechanism on the user side.
* Large garbage collector penalty.
Rust
* Complete language with build system, crate, docs hosting.
* A lot more performance compared to Golang, on par with C++.
* Doctests (!).
* Slow to learn, slow to compile (probably not a deal-breaker, especially if you focus on microservices).
Concerning what would be a good usecase for Rust vs Golang, check this out:
> Very nice multi-threading via Go routines and channels. Impressive semantics in simple syntax, requiring no synchronization mechanism on the user side.
Go’s fundamental semantics are standard not-safe shared-memory multi threading. It provides an mpmc queue as a built-in out of necessity (since no generics originally, which would have made for an awkward situation), but really the only thing that’s notable about it is `select`, not `go` or `chan`.
In in some ways `go` is even a downgrade from other languages: you can’t get a handle on the goroutine and thus have to muck around with side-channels to even know that a subroutine has terminated let alone get its result.
* Go also includes the complete build system, package management (although it wasn't there from the beginning), code documentation, testing and fuzzing. Also the standard library is much more extensive than in Rust ("batteries included").
* "Large garbage collector penalty": that obviously depends on your application and what you consider acceptable. I would say that in most cases the easier development enabled by having GC is worth it, but YMMV. Here's a discussion on the Go garbage collector: https://news.ycombinator.com/item?id=12042302
How "large" is the garbage collector penalty? My understanding is that the Go GC is significantly more efficient than for example JS's mark/sweep approach. Apples to oranges for sure, but I am interested in better understanding how expensive the Go GC is vs Rust performance.
I had the same reflexion about 2 years ago. Realistically, pretty much any program written in NodeJS can be ported to Go and vice versa. But not every Rust program can be ported to NodeJS/Go. It opens up a new class of software that is not typically available to NodeJS/Go developers (e.g. systems programming, embedded, writing libraries for other languages, etc.).
So I went with Rust and am very happy with the decision. Despite being a systems programming language, it feels surprisingly like a high-level language and I now default to programming stuff in Rust unless there's a strong reason to use NodeJS.
PS: That said, an often understated benefit of Go is that the community and job opportunities are massive in comparison to Rust (for now, at least).
In practice, the compile time and binary size of Rust are out of control, which makes Rust far from being a slam dunk over C++. Crossing my fingers this will change!
One drawback of Go (in my opinion) is that it has a runtime. So it's very difficult (impossible) to use it with other languages that also have a runtime. So if you learn Go, you'll never be able to use it to interoperate with e.g. your Python program to speed it up.
With Rust, you could use it to replace the most time critical parts of your high-level program piece by piece. The learning curve is then much easier, and adoption can be gradual.
Having a runtime does not, by itself, preclude interoperating with other languages that have their own runtime. Here's a project that does that for .NET and Python:
(Note that this is not a reimplementation of Python on top of CLR, but rather a bridge between CLR and CPython.)
The thing that makes FFI problematic in Go is green threads, which have their own stacks that nothing but Go understands. Thus, every FFI call has to arrange things to be what the callee expects, and you can't do async using goroutines across language boundaries (whereas callback-based solutions like promises work jsut fine).
Learning Rust is a good exercise in understanding memory safety. Learning it will make you understand the gotchas of what can go wrong with memory allocation, which will translate very well to coding in other languages, especially C.
Just like learning Haskel is a good exercise in understanding functional programming and lazy evaluation, which again will translate very well to the code you write as you will be able to identify pattens where functional programming can be applied.
However, neither language is really super applicable to general development, because there are hoops you have to jump through to write basic code where the language advantages are not really need, and other languages are much simpler and faster to develop in.
Golang is much more widely used for this reason, as its compiled yet features a gc, simpler to develop in with java contains a lot of good functionality in its stdlib.
Since you're coming from a NodeJS background, you'll want to pick up an introductory textbook about C as well. Rust implicitly relies quite closely on the C machine model, and introductory books about Rust (such as "The Rust Programming Language") don't do a very good job of conveying the nitty-gritty details of that model to novice coders. This is a pretty nasty pitfall when trying to code in Rust, and it's important to address it early.
I'm self-publishing "Rust From the Ground Up" which takes this approach: each chapter rewrites a classic Unix utility (head, cat, wc, ...) from the original BSD C source into Rust. I find for systems programming it's easier to understand how things work in C, and then teach the idiomatic way of doing it in Rust. C is pretty easy to follow along in "read-only" mode with some explanations.
This is the main reason I’d recommend that a Node programmer learn Go first.
I haven’t learned Rust yet, thought I’m quite keen to do so, but I have an (ancient) background in C, C++ and 8-bit assembly. I don’t find that I really use much of that knowledge when I work in Go, even though Go is still a lot closer to the metal than Node.
> What would be a good use case of Rust than Golang cannot do given its extra complexity and potentially lesser monetary reward?
Anything where low-level control is required. It's not clear if there are true-Rust web apps in the wild (as opposed to web apps with some services in Rust); as far as I read, Rust web programming is ugly.
The market still offers few positions, largely dominated by crypto. I have the impression that it will still take many years before the field will move to Rust (where appropriate).
> Any advice on which I should pick as a new language to learn?
Depends on the concrete goals. If you want to make a career, Golang is the safe bet, by a very long stretch. If you want to have fun, try both, and you'll naturally find your inclination, as they have a radically different flavor.
> Anything where low-level control is required. It's not clear if there are true-Rust web apps in the wild (as opposed to web apps with some services in Rust); as far as I read, Rust web programming is ugly.
There are. I run one. Written in pure Rust. 160k lines of Rust code in total, serving over 3 million HTTP requests per month. Best choice I've ever made.
Rust especially shines when you need to maintain a big project over a long period of time. People often say that Go is much more productive than Rust, and in most cases that is true, but as the size of your project increases and your expertise in the language increases this relationship inverts, and Rust starts to be much more productive. Pick a right tool for the job.
I'd say it's also a question of team size and organization. Are you a singular developer, or in a large team, writing enterprise software that should be easy to pick up for someone reading the code 10 years later etc.
I personally feel rust is advertised more as safer and faster rather than as a practical yet harder alternative to C or C++.
Although Go as a systems programming language is misleading, it's not something that is as heavily discussed about.
In the long run Rust's complexity will hurt newcomers(new to programming) while it will be a blessing for seasoned c and c++ devs. If all programming languages were tools, rust would be a very very specific tool which makes a lot of sense for a specific case. If nodejs and golang are tools, choosing one over another is easier as you can do same things in both easily with small effort. But you cannot rewrite all rust programs in nodejs or golang.
Finally you need to ask if rust is really worth picking over golang/nodejs for things that can be easily done in nodejs/golang. Rust is not for people who think is rust for them.
Arguments like some implementations are more elegant in some other language can always be brought up as arguments. They should only be taken into account when you run out of options to compare because they are exaggerated and subjective most of the times. For example(exaggerated) screaming why go doesn't have a borrower checker like rust makes no sense because go is garbage collected. For many people seeing such absence of features equate to lack of features in a programming language leading to more boilerplate or other downsides which is not necessarily true.
I think Go would typically be considered a possible substitute of one the "more VMy" languages, Rust a complement.
At first glance this looks as if Rust would be more at home with polyglotism, but the typical Rust complement would be a hot performance critical part of something much bigger, and this is already deep in the realm of strategical commitment (all the not so hot parts have to buy in). Whereas Go often enters the picture in isolated one-shots and can grow from there.
If you want to optimize your learning experience, then learn Go first. Rust has a very steep learning curve, whereas you can pick up Go very very quickly.
I learned Go by reading The Go Programming Language. It's a bit old, but a very good book nonetheless.
I second this. I'm a huge Rust fan, and not really a Go fan, but if you're thinking about leaning both, it will be much faster to learn Go first. Spend a couple weeks on that, and then you'll have another data point to compare while you learn Rust. (Go also distinguishes between pointers and values, which will be a helpful concept to have under your belt when you start Rust.)
For someone writing node apps, Go is a better fit. Go is much simpler than Typescript and almost performs as well as Rust. The reality is most Rust apps written by average Rust programmers do not noticeably outperform Go apps. Getting Rust to outperform Go requires a high level of proficiency in Rust. The effort vs reward definitely favors Go for node type of apps.
If you're looking for a new language in order to get a job, then I wouldn't be looking for either of these languages and look into something much more common like C++ given your background.
I see Rust as more for people in systems programming who want improvements over C, rather than a desktop developer looking to learn something new. There's a lot of hurdles that you only really appreciate if you've come from an unsafe/low-level background
Most of my experience is with python and js. I feel like if you have experience with python, go resembles a lot. While if you have some experience with js, rust feels like an extension (but takes time to feel comfortable). If you like arrow functions, using map, filter, etc. You will feel amazing when using rust.
Those are my 2 cents.
And spite of some other comments, I found writing web servers in rust okay, and I think go is also fine for web services.
And with go it also feels a bit like python when using other libraries, I don't know where to start. While rust with cargo is more similar to the npm experience
I figured I should have given some context to my question on deciding to learn either Rust or Go.
One of the reasons I started thinking which language to pick is when I started diving into web3 development. It seems like there is a trend into either using Go or Rust or both in some of the ecosystems. Think Tendermint, Cosmwasm, Solana, etc. While it makes sense to just learn both languages, I don’t think I have the mental capacity to learn both together quickly. It might work better to learn the one that has the most potential in the long run based on the trend.
I worked in Haskell for many years. It is an absolute myth that rare languages command less salary. Remember the more popular the language, the more supply, hence less pay.
Go compiles to WASM but the stock compiler is pretty bad for this and your binaries are like 2MB+ in size.
TinyGo is an LLVM based compiler that targets microcontrollers but also has a WASM target and that creates considerably smaller binaries, but it doesn't fully support all of the Go standard library.
Yes it does, but there are some issues, mainly the size of the compiled WASM file. But you can get around that by using TinyGo. I'm not that deep into it, but this article seems to give a good (and as far as I can see up to date) overview: https://elewis.dev/are-we-wasm-yet-part-1
Go does compile to wasm, however because wasm is what it is it has to carry around the entire runtime. This is obviously a much bigger issue for delivery over the web than it is for shuffling binaries around, or even more so creating them locally: last I’d checked, the baseline (an empty main function) for a go wasm package is about 1.3M.
I think it's worth spending a few weekends with Rust, even if it's just to expose you to some of the concepts in the language.
Beyond things like borrow-checking; the language introduces a LOT of concepts that are quite foreign. Exposing yourself to them is good; because I expect that future languages will borrow heavily from Rust.
you'll grow more as a developer from rust. Rust will force you to think about things like memory management, safety etc. additionally, it has a rich set of abstractions. rust also has better interop with c and c++. In the long run, you're better off learning rust. You'll encounter a brutal learning curve but once you know it, you'll find yourself able to do very powerful things with ease. especially once you internalize the borrow checker.
Go is a great language for the short term but I don't feel like it brings Anything unique or interesting to the profession. its only real advantage is that its quick to learn but there isn't much substance. Its a great language if you're the type of person who doesn't mind copying large reams of code to change a few lines for a new purpose.
I think rust is the new haskell. After spending 7 months learning it, I can say I really enjoy the language, but there's no job in it and in my opinion, they take academic decisions that make the language way more complex than it should. Also, the community is toxic.
For example, generics in Go were criticized by some, praised by others.
You have the feeling that you can freely share your opinion in the go community without the risk of being harassed by the rest of the community.
In the rust community, just like a sect, everybody must say that everything is just perfect.
Passive / aggressive attitude is something I've seen a lot in the rust community.
I would suggest that if your plan is to learn C/C++ next, and you never really understood memory issues && pointers, then rust is a perfect choice at first.
I'm planning to learn Go next, I don't regret learning rust, I learned lots of things with it.
Rust got already adopted by lot of either big or interesting to work at players (Amazon, Microsoft, DropBox, ...?) and, while anecdotal, I myself get also paid to program rust.
> the community is toxic.
> In the rust community, just like a sect, everybody must say that everything is just perfect.
I often get the opposite feeling with all the diverse and lengthy discussions about how to do things, e.g., like getting async stable a few years ago or long blog articles of core contributors that state "we can do a lot better here and there" in public blog posts that get shared on /r/rust and don't get shunned.
How so? I've seen the random drama crop up here and there, but it always seemed to mostly be about the "political" side of things, as opposed to the technical development.
What few interactions I've had with library maintainers and the tokio project have always been positive, and the people always seemed helpful.
As of today, indeed.com lists 1,500 remote jobs mentioning Rust vs. 4,018 jobs mentioning Golang. That's not so bad. (However, there's no way to tell how many of those listings are Rust-specific as opposed to polyglot job descriptions.)
> Also, the [Rust] community is toxic.
Speaking slightly humorously, if you think Rust community is toxic, try expressing your dissatisfaction with Swift or Apple in the fanboi Swift community (controlled by Apple employees) and see what happens to you :).
I think "somewhat dogmatic" would be a more accurate description of the Rust community, IMO.
For example, I recently had a discussion about `enum` being a poor choice for what Rust makes it to mean from a C/C++ developer's point of view (which are Rust's main "replacement target" languages). The closest I got someone to agreeing with me is a sentiment along these lines "well, `variant` would may have been a better choice but it's not very familiar to C/C++ developers and, besides, when this decision was made, Rust had a hard limit of 5 characters on keyword length".
This is wild to me as someone who spent many years in Haskell and made shit tons of money doing it. There are myriad Haskell jobs available. I'm taking a break right now (mainly to pick up other skills), but would go back to it in a heartbeat. There are lots of Haskell jobs.
I've spent some time casually learning Rust in the past few weeks, and I'd really like to start incorporating it into my serious C++ projects. Rust itself is nice, but having a reliable package manager & build system in the form of cargo is absolutely the killer feature for me.
If I could use Cargo/cxx_build as my C++ build system (which I think may be possible, but I haven't seen a good example), I would fully embrace rust & start incorporating it into my professional work today.
I just want to give a shout out to "Rust for Rustaceans".
I'm only three chapters in, and it's definitely the most enjoyable technical reading I've ever done because you learn so much, so quickly, and so easily. Steve Klabnik (co-author of "The Rust Programming Language") says it's the book to read after going through "The Rust Programming Language", and I couldn't agree more.
+1 from me here! The book arrived yesterday (yes, I'm a luddite like that), and now I'm at chapter 8. For me, I'm already aware in one way or another of most things in it, but my knowledge is spotty in places, and all over the place too. So, R4R seems really great to put some framework around it, as well as get at least accustomed to the least familiar bits.
I would add though that I can see how it can be a pretty challenging read depending on prior experiences. Even then I believe it makes a lot of sense to read through it to at least get exposed to some topics and be able to recall later that you've read something about it when you need it.
I just finished this book. I liked it and learnt a lot, but in some chapters I felt way too far from my comfort zone. The unsafe chapter and some part under the hood of async like Pin/Unpin was difficult for me.
Thanks for the heads up! This is indeed worth noting.
Even in the first three chapters for example, if someone isn't familiar with memory layout in C, or the stack/heap distinction, ..etc, it can seem a bit complicated I think.
I liked that fasterthanlime article a lot too. The main thing it gave me was enough context to get enthusiastic enough about the language to sit down and read through the O'Reilly book¹ (which I thought was excellent).
I'm still very much a Rust beginner, but I've managed to build a couple of useful tiny projects and to hack a feature I wanted into someone else's big 'ol codebase!
This sounded interesting but I was confused by what you meant by "the book." Looks like that's how it's commonly referred to https://www.rust-lang.org/learn
“The HTML format is available online at https://doc.rust-lang.org/stable/book/ and offline with installations of Rust made with rustup; run rustup docs --book to open“
More importantly, it has a “next page” arrow at the bottom right, and a TOC pop-up at the top left of the page.
> Programming Rust (link to review) is the first book I read for an initial introduction to the language.
This book is very much under-rated. If you've unsuccessfuly tried to learn Rust by reading "the Book" cover to cover, you might try reading Programing Rust in the same way.
Readit News
About 2 months ago I wanted to use Arrow within Elixir, which required me to start using Rust again (Elixir uses Rustler to safely convert from Rust <> Elixir without theoretically crashing the beam). I am amazed how far it's come, and I've actually been using it a lot over the last few months and haven't ran into any major issues. There is a fair amount of information out there, and the documentation as the OP pointed out is really fantastic.
The libraries are really good now, and I've had no issues using it on Linux or on my Macbook M1. Incredibly impressive speed results. SIMD is a game changer.
Major shoutouts to arrow2 and Polars, I love using it for data analysis :).
I was one of those and tried to do OOP in Rust. It was a pain. At some point I gave up and was like: "Okay Rust, I do it your way, I just want this to work". And it worked flawlessly and easy. I literally had to overcome my ideas of beauty in code to realize how Rust is meant to be programmed in (more data oriented, less object oriented).
This was a really good lesson for me, as I had to question similar aesthetically motivated decisions I made in other languages in the past.
When I tried again recently I started with the Too Many Linked Lists, which I felt did a better job of explaining both lifetimes and how the compiler views <type>, &<type>, and &ref <type> as completely different types, and that helped a ton.
Combine that with spending more time understanding how Rust handles object composition (compared to "traditional" OOP), the massive compiler improvements W/R/T lifetime elision and auto-derefing within the past several years, and realizing just how damn helpful the compiler and documentation is compared to other languages (again, thanks to TMLL for explicitly showing this), and it's been a downright pleasure to use this time around.
I strongly suspect that it will stick this time.
It was very valuable, say, twenty years ago, when there were most programs were written or compiled using multiple closed source implementations of languages coming from competing companies. There were real economic incentives for the implementations to diverge from each other in ways that harmed the larger ecosystem. A formal spec was a forcing function to make those implementations compatible.
Today, programmers simply won't use a language whose implementation isn't open source with a very permissive license. This makes it very hard for an organization to deliberately make the implementation incompatible with others because other organizations and users are able to either avoid the incompatibility by forking the implementation if they don't like it, or making it compatible by using the implementation if they do.
I still think it's very valuable to have a committee with members of all implementations that helps drive consensus for where the language should go. But the document itself I see as secondary to that human process.
I get that it makes you think about what you’re building a little more than something you can throw together like Python or Ruby but if the end goal is software that works correctly, getting there definitely isn’t harder with rust. It’s the complete opposite :/.
> if the end goal is software that works correctly, getting there definitely isn’t harder with rust. It’s the complete opposite :/.
Strongly agree with you here. It takes me a lot less time to put something that functions correctly together with Rust than it does with Python or Go. Maintenance also gets a lot easier as the codebase grows.
I recently started a job at a Python shop, and the kinds of bugs/regressions we hit are super annoying because a compiler with a type system would have had them simply be build errors up front.
It's a deep language with a mix of borrowed syntax(es) and designs. You can pick up Go or Python or Nim in an hour and have a working application, that's fairly unlikely with Rust.
I'd say it took me a year to feel comfortable with Rust - to the point where I could just sit down and write applications without Googling every five minutes - which is far longer than I've spent with any other language.
A lot of really nasty problems are caused by people thinking they understand what JavaScript is doing.
Rust definitely requires a different thinking process than most other languages. If you're already doing that kind of thinking, you'll probably have a very gentle learning curve.
On the other hand, the concept of ownership and borrowing takes a bit of time getting used to. Once ARC is in the picture; the curve gets very steep if you're coming from a language with automatic memory management where all state is mutable.
Aside from the awesome community that rust has, don't underestimate the power of marketing. Someone should ask Mozilla how much was spent for rust development.
Sun microsystems spent about $500 million in 2003 to push forward Java. https://www.theregister.com/2003/06/09/sun_preps_500m_java_b...
Coming from a NodeJS background, Rust looks a tad more complicated but it looks cooler. There are also more job listings looking for Golang than Rust which makes me wonder if Golang might be a more rewarding investment?
What would be a good use case of Rust than Golang cannot do given its extra complexity and potentially lesser monetary reward? Any advice on which I should pick as a new language to learn?
So, depending on your goals, I think Rust is the better language in general. But if your goal is to get something done fast, then Go would probably be better, since it doesn't require that much learning effort.
You forgot pointers used to represent nullables.
Go was never ever intended for this purpose.
Can you explain? What do I set ‘score’ to when someone hasn’t sat the test yet?
Meanwhile my experience with Go has been the reverse. I’ve found it acceptable for most use cases, but for network services it really stands out. Goroutines <3
Goroutines don't have the restrictions of async that you must never block or spend too much time computing. Goroutines are preemptable. The language has memory-safe concurrency (except for maps, which is weird) and has garbage collection. So you can have parallelism without worrying too much about race conditions or leaks.
Go comes with very solid libraries for most server-side web things, because they're libraries Google uses internally. Rust crates have the usual open source problem - they get to 95%-99% debugged, but the unusual cases may not work right. Go has actual paid QA people.
Go has limited aims. It was created so that Google could write their internal server side stuff in something safer than C++ and faster than Python. It has a limited feature set. It's a practical tool.
I write hard stuff (a multi-thread metaverse viewer) in Rust, and easy web stuff (a data logger which updates a database) in Go. Use the right tool for the job.
Deleted Comment
thats hilarious, my daily driver language is elixir which is the goat for network services. I saw rust as the perfect compliment for that where I need everything else.
That said, Go isn't a very "convenient" language; there's not as much magic or magic libraries that come with the language that take over big chunks of your application, and the community at large actually recommends against using libraries in favor of just using the standard library.
And after a while, I... kind of agree? My HTTP API is gorilla/mux, which is only a thin layer over the standard library's HTTP server APIs (it adds routing / path matching). I started using Ent to abstract away my database, then switched to Gorm when I got annoyed at having to write so much code just to do inserts / updates and manually having to add / remove rows, but that one falls apart as soon as you have a data structure that maps to more than one level of tables deep.
I mean part of my troubles with databases is probably a disconnect between wanting to store items like whole documents but mapping them onto a relational database.
Golang
* Development speed: Golang wins by far. It's closer to Python in that regard, but with strong typing.
* Very nice multi-threading via Go routines and channels. Impressive semantics in simple syntax, requiring no synchronization mechanism on the user side.
* Large garbage collector penalty.
Rust
* Complete language with build system, crate, docs hosting.
* A lot more performance compared to Golang, on par with C++.
* Doctests (!).
* Slow to learn, slow to compile (probably not a deal-breaker, especially if you focus on microservices).
Concerning what would be a good usecase for Rust vs Golang, check this out:
https://discord.com/blog/why-discord-is-switching-from-go-to...
Except for all the times they are required and Go doesn’t tell you: https://eng.uber.com/data-race-patterns-in-go/
Go’s fundamental semantics are standard not-safe shared-memory multi threading. It provides an mpmc queue as a built-in out of necessity (since no generics originally, which would have made for an awkward situation), but really the only thing that’s notable about it is `select`, not `go` or `chan`.
In in some ways `go` is even a downgrade from other languages: you can’t get a handle on the goroutine and thus have to muck around with side-channels to even know that a subroutine has terminated let alone get its result.
* Go also includes the complete build system, package management (although it wasn't there from the beginning), code documentation, testing and fuzzing. Also the standard library is much more extensive than in Rust ("batteries included").
* Doctests: since you mention them explicitly, Go has those too: https://go.dev/blog/examples
* "Large garbage collector penalty": that obviously depends on your application and what you consider acceptable. I would say that in most cases the easier development enabled by having GC is worth it, but YMMV. Here's a discussion on the Go garbage collector: https://news.ycombinator.com/item?id=12042302
In my experience it's the slowest language to compile ever, and the binaries generated are gargantuan.
I was super excited to learn Rust, but that excitement is now 100% gone.
So I went with Rust and am very happy with the decision. Despite being a systems programming language, it feels surprisingly like a high-level language and I now default to programming stuff in Rust unless there's a strong reason to use NodeJS.
PS: That said, an often understated benefit of Go is that the community and job opportunities are massive in comparison to Rust (for now, at least).
Rust is a better c++. It's not appropriate for anything you wouldn't program in c++. The coding speed is slow
So if you are thinking about learning a new language to program your future apps you currently code in node, choose Go
The Rust language is a far better C++.
In practice, the compile time and binary size of Rust are out of control, which makes Rust far from being a slam dunk over C++. Crossing my fingers this will change!
With Rust, you could use it to replace the most time critical parts of your high-level program piece by piece. The learning curve is then much easier, and adoption can be gradual.
Never done it myself, but:
https://www.ardanlabs.com/blog/2020/07/extending-python-with...
https://github.com/go-python/gopy
http://pythonnet.github.io/
(Note that this is not a reimplementation of Python on top of CLR, but rather a bridge between CLR and CPython.)
The thing that makes FFI problematic in Go is green threads, which have their own stacks that nothing but Go understands. Thus, every FFI call has to arrange things to be what the callee expects, and you can't do async using goroutines across language boundaries (whereas callback-based solutions like promises work jsut fine).
Just like learning Haskel is a good exercise in understanding functional programming and lazy evaluation, which again will translate very well to the code you write as you will be able to identify pattens where functional programming can be applied.
However, neither language is really super applicable to general development, because there are hoops you have to jump through to write basic code where the language advantages are not really need, and other languages are much simpler and faster to develop in.
Golang is much more widely used for this reason, as its compiled yet features a gc, simpler to develop in with java contains a lot of good functionality in its stdlib.
https://rftgu.rs/
I've learned Rust after having used Python, and at first I had a few "wtf" moments, things I just couldn't understand.
Everything fell into place after discussing these with a friend who knows much more about the "nitty-gritty" than I do.
I haven’t learned Rust yet, thought I’m quite keen to do so, but I have an (ancient) background in C, C++ and 8-bit assembly. I don’t find that I really use much of that knowledge when I work in Go, even though Go is still a lot closer to the metal than Node.
Anything where low-level control is required. It's not clear if there are true-Rust web apps in the wild (as opposed to web apps with some services in Rust); as far as I read, Rust web programming is ugly.
The market still offers few positions, largely dominated by crypto. I have the impression that it will still take many years before the field will move to Rust (where appropriate).
> Any advice on which I should pick as a new language to learn?
Depends on the concrete goals. If you want to make a career, Golang is the safe bet, by a very long stretch. If you want to have fun, try both, and you'll naturally find your inclination, as they have a radically different flavor.
There are. I run one. Written in pure Rust. 160k lines of Rust code in total, serving over 3 million HTTP requests per month. Best choice I've ever made.
Rust especially shines when you need to maintain a big project over a long period of time. People often say that Go is much more productive than Rust, and in most cases that is true, but as the size of your project increases and your expertise in the language increases this relationship inverts, and Rust starts to be much more productive. Pick a right tool for the job.
Unless you need those extra nanoseconds of performance or super low-level features, Go will be a much better choice.
In the end, they are just tools, and you need to choose them based on your needs, not language features.
In the long run Rust's complexity will hurt newcomers(new to programming) while it will be a blessing for seasoned c and c++ devs. If all programming languages were tools, rust would be a very very specific tool which makes a lot of sense for a specific case. If nodejs and golang are tools, choosing one over another is easier as you can do same things in both easily with small effort. But you cannot rewrite all rust programs in nodejs or golang.
Finally you need to ask if rust is really worth picking over golang/nodejs for things that can be easily done in nodejs/golang. Rust is not for people who think is rust for them.
Arguments like some implementations are more elegant in some other language can always be brought up as arguments. They should only be taken into account when you run out of options to compare because they are exaggerated and subjective most of the times. For example(exaggerated) screaming why go doesn't have a borrower checker like rust makes no sense because go is garbage collected. For many people seeing such absence of features equate to lack of features in a programming language leading to more boilerplate or other downsides which is not necessarily true.
That said, I feel that Rust is likely the winner long term. So I'm still building my rust skills, but programming personal stuff in go.
Interesting; why do you think so?
At first glance this looks as if Rust would be more at home with polyglotism, but the typical Rust complement would be a hot performance critical part of something much bigger, and this is already deep in the realm of strategical commitment (all the not so hot parts have to buy in). Whereas Go often enters the picture in isolated one-shots and can grow from there.
I learned Go by reading The Go Programming Language. It's a bit old, but a very good book nonetheless.
I see Rust as more for people in systems programming who want improvements over C, rather than a desktop developer looking to learn something new. There's a lot of hurdles that you only really appreciate if you've come from an unsafe/low-level background
Here, Rust has officially climbed past NodeJS on the "cool" ladder. Let's rejoice, and welcome our fellow programmers into our communities !
And spite of some other comments, I found writing web servers in rust okay, and I think go is also fine for web services. And with go it also feels a bit like python when using other libraries, I don't know where to start. While rust with cargo is more similar to the npm experience
One of the reasons I started thinking which language to pick is when I started diving into web3 development. It seems like there is a trend into either using Go or Rust or both in some of the ecosystems. Think Tendermint, Cosmwasm, Solana, etc. While it makes sense to just learn both languages, I don’t think I have the mental capacity to learn both together quickly. It might work better to learn the one that has the most potential in the long run based on the trend.
TinyGo is an LLVM based compiler that targets microcontrollers but also has a WASM target and that creates considerably smaller binaries, but it doesn't fully support all of the Go standard library.
Never tried it, though :)
Beyond things like borrow-checking; the language introduces a LOT of concepts that are quite foreign. Exposing yourself to them is good; because I expect that future languages will borrow heavily from Rust.
Go is a great language for the short term but I don't feel like it brings Anything unique or interesting to the profession. its only real advantage is that its quick to learn but there isn't much substance. Its a great language if you're the type of person who doesn't mind copying large reams of code to change a few lines for a new purpose.
Deleted Comment
If you can afford GC in your project go for Golang else Rust.
For example, generics in Go were criticized by some, praised by others.
You have the feeling that you can freely share your opinion in the go community without the risk of being harassed by the rest of the community.
In the rust community, just like a sect, everybody must say that everything is just perfect.
Passive / aggressive attitude is something I've seen a lot in the rust community.
I would suggest that if your plan is to learn C/C++ next, and you never really understood memory issues && pointers, then rust is a perfect choice at first.
I'm planning to learn Go next, I don't regret learning rust, I learned lots of things with it.
That's just not true.
Rust got already adopted by lot of either big or interesting to work at players (Amazon, Microsoft, DropBox, ...?) and, while anecdotal, I myself get also paid to program rust.
> the community is toxic. > In the rust community, just like a sect, everybody must say that everything is just perfect.
I often get the opposite feeling with all the diverse and lengthy discussions about how to do things, e.g., like getting async stable a few years ago or long blog articles of core contributors that state "we can do a lot better here and there" in public blog posts that get shared on /r/rust and don't get shunned.
How so? I've seen the random drama crop up here and there, but it always seemed to mostly be about the "political" side of things, as opposed to the technical development.
What few interactions I've had with library maintainers and the tokio project have always been positive, and the people always seemed helpful.
The Rust community has been the friendliest PL community I've seen so far.
As of today, indeed.com lists 1,500 remote jobs mentioning Rust vs. 4,018 jobs mentioning Golang. That's not so bad. (However, there's no way to tell how many of those listings are Rust-specific as opposed to polyglot job descriptions.)
> Also, the [Rust] community is toxic.
Speaking slightly humorously, if you think Rust community is toxic, try expressing your dissatisfaction with Swift or Apple in the fanboi Swift community (controlled by Apple employees) and see what happens to you :).
I think "somewhat dogmatic" would be a more accurate description of the Rust community, IMO.
For example, I recently had a discussion about `enum` being a poor choice for what Rust makes it to mean from a C/C++ developer's point of view (which are Rust's main "replacement target" languages). The closest I got someone to agreeing with me is a sentiment along these lines "well, `variant` would may have been a better choice but it's not very familiar to C/C++ developers and, besides, when this decision was made, Rust had a hard limit of 5 characters on keyword length".
I've found the complete opposite, Rust communities are the least hostile programming environments I've come across.
There's also a huge amount of irony about saying a community is toxic on this site
If I could use Cargo/cxx_build as my C++ build system (which I think may be possible, but I haven't seen a good example), I would fully embrace rust & start incorporating it into my professional work today.
I'm only three chapters in, and it's definitely the most enjoyable technical reading I've ever done because you learn so much, so quickly, and so easily. Steve Klabnik (co-author of "The Rust Programming Language") says it's the book to read after going through "The Rust Programming Language", and I couldn't agree more.
I would add though that I can see how it can be a pretty challenging read depending on prior experiences. Even then I believe it makes a lot of sense to read through it to at least get exposed to some topics and be able to recall later that you've read something about it when you need it.
Even in the first three chapters for example, if someone isn't familiar with memory layout in C, or the stack/heap distinction, ..etc, it can seem a bit complicated I think.
I also really like this quick introduction. https://fasterthanli.me/articles/a-half-hour-to-learn-rust
You won't "learn" rust by reading it but you get a pretty good picture of the basics in my opinion.
Maybe someone more experienced can rate these as i don't have comparisons yet.
I'm still very much a Rust beginner, but I've managed to build a couple of useful tiny projects and to hack a feature I wanted into someone else's big 'ol codebase!
¹https://www.oreilly.com/library/view/programming-rust-2nd/97...
I learned the basics of Rust on a long plane ride with no WiFi. What a great way to pass the time!
“The HTML format is available online at https://doc.rust-lang.org/stable/book/ and offline with installations of Rust made with rustup; run rustup docs --book to open“
More importantly, it has a “next page” arrow at the bottom right, and a TOC pop-up at the top left of the page.
rustup docs --book
This book is very much under-rated. If you've unsuccessfuly tried to learn Rust by reading "the Book" cover to cover, you might try reading Programing Rust in the same way.