Hey, devs around the world,
I set the goal of learning Golang about a year ago. But then the Stackoverflow Developer Survey was released and I saw that Rust was a good competitor against Golang.
Now, I have some time to learn new stuff but I'm not sure if Golang should be the next language I learn.
What do you guys think about this topic? Will Rust overtake Golang? Because Golang seems never got that popular as Rust currently is and seems not the language that is needed in most business projects in the future.
Would be cool if you can give me your opinion and may a few pros and cons of your decision.
Have a nice day!
Top comments (49)
Small chance that Rust will overtake Go, but personally I find that Rust is a MUCH better designed language than Go (but with a steeper learning curve).
If you like abstraction when doing programming, or if you're interested in Functional Programming (FP) - then definitely go (pun intended) with Rust!
I've dabbled with Haskell before, and I was surprised how much Rust reminded me of Haskell (even though Rust generally isn't touted as an FP language - and it is not a full "pure" FP language by any means, but it has strong support for the main FP concepts).
Go in its current incarnation does not allow you to do FP - it even lacks generic types. You'll be doing lots of old-fashioned procedural programming ... I found it rather disappointing compared to Rust.
Two nice things about Go: the compiler is fast (Rust's is rather slow), and it has these nifty "goroutines" (Rust has solutions for that, but not as elegant as Go's goroutines).
Yes, Go is quick and practical, and productive for a certain class of systems (network apps). But intellectually I found learning Rust MUCH more satisfying than learning Go.
"I found learning Rust MUCH more satisfying than learning Go."
Really? I took a short look at the Rust syntax and got instantly headache :D I came from java to php to javascript to typescript. So i would say i love type safety and object oriented programming,
Then you're very likely to have very hard time with Rust.
While Rust do promote type safety to very large degree it's different type-safety than Java's or TypeScript's. More akin to Haskell type-safety. It's somewhat hard to wrap one's had around that.
And to large degree Rust does not provide or support OOP. Programming with structs and traits is significantly different from class-and-interface-based OOP, usual designs and patterns do not apply. Even if you do emulate OOP in Rust (which is somewhat awkward but possible) you will have hard time integrating your design with borrow-checker, libraries and frameworks (especially async ones).
It doesn't mean you won't be able to learn Rust or you shouldn't learn Rust. It just means it might require much more time and effort that it seams because you're likely will need to "unlearn" a lot of stuff.
Spot on, I forgot to mention how much Rust reminded me of Haskell ...
Yes, type safety in Rust is more based on abstract/algebraic data types, much like Haskell. It really raises the abstraction level and allows one (if used well) to write succinct and "correct" software (the amount of static analysis the compiler can do to check if your code is 'correct' is amazing).
Compare that with the banal type checks of other languages, whether you're passing in a string or an integer, and you can see that it's on a completely different level. It's elegant and powerful.
And yes, OO (especially the "classic" variant with inheritance and so on) feels indeed like a second class citizen in Rust ...
I'd argue that that's almost a good thing, I haven't used classical conventional inheritance for ages ... programming with interfaces and abstract types (and generics and so on), yes by all means, it's supported, but forget "classic" OO with its emphasis on inheritance.
Well, I'd say "plain old" Abstract Data Types and Algebraic Data Types are about the same level as an "ordinary" Java/C# type-checking (and hence type-safety). The thing is Rust doesn't stop there (not even mentioning Haskell): huge chunk of expressiveness and safety comes from advanced "type-level programming" with generics and some neat (and hard-to-wrap-your-head-around) tricks with (opaque) lifetime parameters. That's indeed far beyond the experience of a "normal" OO-developer as most OO languages lack such facilities. It's similar to what half of Scala developers do with their type-level programming (and for that the other half of Scala developers hates them).
And we still haven't even mentioned two kinds of Rust macros...
OO inheritance just don't play along with all that features. That's why one has to forget about it to fit into the ecosystem of libraries and frameworks. But then you have to learn to program (and think) without inheritance...
Yeah to me the safety and performance benefits one can reap off Rust are totally worth the troubles. But I knew Haskell when I started learning Rust so I knew how to program without OOP (and some type-level "magic" too). For someone coming from Java that might not be worth the trouble.
Though I know some people who learned Rust after just Python or as the first language and totally love it. :D
Amen to all that! Ah yes the macros, that's another powerful one ...
I definitely think it is worth the trouble for a Java programmer to learn that there's another way, expressiveness over verbose "patterns" and a 10 level deep class hierarchy ...
Having studied Haskell before Rust was definitely a good thing because I recognized so much on a conceptual level, seeing those concepts and approached pop up again in a different language was an eye opener.
And I'd argue that Rust is at the same time still more accessible to the "mainstream" programmer than Haskell or Scala.
Yes but one doesn't even need to learn a new language for that! 😂
carlopescio.com/2012/03/life-witho...
One does not need to learn a new language, ah sure, even the newest versions of Java have some FP-style stuff like filter/map/reduce and so on ... it's just that a language like Haskell (or Rust, to a lesser extent) "forces" you more into that style.
Nice article, well yes if your level of design thinking allows you to break away from "controller" style procedural thinking and towards splitting it into objects (or functions, for that matter) with clearly defined responsibilities which "do one thing" then you're also prepared to go the FP way ... that's what you were trying to say or not?
I guess what I'm trying to say is that FP is not a silver bullet. What really matters is clear understanding of the problem and the solution, and good modular and composable design.
Pure FP languages like Haskell do nudge you in that direction first, because pure functions are the most composable thing in our arsenal, second through culture and mechanisms of algebraic design. But all of that takes you only this far. If you really want to go an extra mile and produce even better designs for your programs you have to go beyond and above just language mechanisms and learn and think in more abstract terms.
But at that level particular language and even paradigm doesn't matter that much. With clear understanding of both problem and solution, and good design skills and experience one can produce excellent OO design as well as FP design or even just "structural" design in the sense of good 'ol structural programming.
I'm nowhere near that level of qualification but there are great examples of clever and clean design in all that paradigms in all kinds of languages. So if you want to become a better programmer you can do it regardless what language you use.
Though learning a new programming language in unfamiliar paradigm might be eye-opening and mind-bending experience that really helps in becoming a better developer, so I wholly approve! :D
Ah right, yes I totally agree ... yes ultimately the quality of a system is based on the quality of the analysis and design you do - and based on that analysis and design you can decide on the language, tech stack or tools you want to use - whether that's FP, OO or whatever - I'm sure that there are systems or requirements where FP would NOT be the best option, for instance a static website having hardly any or no business logic ... but yes intellectually learning another language or paradigm can be refreshing and an eye opener.
P.S. just came across this dev.to article about "String" and "str" in Rust: dev.to/ssivakumar77/rust-string-vs...
Yes, in the beginning this sort of stuff leaves you horribly confused, this is exactly what Rust's infamous "learning curve" is about. I had to read the Rust documentation pages 2 or 3 times before it all clicked, "String" vs "str" was a brain twister initially.
I didn't say OO, I said FP hehe ;-) although Rust supports OO as well.
Well yes like I said, Rust has a steep learning curve so I can imagine your initial reaction. You need to put in some time and effort to overcome that initial hurdle.
But I can promise you, until they add generics to Golang you will just be doing lots of old fashioned procedural programming there, coding for loops until you see blue in the face. No more map/filter/reduce for you, like you used to be able to use in Javascript ... that was probably my biggest disappointment about Golang.
Would love to see a Jetbrains dedicated IDE for Rust as they did it for Golang with "Goland".
Are you a VSCode user? I think VSCode works with Rust ... I've used Jetbrains products before but I've switched completely to VSCode, except for some occasional (now rare) Java work for which I use Eclipse ...
The Rust plugin for IntelliJ is fantastic, and does some things better than VS Code, such as automatic imports (my favourite feature!). VS Code is very good too however and I do like the progress on rust-analyzer.
That said, the Go plugin for IntelliJ is also really nice too.
I did the same when I first looked at Go. Coming from C# it seemed very un-intuitive. Somehow Rust makes more sense to me but not sure why really...
To me it feels like Go was cobbled together, Rust seems to be more methodically designed. And what intrigues me is the idea that Rust could be the first "mainstream" language to introduce FP (functional programming) concepts other than the obligatory map/filter/reduce to the masses, although it isn't a pure FP language by any means ... Haskell, Scala, Clojure etc are just too "niche".
I think go was not a language that was "planed" with the ulterior motives to be for the public and has to be "good". In the first, it was planned to solve google internal problems which other langs could not solve in the way that google needs it to bes solved. Compared to Rust i think was more a "planned" language for the public.
I don't think these two languages are really competitors. I've used both and I think the reasons you would choose Go are different than the reasons you would choose Rust.
It might also depend on what you want to build, and the kinds of things you value in a programming language.
I would choose Go for things at work that need contribution and buy-in from other developers (with varying skill levels). As others have mentioned Go is easier to learn, and easier to write, at least to begin with. It also has a much larger standard library and many of the available libraries and frameworks are more mature.
However I find Rust more rewarding (subjective) and more expressive. I've used several different programming languages over the years including C, C++, some Java, Perl, Python, Javascript, Typescript, Rust and recently I've been learning Go as well. Go feels more like all of the others than Rust. Rust is different in its strong bias towards correctness, safety-by-default, and trying to eliminate certain classes of bugs entirely (and actually succeeding in some cases). What I mean is that in most other languages (including Go) you can avoid bugs by being more careful, following better conventions and best practices and even then you'll still make the same mistakes sometimes and trip up. Because programming is hard sometimes. Go still has null pointers (although it's still safer than C or C++). Rust does not.
With Rust, of course you will still make mistakes, but there are some mistakes that are just a lot harder to make. Let's take a simple example using Go and Rust. Mutexes in Go, just like other languages, require you to make sure you remember to lock and unlock at the right times, and make sure you never access shared data outside of the mutex. Otherwise you will get data races and/or crashes. The language won't tell you if you forget. Go will not stop you from accessing data behind a mutex without locking it.
But with Rust you cannot get access to the data without first locking the mutex. That is because the way to get access is by calling the lock() method, and that returns the value. And Rust's borrowing rules mean that the returned value is only accessible within the scope of the mutex lock - so you cannot get it wrong (there are ways around it but you have to try really hard to break it). This is just one example but there are many cases like this where Rust really goes a step further to prevent you from making mistakes. It is a different approach to safety and correctness than with most other languages. This also makes it more difficult to learn, and in Rust you find that you often spend longer writing the code and a lot less time debugging afterwards.
You could (and should) build similar mechanisms in Go and other languages to make it more difficult to make mistakes, but that job is left to you. My recommendation is to learn Rust first, and then learn Go afterwards. Learning Rust will teach you much more about memory models, data structures (and how they allocate memory or use cpu), and safe programming practices, and then you'll be able to more easily spot common mistakes in other languages and code more defensively to avoid them.
Go looks like a really useful language to learn (hence why I'm learning it too) but I think Rust will teach you more. Just my opinion. Learn both ;)
Great explanation, spot on about Rust's built in "correctness" - with Rust the compiler can check/validate a LOT more than other compilers that I know of, so with Rust "if it compiles correctly" (i.e. if it compiles at all) then you can already be a lot more certain that it will also run correctly - that's a pretty unique capability AFAIK ...
P.S. regarding "I don't think these two languages are really competitors" - I've read that often, and in general it seems true, but in my opinion it would be interesting to try and use Rust for the same sort of things which Golang is typically used for - let them compete head-to-head instead of within their own "niche"
Thanks for that really detailed answer
Hi there! I'm a moderator here at DEV and just wanted to let you know that I added the "discuss" tag to your post to increase visibility! :)
I looked at Go and to be honest, I never really liked it.
Coming from Ruby (and other dynamic languages), experimenting with Elixir, and then discovering Rust I don't think Go has anything to offer to me.
I know that Go wants to be a pretty boring language, but that also means to not have things which makes me considering to jump from dynamic to static typing.
No generics? Why?
Interfaces? What is that even for a concept in Go? Rust's trait/impl patterns make it more obvious to me, that something relates to each other, in Go I have to connect the dots myself (or let the compiler yell at me).
GC? I have that in Ruby and JavaScript already, no need to switch then. (And if you care and need raw speed with predictable throughput, you maybe do not want GC anyway.)
And some of these syntactical patterns.
if err != nilor maps (m = make(map[string]int)). Someone said they get headaches when looking at Rust code, I have the same but for Go. 🤷🏻♂️Also (compiler) error messages. Not great when it comes to Go. While Rust being harder to learn, the messages are extremely helpful there, and the developers try to improve them constantly.
Go also repeated still some mistakes of the past; for example the unicode string story in Rust is so complex for a reason, not because of the language, but because strings are complicated. And this is true for other areas where you think Rust makes it too hard on you. Go (and most languages to be fair here) do not really care about that.
Though Go has goroutines and channels, you still have to be careful when programming concurrent stuff. Have read some stories about how easily you can shoot your feet when not paying attention.
The dreaded null pointers are still there, because Go has
nil, and it is equally "broken" as I know already from the dynamic languages. (Rust avoids this problem with specific types like Option and Result, so you also have to handle the fallible cases, but more explicitly, on the type level, no random "nil" or "null" pops up where you wouldn't expect it.)I could dig up more weirdness about Go. And it is just my opinion. But even though Go and Rust are both pretty young languages (initially created around the same time), Go overall feels like an old language, as if it was created in the 90s.
Don't get me wrong, Rust is not a perfect language. And it has its own quirks and weirdnesses. While some of them will never change, others are constantly fixed and changed, and comparatively fast. (A release cycle of 6 weeks might help here to quickly move forward.)
This is an interesting statement. What do you mean? In my bubble I still see a lot of Go. For example if you work in DevOps and/or use containerization (Docker) + orchestration (Kubernetes, terraform), you cannot really work around Go that much, as most of the foundation was built with it.
Also I've seen people in companies redoing some JavaScript stuff in Go. Probably hoping to get more out of it, though the wins might not be as much as anticipated.
As far as I can see, Go is competing mostly in the web/networking domain. And there you find mostly JavaScript, Ruby, Python, or other usually dynamically typed languages, which slowly over time get some kind of stronger type system (gradual, optional, or like via TypeScript), as well as JIT and other performance improvements. And plain (request) performance/speed is not always the primary goal. In businesses you make trade-offs on so many levels, even if Go would be appealing, there might be still reasons not to use or switch to it.
The last reason also applies to Rust, too, of course. But I currently see some niches, where it shines, my current focus area being embedded/IoT. And for unknown reaons the blockchain folks seem to love Rust as well. 🤷🏻♂️
I don't think so, they operate in different areas most of the time. People want to see them as direct competitors, but they're really not. (Usually Rust is seen more in competition with C/C++.)
And no matter what my personal preferences are, language plurality is better than this One True Language. Which will never be a thing.
So, sorry for my ranty response. Definitely make your own picture of the story.
In the end: learn both if you want. Use both where you feel they are best suited. And don't listen to surveys or us! 😅
"And some of these syntactical patterns. if err != nil or maps (m = make(map[string]int)). Someone said they get headaches when looking at Rust code, I have the same but for Go. "
Total agreement here...
The blockchain folks use Rust because they can’t afford security issues resulting from memory mgmt bugs, alá buffer overruns.
Different use cases in my mind and the key difference is around garbage collection.
I wouldn't build anything that needs ultra-smooth performance in GoLang. Say, a game engine, for instance. You need to manually manage your garbage collection when you are trying to draw your frames.
This is the other aspect. Where do you want to go with your development career? Search jobs with each language and see what places have been hiring recently. You'll see where Rust and GoLang are used the most. For instance, if you like DevOps work, Go will be the choice for sure (with some Python). Do you want to work in IoT at the chip level, Rust is going to be a path there.
Now, if you are interested in building mobile apps, Netiher will do many favors. Same for RESTful or GraphQL APIs. Yes, they are both super fast and can build highly performant services. However, other languages with rich, battle-tested libraries will probably net a faster development with more tooling for testing and deployment.
Finally, GoLang vs Rust popularity is subjective. I have seen GoLang used in production in MANY places. I have witnessed Rust in production only once. But, I'm not omnipotent.
Great advice for looking at the job postings. Golang is for sure here to stay within Devops roles. Rust has growing demand in key use cases. It still feels to me that Rust will be very niche for the long term, but in critical need.
"I set the goal of learning Golang about a year ago. But then the Stackoverflow Developer Survey was released and I saw that Rust was a good competitor against Golang."
I would try to avoid this status game as there will be something always overtaking something. Which language is #1 is a zero-sum game.
If you want to have a positive sum game, learn both. You'll discover that each language has it's place and solves a some problems well and other problems poorly.
OK, I personally would take Rust over Go any day. Even more I'll never touch Go again at least until they release Go 2. BUT! That doesn't mean you should prefer Rust over Go.
Usefulness and relevance of programming languages almost entirely depends on the domain you work in. If you're a DevOps Engineer Rust is almost entirely irrelevant while Go very relevant as a number of tools (Docker, Etcd, etc.) are implemented in it.
In a sense of "the language that is needed in most business projects in the future" both Rust and Go are irrelevant. The languages are PHP, JavaScript, Java, C#, Python in some order and some combinations.
Pretty much the only area where Rust and Go compete at all is development of (somewhat) high-performance low-memory network services. But even in this area they occupy rather disjoint "ecological niches".
From the Programming Language Theory point of view Go is a joke, it just ignores last 40 to 50 years of PLT research, while Rust is a decent language incorporating some theoretically strong aspects and making them work in constrained practical setting. But that aspects might be completely uninspiring and uninteresting to you.
So like always if you want to invest your time and effort with maximum benefit you should consider your (career) goals and future fields of work.
I don't think you can compare Rust and Go. They are different languages with different targets.
However, having used both for a long time, I recommend learning Rust. I really enjoy writing Rust code and everything feels so safe and fast. Generics, type safety, nice error handling and null handling are just some of the features of Rust you will love.
Rust has a steep learning curve but after reading "the book", as we call it, you will have a good understanding of how to use the language.
The Rust compiler, as someone has already wrote, isn't as fast as Go's and the borrow checker can be annoying at times but you will get used to it soon.
I think you meant generics not genetics.
Yeah, thank you.
Rust, hands down. To me, Go looks like some duct taped futuristic C written in the 80s. I understand why this is the case, but Go's simplicity to me is more like tying someone's hands than making things simpler.
On the other hand, Rust provides a solid set of features and some very powerful features on top of that like traits and macros.
Exactly, I noticed that the compiler validates and enforces a LOT (that's also why the Rust compiler is slower than the Go compiler, it simply does more) ... if you program in a certain way in Rust and you program it "right" then you can almost be sure that it runs "right" - to a certain extent