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 !
81 comments
The answer depends on who you are, what you've done, and what your goals are. Developing a Rust skillset is absolutely an investment-- but is it a worthwhile investment for you?
To rephrase Dowwie's point: It's an investment. What would "return on investment" look like to you?
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.
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.
Yes. Understanding of concepts that make Rust's learning curve steep make you a better programmer regardless of which language you'll use later.
I spent around 30 minutes reading "Rust for functional programmers" [1] to get overall perspective and then around 3 hours more reading selected chapters from "The Book" [2] about borrowing, lifetimes etc.
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...
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...
[deleted]
Learn both, Rust is a great general purpose language that can be used to build almost anything. Go is a great general purpose language that can build a nice set of things.
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.
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.
Yes, on the performance side of things, Rust is blazing fast, but the learning curve is hard though, that's why I'm wondering if it's really beneficial for me as a programmer especially in the long run, since it's not used widely in the moment.
> I'm wondering if it's really beneficial for me as a programmer
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.
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.
It is worth learning about it, the biggest part of the learning curve is learning how to right programs better using the language guidelines. I use it daily and it has been a wonderful tool in the toolbox to improve performance, reliability and security of our systems and low level processing systems. You will more then likely still need to use C and C++, but learning Rust will help you program better in C and C++ along with other languages as Rust can call those C and C++ based programs.
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
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
What resources would you recommend for a beginner programmer with no experience of C or C++?
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.
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.
If this is a career thing, it's usually better to be an expert in one language than an amateur in a dozen of them. Try them both, proceed with the one you like best, because in the end, you will be judged by what you produce with it.
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.
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.
I absolutely agree with you that it's usually better to be an expert in one language than an amateur in a dozen of them.It's not really for a career thing right now, but I like to expand my knowledge especially in systems programming languages, but if Rust become widely adopted, I will be more than happy that I made the right decision to learn it.
If by systems you mean drivers/kernels/etc, that kicks Go out of the running anyway.
If you are a C++ programmer, learn rust.
If you are a C or other programmer, learn go.
If you are doing this for job prospects, pick go.
If you are doing this for job prospects, pick go.
Can you explain please why is that ? btw I'm coming from a JS/Node background, but I worked with C and C++ before (mainly school projects, nothing serious).
Maybe I can try to chime in:
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.
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.
Rust isn't about advanced OOP at all. It is heavily inspired by functional programming.
No offense but your commentary is on the verge of being just misleading. Rust is not OOP and go is definitely not a replacement for node.
Rust and OOP are no more related than Go and OOP. What "advanced" OOP features of Rust are you talking about?
Then I must have gotten the wrong idea.
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?
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?
No!
- 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".
- 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".
You make it sound like OOP is an inherently bad thing, and OOP is not mutually esclusive with FP as you seem to imply with your Haskell reference.
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.
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.
Objects are parametrizations of functions that possibly close over variables. Having types with functions defined in types with dot notation is a different thing.
Have you ever used Rust? it is not object oriented at all. It uses Traits (kinda like interfaces) for generic programming.
If you don't know, please don't muddy the waters.
If you don't know, please don't muddy the waters.
> That said, IMHO, Go to me feels more like a replacement for Node more than a replacement for C.
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.
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.
I don't mean to imply that it was designed with that goal in mind (for all I know, the date you are quoting still leave ample opportunities for "cross-impollination"), but for day-to-day usage, every service that I would have written in Node in the past, I'm now writing in Go.
That, at least for me, feels not as much the "obvious" choice for C programs.
That, at least for me, feels not as much the "obvious" choice for C programs.
learn both until you know which one is your favorite.
I think learning both languages to figure out what's my favorite is a bit hard to do, I don't want to actually learn some basics then switch to another language to explore.
Learning and using multiple languages is absolutely vital to being able to choose the right tool for the job. You have time to learn both and switching is a necessary skill if you want to program professionally
> to learn both and switching is a necessary skill if you want to program professionally
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.
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.
My advice is sound for anyone working as a programmer because it gives them more options. Many of those Java/C# devs are stigmatized in a mold and will have more trouble applying to jobs outside large enterprise.
My last job was for a small startup.
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.
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.
yes
Forget about the language. What kind of systems do you want to build, or want to learn to build? If it is networked systems, Go gets the job done pretty well. If you want to build a game, or want a superior c++, go for Rust.
> If you want to build a game, or want a superior c++, go for Rust.
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.
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 feel that it has a good and growing game dev community, but all the tools and engines need more time in development. There are a few game engines and frameworks being built with rust, but (someone correct me if im wrong) they all either dont have a stable api or have bugs which i wouldnt want to have in production.
I do think Rust is an ideal languange to build games in though. It just needs some time.
See http://arewegameyet.com
I do think Rust is an ideal languange to build games in though. It just needs some time.
See http://arewegameyet.com
Both are great languages.
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.
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.
To answer your question, it would be good if you indicated what your experience is already and what you want to do!
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, ...).
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 write modern C++ as my day job and work on mobile apps in swift/objc/kotlin/dart, and services in python for fun on the side.
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.
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.
What are your goals? Are you trying to find a job, get into some sub-field of development? Do you have some particular thing you want to build? Or just satisfy some personal itches?
Learn a lisp like Clojure/Clojurescript, or a functional language like Elm or Haskell. Learning a lisp is quite mind opening.
Many things are worth investing in, if you justify it.
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.
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 advice would be to not just focus on a use case, but actually have a small "starter project" in mind that you can prototype an MVP for.
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.
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.
Go is a much, much easier language to learn; it's one of the easier mainstream languages to learn.
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.
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.
I've written fairly complex projects in both languages, but have a great deal more experience in go. I think tptacek nails it with this advice: go is much easier to learn. One of the things i really like about it is how easy go code is to read coming from almost any language.
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.
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.
If it's for learning, learn both. They teach you different models of thinking. As far as pure knowledge, Rust probably has an advantage. If you're looking to get things done quick, or for employment, Go would be the safer choice today.
I'm guessing Go is the more marketable skill. I imagine learning both would make you better at both, too.
> I'm really struggling between going for Go or Rust.
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?
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?
Depends on what you're doing. If you're doing web backend stuff, use Go. That's what it's for, and it has solid libraries for that because Google uses them internally. Go is reasonably easy to learn - it's just not that big.
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.
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.
No language has ever "killed off" any language as popular as C++. Perl isn't dead yet. C hasn't even killed COBOL and Fortran.
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.
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.
I have written non-trivial code in Rust and Go. The thing about Rust is that it needs a bit of perseverance and experience of writing a bit of non-trivial code in Rust to really appreciate it. Writing tutorial like code won't cut it.
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
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
I recently started using Go for a bunch of small services a new product needed. I was amazed at how easy and fast it is to get up to a point of high productivity in Go. The language is really straight-forward to begin working in. Probably the most fun I've had learning a new tool in many years.
[deleted]
What does "error management story" refer to in the second pic?
For some time the dominant error handling way was 'error-chain' crate and the comment was made in that context.
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.
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.
Note that if verbosity of error handling is a problem for you, you definitely should not use Go.
> Good, bad and the ugly: https://imgur.com/udNcZXa
What does "Development experience is very intense" mean?
What does "Development experience is very intense" mean?
An example:
So suppose you have the following pseudo code:
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.
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.
Thank you!
Having thought about this myself; the main thing I would note is that I am seeing more and more companies start to write things in rust. It seems on a definite uptrend.
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)
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)
Yes, it is worth investing in learning Rust. As is learning Go. Which depends on what you want to learn and what you already know.
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.
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.
I my humble opinion, Go and Rust will be the go-to programming languages for system software. Go has an edge, but Rust has its own strengths. Go is easier to get productive than Rust.
( But Rust has generics :) )
( But Rust has generics :) )
Don’t see anyone asking why are you learning either?
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.
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.
I don't know Go, so I cannot make a comparison, but studying Rust has been very useful to me as someone interested in the principles of programming because it forces you to think deeply about pointers.
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...
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...
Could I have a tangential question: I did learn what is Rust for, but if there is a steep learning curve, it is that much better comparing to C++? I worked about 15 years professionally in C++, it's a solid language, and it is used by many open source projects and companies as well. You can also do "anything" in it, like in Rust, and the abstractions don't incur performance penalties.
Are you one of the three people in the world who can write C++ code without security holes? If not, I'd say it's worth it. That was half joking. :)
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.
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.
Yes the second point is exactly what I was getting at - how exactly is Rust so much better that it justifies to learn it instead of C++. (but I don't imply it isn't, just curious to see some real points).
AFAIK, the design goals of Rust are better security and correctness in general, than C++. Have you looked at Rust and decided that it does not achieve that goal?
If I'm starting my own project, then I can pick the language that I think gives me a better shot at security and correctness. If Rust is better than C++ at that, and if that's my criterion for picking a language, then knowing Rust opens new doors for me.
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.
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.
Clojure and Datomic.
Is it that big of an "investment" that you need to agonize over it? Flip a coin, learn whichever one. Then assuming you're not currently dying of cancer and don't get hit by a bus etc., learn the other one next. You've got plenty of time.
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.
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.
Think of Go as a better Python and Rust as a better C. Which type of programming do you do more?
Rust is harder to learn but solves some harder problems and arguably you'll learn more valuable concepts as a result.
Rust is harder to learn but solves some harder problems and arguably you'll learn more valuable concepts as a result.
I think that anyone using even intermediate Python features is going to find moving to Go a bitter pill to swallow.
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.
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.
> Think of Go as a better Python and Rust as a better C.
That's an interesting position, because the Go designers specifically intended for Go to be a better C.
That's an interesting position, because the Go designers specifically intended for Go to be a better C.
> 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.
So what? Go is not a better C. The C interop overhead by itself is proof enough for that.
This looks like a Perl vs Python question from late 90s.
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.
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.
I really think it is about the kind of dev you want to be. Judging from your question you're early in your carreer / a student: so in order to choose between these two (I'd recommend both, by the way, or as many languages as you can, but do become an expert in one), you need to choose where you want to head. Rust is often (not exclusively) used for more low level stuff, down to firmware, where Go is generally used for higher level stuff, among others networking, web and such.
I think if you find what level of programming interests you, the tools will follow from that.
I think if you find what level of programming interests you, the tools will follow from that.