@snaggen coming from 10 years of Go, Rust is an ugly, unnecessarily complicated language with even more dogma than Go.
I guess for someone coming from C++ it must seem like an upgrade.
But as someone using Go on the server side , it’s just much more overhead involved and for what, potentially slightly better performance?
I went Go because it got rid of the mental burden of OOP.
And while it’s not perfect by far, it’s good enough.
Simplicity wins.
I tried, time and again to like Rust.
It starts with error messages not making any sense.
How would I know that I’m missing an import when typing a demonstration from some website?
What’s up with the ugly ( || keyword) syntax or :: or .unwrap() .
Because of ownership you’re forced into certain hierarchies, which make the code ugly and hard to read.
There’s a bazillion libraries, but all are \
I see where you come from. I first turned to Go, but at the end of the day it was a nice language but it didn’t tick my boxes. One of my main issues for backend servers, is for them to be robust. They should never fail in runtime. That means error handling is quite important, and as few runtime errors as possible. Go, fails this hard. The strictness of Rust, may be a pain while learning, and some syntax may be less than optimal, but the result will almost never fail in production. I have in fact never had a backend I wrote fail in production. The error handling also makes it easy to find any errors due to things out of my control. I switched a project from Java to Rust, and the log shrunk by a factor 10.
Note, I still use Go sometimes, but it is not my go to language.
And on a second note, that you point to .unwrap() indicates that you never really used rust to write a backend, since use of .unwrap() will panik if you use that. You normally use .unwrap_or(…) or some other better construct. Also, complaining about unwrap() would indicate that you prefer a null pointer issue? Because, dropping null/nil is one of the great design choices, having null/nil is just a recepie for getting a runtime crash.
I disagree. As someone that learnt go first then rust I much prefer rust in almost every way. The more I learnt Go the more it bothered me, so many promises it made were broken and so many good ideas half implemented. And the more I learn rust the more I enjoy it, it fixed most of the issues I had with Go and fixes a lot of issues I constantly see in Go code in production settings.
How would I know that I’m missing an import when typing a demonstration from some website?
I don’t see how this is an issue? You have a use somecrate at the top of a file that tells you you need something external, demonstations online will only really have crate use statements so it is never really a problem to tell. If they are missing? Well, go has the same but worst problem as you cannot easily guess the import you need for it as you need a full url.
What’s up with the ugly ( || keyword) syntax or :: or .unwrap() .
No more ugly than
func() { ... }
or
iferr != nil {
returnerr;
}
Because of ownership you’re forced into certain hierarchies, which make the code ugly and hard to read.
I dont know what you mean by this? The code rust encourages you into IMO is generally far more readable and less bug prone than a lot of languages.
Rust is a much harder language to learn and get into. But I still find it gets better every day and you learn better ways go doing things. In go if there is something you don’t quite like you re typically stuck doing it the one go way in every situation.
I’ve used Go for a similar amount of time as you. I started with Go 1.0 when I pitched it to my company at the time, and then migrated all of our BE code to Go. It solved the problems we had at the time, and I certainly don’t regret that decision.
However, I ran into a ton of issues that I really don’t think I should have. For example:
dumb bugs stemming from nil and weird interaction with interfaces (e.g. interface{}((*int)(nil)) != nil); honorable mention, functions attached to nil types can still be called, so the source of the nil could be hard to find
map isn’t thread safe; why??
nothing like Arc in Go, either use a channel or DIY with a mutex
And so on. Go strives to be easy to write, but it doesn’t do much to hide the footguns. So it’s like C, but at least you get panics instead of SEGFAULTs.
These days I much prefer Rust. I followed Rust pre-1.0, and I’ve used it a bit for personal projects since 1.0. It has come a long way, and I think it’s finally at a point where the barrier to entry is low enough and the ecosystem is robust enough that it can be a decent alternative to Go. I like that it doesn’t hide the complexity and forces you to deal with design problems at compile time instead of running into them randomly.
If Rust is too much, I prefer Python.
I wish Go would do something about its footguns. I honestly don’t like using it anymore because I get a ton of complexity with goroutines and whatnot, and very little to help manage it. The main thing I miss is pprof, and I find I haven’t needed it with Rust because things just run better.
@sugar_in_your_tea map not thread safe, because multiple threads iterate over one map so you have to use sync.Mutex to lock it for reading, writing or both. I fell into that pit too. Part of the learning process. C++ has mutexes too.
Right, the whole point of Go is to be concurrency friendly, as in, the main reason you’d use it is to do multi-threaded concurrency. That’s the #1 selling point and it’s why goroutines and channels are a thing. Yet there are so many little things you need to keep in mind, such as:
sending mutable types across channels - you either need to ensure it cannot be used by the sender until the receiver is done with it (either by coupling the logic, or by destroying the sender’s copy), or you need to copy it; then you get into whether you need a deep copy, and how to protect any other reference types you send; Rust solves it with the Copy and Send traits, which can only work if everything you depend on implements the Copy or Send trait
no scope guards, so you need to rely on defer for unlocking; in Rust, you get this for free, as soon as you lock something, it’ll unlock once your scope exits
a read from a nil channel blocks instead of panicing (ideally it would fail to compile) - that’s a pretty easy mistake to make
Part of the learning process
Unfortunately, you hit a lot of these cases in production instead of at compile time. In Rust, many of these types of issues are caught before you even get to testing your code, much less actually trying to ship something.
That’s why my decision process is something like this:
Python - if I just want a quick prototype and don’t particularly care about production-level stuff like performance, safety guarantees, etc
Rust - once I need performance, safety guarantees, etc
Go isn’t easy enough to just throw a junior developer on a project, and it’s not robust enough to catch a senior developer when they make mistakes. I thought it would’ve been good enough, but it’s just not as productive for me as Python (generally you hand-wave away the concurrency by using separate processes), and the compiler doesn’t catch nearly enough to rival Rust, so I’m happy to pay the productivity penalty to shift from Python to Rust once I know I need something a bit more serious. And once you’re experienced, the compiler doesn’t really get in the way anymore.
Go is interesting I guess as a microservice tool where you’re making things that are small enough, but imo it really doesn’t scale all that well in terms of reducing bugs as the project gets larger.
Because of ownership you’re forced into certain hierarchies, which make the code ugly and hard to read.
For non-gc languages you always have ownership, in most languages you just have to keep track of it manually. And whenever the rust compiler gives an error, you would most likely have had a future issue in another language. For gc languages, this may still exist if you share data between threads, causing possilbe race conditions and data corruption. So, the ownership/borrow model is just a formalization of implicit rules that exists in most languages.
Sounds like you don’t understand Rust. It’s more difficult to learn than Go. Go can be picked up by an experienced developer in a day. Mostly becauee there isn’t much in the language so there isn’t much to learn.
Try learning Rust properly before writing code. Learn the concepts. It’s not Python where you hack something together that maybe kinda works.
@crispy_kilt correct I don’t understand it and I don’t want to anymore, because I’ve seen it’s much more complicated than what I already use, but I have written that already.
You’re acting like a kid that’s butt hurt that someone said something bad about their favorite team.
Rust promised performance but for the cost of much more mental overhead and more complicated and indoctrinated workflow.
I do what’s best for me.
Don’t like it idgaf
@snaggen coming from 10 years of Go, Rust is an ugly, unnecessarily complicated language with even more dogma than Go.
I guess for someone coming from C++ it must seem like an upgrade.
But as someone using Go on the server side , it’s just much more overhead involved and for what, potentially slightly better performance?
I went Go because it got rid of the mental burden of OOP.
And while it’s not perfect by far, it’s good enough.
Simplicity wins.
I tried, time and again to like Rust.
It starts with error messages not making any sense.
How would I know that I’m missing an import when typing a demonstration from some website?
What’s up with the ugly ( || keyword) syntax or :: or .unwrap() .
Because of ownership you’re forced into certain hierarchies, which make the code ugly and hard to read.
There’s a bazillion libraries, but all are \
I see where you come from. I first turned to Go, but at the end of the day it was a nice language but it didn’t tick my boxes. One of my main issues for backend servers, is for them to be robust. They should never fail in runtime. That means error handling is quite important, and as few runtime errors as possible. Go, fails this hard. The strictness of Rust, may be a pain while learning, and some syntax may be less than optimal, but the result will almost never fail in production. I have in fact never had a backend I wrote fail in production. The error handling also makes it easy to find any errors due to things out of my control. I switched a project from Java to Rust, and the log shrunk by a factor 10.
Note, I still use Go sometimes, but it is not my go to language. And on a second note, that you point to .unwrap() indicates that you never really used rust to write a backend, since use of .unwrap() will panik if you use that. You normally use .unwrap_or(…) or some other better construct. Also, complaining about unwrap() would indicate that you prefer a null pointer issue? Because, dropping null/nil is one of the great design choices, having null/nil is just a recepie for getting a runtime crash.
I disagree. As someone that learnt go first then rust I much prefer rust in almost every way. The more I learnt Go the more it bothered me, so many promises it made were broken and so many good ideas half implemented. And the more I learn rust the more I enjoy it, it fixed most of the issues I had with Go and fixes a lot of issues I constantly see in Go code in production settings.
I don’t see how this is an issue? You have a
use somecrateat the top of a file that tells you you need something external, demonstations online will only really have crate use statements so it is never really a problem to tell. If they are missing? Well, go has the same but worst problem as you cannot easily guess the import you need for it as you need a full url.No more ugly than
func() { ... }or
if err != nil { return err; }I dont know what you mean by this? The code rust encourages you into IMO is generally far more readable and less bug prone than a lot of languages.
Rust is a much harder language to learn and get into. But I still find it gets better every day and you learn better ways go doing things. In go if there is something you don’t quite like you re typically stuck doing it the one go way in every situation.
I’ve used Go for a similar amount of time as you. I started with Go 1.0 when I pitched it to my company at the time, and then migrated all of our BE code to Go. It solved the problems we had at the time, and I certainly don’t regret that decision.
However, I ran into a ton of issues that I really don’t think I should have. For example:
niland weird interaction with interfaces (e.g.interface{}((*int)(nil)) != nil); honorable mention, functions attached to nil types can still be called, so the source of the nil could be hard to findmapisn’t thread safe; why??Arcin Go, either use a channel or DIY with a mutexAnd so on. Go strives to be easy to write, but it doesn’t do much to hide the footguns. So it’s like C, but at least you get panics instead of SEGFAULTs.
These days I much prefer Rust. I followed Rust pre-1.0, and I’ve used it a bit for personal projects since 1.0. It has come a long way, and I think it’s finally at a point where the barrier to entry is low enough and the ecosystem is robust enough that it can be a decent alternative to Go. I like that it doesn’t hide the complexity and forces you to deal with design problems at compile time instead of running into them randomly.
If Rust is too much, I prefer Python.
I wish Go would do something about its footguns. I honestly don’t like using it anymore because I get a ton of complexity with goroutines and whatnot, and very little to help manage it. The main thing I miss is
pprof, and I find I haven’t needed it with Rust because things just run better.@sugar_in_your_tea map not thread safe, because multiple threads iterate over one map so you have to use sync.Mutex to lock it for reading, writing or both. I fell into that pit too. Part of the learning process. C++ has mutexes too.
Right, the whole point of Go is to be concurrency friendly, as in, the main reason you’d use it is to do multi-threaded concurrency. That’s the #1 selling point and it’s why goroutines and channels are a thing. Yet there are so many little things you need to keep in mind, such as:
CopyandSendtraits, which can only work if everything you depend on implements theCopyorSendtraitdeferfor unlocking; in Rust, you get this for free, as soon as you lock something, it’ll unlock once your scope exitsnilchannel blocks instead of panicing (ideally it would fail to compile) - that’s a pretty easy mistake to makeUnfortunately, you hit a lot of these cases in production instead of at compile time. In Rust, many of these types of issues are caught before you even get to testing your code, much less actually trying to ship something.
That’s why my decision process is something like this:
Go isn’t easy enough to just throw a junior developer on a project, and it’s not robust enough to catch a senior developer when they make mistakes. I thought it would’ve been good enough, but it’s just not as productive for me as Python (generally you hand-wave away the concurrency by using separate processes), and the compiler doesn’t catch nearly enough to rival Rust, so I’m happy to pay the productivity penalty to shift from Python to Rust once I know I need something a bit more serious. And once you’re experienced, the compiler doesn’t really get in the way anymore.
Go is interesting I guess as a microservice tool where you’re making things that are small enough, but imo it really doesn’t scale all that well in terms of reducing bugs as the project gets larger.
For non-gc languages you always have ownership, in most languages you just have to keep track of it manually. And whenever the rust compiler gives an error, you would most likely have had a future issue in another language. For gc languages, this may still exist if you share data between threads, causing possilbe race conditions and data corruption. So, the ownership/borrow model is just a formalization of implicit rules that exists in most languages.
Sounds like you don’t understand Rust. It’s more difficult to learn than Go. Go can be picked up by an experienced developer in a day. Mostly becauee there isn’t much in the language so there isn’t much to learn.
Try learning Rust properly before writing code. Learn the concepts. It’s not Python where you hack something together that maybe kinda works.
@crispy_kilt correct I don’t understand it and I don’t want to anymore, because I’ve seen it’s much more complicated than what I already use, but I have written that already.
You’re acting like a kid that’s butt hurt that someone said something bad about their favorite team.
Rust promised performance but for the cost of much more mental overhead and more complicated and indoctrinated workflow.
I do what’s best for me.
Don’t like it idgaf
Of course, do what’s best for you, I didn’t mean to suggest otherwise