Ask HN: Is it worth investing in learning Rust?
I'm interested in your feedback regarding my question,In my case, I'm planning to learn Rust, but I'm really struggling between going for Go or Rust.
Thanks !
Life-cycle of a Rust developer: https://imgur.com/kNkV7jm
Good, bad and the ugly: https://imgur.com/udNcZXa
With Go, in my head it is best explained in terms of the scene in the movie: Pursuit of Happyness
Boss: Chris. What would you say if a guy walked in for an interview, without a shirt on, and I hired him? What would you say?
Chris Gardner: He must have had on some really nice pants.
People (including me) find lot of issues with Go in terms of some choices in the language. But boy it does have some really nice pants and that is the ease of writing networking services + Go routines
Now there is a failure crate https://github.com/withoutboats/failure. It is an improvement, but it still feels that one has to type a lot for something basic. Now, this is a matter of taste and many people will be ok with this.
What does "Development experience is very intense" mean?
So suppose you have the following pseudo code:
x = f()
My productivity increased a lot, once I realized that there is a pattern to these and knowledge gain with Option & Result is transferrable to using Future's combinators as well. It is very hard to explain it to someone as to how to get to this state. There lies the challenge with teaching Rust and I think Steve Klabnik and team has done really good job with documentation.
If you need to, you can even use Rust to build firmware, boot loaders, kernel drivers, user mode drivers and operating systems. Basically anything that you want to run fast and have less errors Rust would be a pretty good choice to use, especially when speed, performance and app reliability is a high requirement.
I use Rust at work to help reduce error prone programs and speed up capabilities of our distributed apps (calculations and pre-processing of data from systems) that naturally run slow using their original language implementation. I use Go for writing our blazing fast web applications that provide an fast interface to our apps for our internal users.
I'm biased since I love programming in Rust, but I think learning the ownership model (the trickiest part for most people) is beneficial for programming in any language. It builds up a really good intuition: If only one reference exists to an object, or if shared references exist but they're all read-only, then that's "business as usual". But as soon as you have shared references and mutability at the same time, then you have "very interesting code". Even in a language other than Rust, where you don't need special types to let you do that, the situation probably deserves some beefy block comments where you warn everyone to pay attention.
The use of Rust is rising, especially for new systems level projects or rewrites of older programs. This is especially true where unexpected issue reduction is a high priority (high frequency trading systems, industrial systems, security systems, video transcoding, packet switching and routing systems, video monitoring systems, virtualization and emulation, web servers, other embedded etc.)
I would recommend getting started learning Rust by having a few projects. I would recommend starting off by building a multi-threaded web server. https://doc.rust-lang.org/book/second-edition/ch20-01-single... See how many concurrent clients it can handle and make adjustments to increase it's max capacity. After you have done that I recommend building your own daemon to handle log parsing and analysis from your web server to give you a nice table of stats. To spice thinks up I would recommend trying to do this without the dependency on external resources after you have downloaded all the resources you need: https://doc.rust-lang.org/cargo/reference/source-replacement... https://crates.io/crates/crates-mirror then try to build the projects.
You can also do some much needed checks on your programs input by using Valgrind and several other tools. Once you are satisfied with your program insure you use Rusts tools to also build the documentation and check your coverage: https://github.com/huonw/travis-cargo
I'm a mature student studying a computer science degree but wouldn't say it's providing anything in the way of proper programming experience, though I do understand the most common data structures and algorithms as result.
The case between Rust and Go is an interesting one, as many of us have observed that the two languages seem to get paired together (for people wanting to learn).
I wanted to start learning both beyond the basics, about 2 years ago. A few weeks ago I decided to write my Hello World in Rust, and I've been hooked.
What I'd advise is for you to have a use-case that you work on while learning the language. You can spend a lot of time on the basics and std, but unless you start also picking up a few external libraries (e.g. SQL, web framework), you might find progress to be slow.
The other benefit is that you'll get more exposed to the community. It's important to know where to go when you need to ask for help.
In my case, I got comfortable with gRPC in Rust, then moved to Actix, and now (if I get diesel.rs to compile) I'm moving to SQL. Next will be "fearless concurrency", threading and futures, streams, integrating with NodeJS and other languages, etc.
A roadmap which gets one comfortable with the standard language while being productive.
My starter project[1] was a set of bindings for pandoc-types, so you can manipulate Pandoc ASTs in Rust. It's a very small library, but it's enough to plausibly do something interesting. It's also big enough to get me to play with serde and some serialization stuff in Rust. So it was a pretty good size to start with.
https://github.com/elliottslaughter/rust-pandoc-types
[1]: Technically, I did work in Rust prior to this, but it was all long before 1.0, so I had to relearn when I picked it back up.
Your thoughts as revealed by the question fall into a pattern I recognize from when I was younger, where I used to think (for example) 6 months was like this eternity, and (for another example) what I was gonna major in was super important because it would define my life for 40 years. Ha ha, I should've been so lucky! Or rather, unlucky, because reality is much more interesting. The reality is, in 10 years you'll be learning something else entirely, and when you've been at this game a while, you start to lose count of the languages and paradigms you've learned. You get so you can pick up a language in a couple of weeks, or a weekend. Each one of them is worth it, for the things you learn along the way, and the ways it teaches you to think. Any rock is sufficient for sharpening your knife.
If you really have to ask, like it's a headscratcher between the two, learn Go first and see if you're happy where you land with it. Go is the more popular of the two languages; there's not much "risk" to either of them, but there's marginally less risk for Go.
Rust is the more ambitious of the two.
It makes sense to get comfortable with go first because the time commitment to achieve basic competence with rust is much greater. Rust will definitely open your mind but it will take some time to get there.
No matter how much nerd-cred a language has, it is hard to be productive with a language that you hate.
edit: FWIW, we are commenting on a site by a billionaire who seeded his fortune by writing a program in LISP back when almost everyone else thought that LISP was long-dead and buried.
Rust is fascinating, but there's just so much stuff in there. The borrow checker is a major advance, but unless you're doing heavy parallelism or can't use garbage collection, the complexity of the language is a problem. I'd hoped Rust would kill off C++, but that's not happening.
Anyway, if Rust doesn't unseat C++, of all languages, it won't be because of language complexity. There's very little complexity in Rust that isn't inherent to the language goals anyway.
Your objectives should come first, then you figure out the tooling. Some have touched on what either is good for, but it really comes to what type of work you are doing/want to do.
In a comment, you mention that you are currently doing JS/Node work. Golang is going to be the closest in terms of use cases - it’s excellent for services. We’ve used it in production with great success, especially when you can leverage goroutines to make things happen in parallel very fast. It’s also fairly maintainable for the web services use case.
I don’t know much about Rust unfortunately.
Rust is harder to learn but solves some harder problems and arguably you'll learn more valuable concepts as a result.
In what sense is Go a "better Python"? My impression of Go is that it (by design) is extremely minimalistic, leading to simple, verbose code, that is understandable by the lowest common denominator, allowing large scale collaboration. And also it has good concurrency.
That's an interesting position, because the Go designers specifically intended for Go to be a better C.
So what? Go is not a better C. The C interop overhead by itself is proof enough for that.
If you are doing this for job prospects, pick go.
Go is not an OOP language, you get the dot notation on structs and that's pretty much it.
Rust is all about advanced OOP and very fussy static type checking.
That said, IMHO, Go to me feels more like a replacement for Node more than a replacement for C.
I saw a few examples of Rust code with a good amount of generics sprinkled in and given what (seemed to me) the parent comment was suggesting, I assumed that was the case.
That said, I remember reading in the docs about many usually OOP related concepts like RAII, boxing/unboxing, operator overloading, the aforementioned generics.
You mostly don't care about these things in Go. Can we agree that Rust is a bit more OOP oriented than Go at least?
- Parametric polymorpism isn't OOP, pretty much every halfway-decent language has it (including Haskell, which is as functional as they come).
- Boxing in Rust isn't what you think it is - it's just heap allocation (more like malloc than the monstrosity that is boxing in Java).
- Again, operator overloading isn't OOP either. Seriously, is it that hard to believe that "you get to use + and - with your own types" is an expectation independent of any paradigm?
> I must have gotten the wrong idea.
Yes. Go and Rust are both very far from what most people would consider "OOP".
Funcional can be considered an alternative vs imperative and declarative, and usually languages are a mix of the three. And any of these 3 style can support OOP.
BTW, plenty of half-decent languages don't have generics.
If you don't know, please don't muddy the waters.
Except the first release of node was May 2009 and the first announcement of golang November 2009. Node was also first showcased in November 2009.
So for me golang cannot be seen as a replacement for node just from chronological order. Also their design goals at the time seems very different.
That, at least for me, feels not as much the "obvious" choice for C programs.
I think if you find what level of programming interests you, the tools will follow from that.
I learned Golang about 2 years ago and have done a small web app in it to understand and learn about the libraries.
I recently started reading the Rust book and its an eye opener. Its important to understand how the language is designed and with Rust, its different concepts compared to Go. I would suggest to read the documentations/manifestos of both the languages and decide to go ahead based on what you want to do.
Community and ecosystem is an important requirement when choosing a language.
So there is quite possibly work for you in the field, especially since its emerging, you could be in early.
Having said that golang is also on the up and up and probably currently there is more work I would guess; but obviously also more competition.
Lastly; to the average person like myself who is half-sysadmin half-developer (I'm not a software engineer, but I can read and write many languages "well enough") -- Rust is definitely more complex from my small amount of playing both in Syntax and basic things you need to do to "get started" -- I am sure these would evaporate quickly once you actually learn it properly early on but if you have little other language experience you may struggle with it a little as a 'first' language. Where-as go feels a little more script-like and a little easier to "bounce off the walls" in early learning.
So; is it worth learning? IMHO, yes. Is it the best choice? That may depend a little on your previous programming experience and what job market you are in (for example probably easier to find an onsite job doing rust in Los Angeles, USA than Perth, Australia)
Back then Perl had a huge traction, mostly from sysadmins. Python got traction from web backend, and systems (redhat used to have a good python conde for starting-up servers).
I think both Rust and Go will coexist un different industries/use cases.
IMHO the killer app/use for GO are lambdas/cloud functions because they are cheaper to execute than python.
For Rust, I expect to see someday a unikernel that boots an app into a VM/light container.
If you want to pick a skill to put on your CV I would recommend Go.
If you want expand your knowledge of programming paradigms I would recommend Rust. As a side note you will also be able to put it on your CV.
edit: for the down voter, what boundaries in language design did golang push? Unlike Rust with its unique memory management?
I like to learn languages like building a toolbox. I try to pick up popular, well known tools that don't have a ton of overlap with my existing tools. My go-tos: Java, Python, and C can get you pretty far. Go is a great statically compiled, GC language, with decent memory layout control and with a good concurrency story and a nifty type system (coming from Java). Rust has novel borrow-checker that's probably worth learning and seems to let you solve tasks suited for C but with more structured types and a better/simpler multi-threading story.
Does Rust have the libraries, frameworks, engines, and communities for developing games? In my opinion, development of any software, whether it's a REST API or a AAA 3D game, isn't just about the language but is actually about 10 other things.
I do think Rust is an ideal languange to build games in though. It just needs some time.
If you’re interested in building a game engine then C++ will have the most resources.
( But Rust has generics :) )
Just my opinion (given my own experience and goals; if your experience/goals are different the below may be irrelevant):
As a constant waverer, my answer to the "Go or Rust" question was, after much time, "no".
Instead I'm returning to C++ and trying to learn how to use modern C++ idioms and finding this very productive.
It's a bit frustrating, as C++ is a bloated mess of a language with way too many dark corners, but good discipline can allow you to use a version of it that is really nice. As someone who learned C++ in 1992 (when much of the language wasn't even really there yet) and has only fitfully engaged with good C++ practices over the years, the payoff from learning new parts of C++ has been really much better than a new language.
Plus, neither Rust nor Go are particularly mind-expanding if you're a native C++ speaker (as compared to Python, Prolog, Forth, assembly, Haskell, Lisp, ...).
I don’t know if it’s just cuz I code modern C++ so much, but I’ve learned to love c++, even when compared to much easier and theoretically more productive languages like swift and kotlin.
There is a hoard of professional Java or C# developers that invalidate the idea that you need to know more then one language to program professionally.
While this might seem odd to a hn reader, where there is weekly blog posts of comparing languages or trying out the new shiny thing at a startup.
One need to remember the audience is single digit percentile of the computer industry. The rest of the industry actually use jdk or .net in the enterprise.
They used Java. The rest of my programming jobs, -large and small, has been either Java, PHP, .Net and once a bit of Delphi. Lately there's also been a lot of TypeScript.
There's been a few jobs I wanted to apply for but couldn't because I'm not good enough with C/C++ and Qt.
Maybe things are different in Silicon Valley but around here the most exotic language I see is Python.
Knowing a new way to think about code? Rust is probably worth it for that, even if you never actually use Rust much. Go is less of a new way of thinking.
Increasing your ability to get hired (or you paycheck when you do)? I'm less clear that you'll get paid back in those terms. Go might be a better bet.
Scratch the itch that you like learning new things? Well, if you learn Rust (or any language), sure.
In C, pointers are used for many different things: they stand for arrays and strings (which IMHO is a questionable choice); they are used in types where the structure of an object changes at runtime (linked lists, trees); they provide a way for different parts of the program to refer to a common state; they allow subroutines to modify objects 'owned' by calling routines; they provide a cheap way to pass big structures as arguments to subroutines even when they won't be modified; they provide a way of incorporating large structures as elements of other structures which allows replacing one value with another without a full copy.
Some troubles with pointers are specific to the ways that C uses them: manual memory allocation means that you can use before alloc or after free; the NULL value means that you can dereference an invalid pointer; pointer arithmetic means that a valid pointer can be used to produce an invalid pointer. At possibly some small runtime cost we can eliminate these problems.
But there is one unavoidable problem at the heart of the use of pointers. When you are referring to something with a pointer, are you doing it just for convenience, to avoid copying large structures; or are you doing it to share state with other parts of the program? Things will go horribly wrong if you end up doing the latter when you just wanted the former.
Rust's type system is an attempt to keep track of different uses of pointers to catch such errors without compromising on efficiency. There have been other attempts ([1],[2]) but Rust finally has a rich enough language and library to attempt writing serious programs in.
I think it will be interesting to see whether the authors of such programs find the mental effort of keeping the borrow checker happy worth the efficiency gains of using pointers for both purposes on an equal footing, or whether they fall back to the extreme models of Python (and many other languages) where everything is a pointer which shares state or that of Haskell where there are no pointers by default and one has to switch to a explicit and cumbersome syntax (using the IO or ST monads) when one wants to use shared mutable state.
[1] https://en.wikipedia.org/wiki/Substructural_type_system [2] http://pauillac.inria.fr/~fpottier/slides/fpottier-2007-05-l...
The half serious answer I can give is: Do you have a job offer you want to take or at least a solid plan how you can use it professionally? There are so many C++ jobs, that you can most likely find another one that meets all your other requirements (location, salary, domain, etc.), should you decide to leave your current one. I don't think that is the case for Rust yet (But I'm rooting for it! :)
The second point is also my answer for OP.
If someone hires me to work on a project, in the current state of affairs, they're much more likely to have picked C++ than Rust, and I don't get the choice (other than choosing whether to take the job). Rust doesn't (yet) open that many doors for me as an employee.
Then I managed to write a simple program which reads a password from stdin, applies scrypt KDF to it and prints the result in hex encoding. It took me less than 2 hours. Mostly I just tried to do something, and when it didn't work, I'd find a solution for my problem on stackoverflow or r/rust. Compiler error messages were also quite helpful.
So I managed to write a useful (for me) simple CLI application in 1 day. The next day I added option processing (salt, scrypt parameters), split the code into functions etc. I didn't encounter any problem which I couldn't solve in under 1 hour. The biggest struggle was trying to return a reference to local variable from function, and it was covered in [3].
TLDR: don't try to master the language, just give it a try for a few days, writing a simple program.
[1] http://science.raphael.poss.name/rust-for-functional-program...
[2] https://doc.rust-lang.org/book/
[3] https://bryce.fisher-fleig.org/blog/strategies-for-returning...