DEV Community

Atomzwieback
Atomzwieback

Posted on

Golang or Rust, that is the question.

Alt Text

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!

Latest comments (49)

Collapse
 
lexiebkm profile image
Alexander B.K.

I am learning both. It is nice to see they provide struct and pointer. But I feel more encouraged or challenged to learn things like traits, generics, how method is implemented, memory management via ownership in Rust.
On the other hand, I still need to learn Go because there are a few job requirements for it. When it comes to compiling, I certainly prefer Go. Also for web backend development, there are more interesting frameworks to be used such as Gin, Fiber, Iris.
As for database connection, I like that Go provides standard package that proved to be easier to use than the likes of Diesel for Rust.
Therefore, at least for me :

  • Go will not rust
  • Rust will not go

Btw, I am also still learning (relearning) both Java and C/C++.

Collapse
 
kwinz profile image
Name • Edited

They are not competitors. They are almost opposite of each other.

Go is a simplified, garbage collected language. Because of its simplicity it is suitable for beginner programmers. And for security critical applications.
Also it allows you to quickly write services and stuff like FUSE filesystem code.
It might be a step up for Python programmers that are looking for a faster language.

Rust competes with C++. It is basically a C++ that get's the defaults right. I brings many influences from languages like Haskell. It has a steep learning curve. It spends a lot of effort on getting manual memory management right (borrow checker). It is almost the complete opposite of golang.

Collapse
 
lexiebkm profile image
Alexander B.K.

Yeah... I see Rust is like a modern C++, although it is not OOP by traditional definition. Whereas Go is like a modern C; the fact that Ken Thompson is one of the trio who created Go may validate my viewpoint.

Collapse
 
gogi2811 profile image
gogi2811

How did you learn Go ?what are refrence material do you have?
Would be great if you could share as I am also starting in learning Go for next 6 months.

Collapse
 
atomzwieback profile image
Atomzwieback

Probably the best resource out there is this:

quii.gitbook.io/learn-go-with-tests/

Collapse
 
gogi2811 profile image
gogi2811

Awesome

Collapse
 
misobelica profile image
MiΕ‘o

Recently I read a good article from LogRocket, maybe will be helpful for you :) blog.logrocket.com/when-to-use-rus....

Collapse
 
0x64796c616e profile image
dylan

As someone who has done a professional foray into Go, and a side project foray into Rust, I found Rust much more generally practical to a variety of solutions. I feel it also has aided in my thinking process when programming - like I learn more about programming as I’m learning about Rust.

Go is very practical for network programming, but - and rust has this too - Go felt more awkward imo.

Collapse
 
stojakovic99 profile image
Nikola Stojaković

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.

Collapse
 
leob profile image
leob

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

Collapse
 
gabrielfallen profile image
Alexander Chichigin

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.

Collapse
 
jmfayard profile image
Jean-Michel πŸ•΅πŸ»β€β™‚οΈ Fayard

You know, sometime there are multiple good options, and that need not to be a source of stress.

Pick one and let go of FOMO

Collapse
 
jessekphillips profile image
Jesse Phillips

I don't see these languages being applied with the same user base.

I don't utilize either and my hobbies use D.

What you'll want to do is either figure out the language you want to work in, or find a job you want and see what language they use rather than predicting a future.