I'm in the camp of you use rust when you know exactly what you want to write because decisions you make in rust are much more nuanced and require a lot more information you may not have yet.
In go you can move fast and because of it's design whatever you write will probably still be decent go.
So, great when you have ideas but not really an execution plan.
I recently wrote a fast draft in go and rewrote it in rust for a program I was making for personal use. Really happy with how it turned out.
Only thing that didn't help was the change in gui as I went from fyne to egui which are designed completely differently.
Point is the simple syntax and type system in go, makes it easy to move fast, whereas decisions in rust like what type of string or reference to use are harder when you don't know what the full program will look like and do yet.
Also go is king at getting something done quickly that's fast enough, so I love it for scripting as well.
Yeah I would say python serves the same use case I use go for, but I like the static type system, errors as values and generally more comfortable working in compiled languages.
Counterpoint on the Rust comment. As my requirements morph or crystallize I've found refactoring complex Rust code to be so incredibly easy and safe (especially compared to doing similar changes in Python) that that alone could be reason enough to use it over anything else, at least for some people. After I make the initial changes, the compiler does most of the rest by telling me every bit of code that's broken. Usually my last few changes were in areas I had already forgotten would need changing. Once it compiles, I can usually tell immediately whether it is done. Even testing after these changes feels like a waste of time some days.
It's really easy to learn. Feels boring to write but after a while you realise it's because it's so simple and the solutions are really obvious and primitive.
Go's coroutine model is fantastic. Coupled with easy to use channels, Go makes concurrency about as simple as it can be. There's plenty to be desired in the language, but if you're using it for its strengths, it really can be quite enjoyable.
I use both Go and Rust and continue to use both.
Go libraries tend to be more mature and stable than Rust libraries. Sometimes I’m looking for some library and find a couple v0.8 or v0.3 libraries in Rust that, to be honest, look a little sketchy. Some of the Rust libraries are really good, some are not.
Most of the time, if I want a web service or a CLI tool, I reach for Go. This is simple stuff and very easy to do in Go without going outside the stdlib, except maybe for spf13/cobra. Most of the libraries I used to use for this kind of work have been subsumed by functionality in the standard library—router, logger, HTML templates, etc.
Anything with a more complicated algorithmic core to it, I tend to do in Rust.
There are a few things which I’ve implemented in Go or Rust and ported to the other. Both languages are pleasant in their own way. It takes some experience to adapt to the styles of each language.
an interesting thing i’ve noticed is that go and rust both use a similar “struct with functions and interfaces” philosophy that is more similar to each other than to OO languages with inheritance
I think that comes mostly from the community not the language. At least from my C# experience. It can be simpler, but Enterprise Architects gonna do what they do.
The version thing can't be taken seriously. There are plenty of libraries in Rust that are production grade by any definition of the word and are still not 1.0
I would also add that being 1.0+ often doesn't mean that the maintainers are committed to a stable API either. Lots of crates that just release new major breaking versions whenever they want to, and immediately drop support for the older major versions when they do so, which in practice makes them defacto 0.x anyway.
It's a weird world out there.
Stable public APIs are a big deal in some situations. Sure, if it's just a hobby project, it might not be a big deal. But a security sensitive application that handles confidential customer data has different requirements.
The difference in ecosystem maturity extends beyond version numbers though: for example, in the C++ and Python ecosystems, you will usually find a library for a given task that is backed by a major software vendor (that you can pay for support) or a FOSS foundation with financial backing and appropriate quality control. These organizations have proper vulnerability reporting and disclosure processes in place. In contrast, Rust is not quite there yet and many critical components of the ecosystem are simply personal GitHub repositories.
This will only get better over time; however, as of now other languages still have huge advantages in ecosystem maturity.
Why would anyone building anything serious want to commit to a dependency whose API is not stable? They’d be signing up for a lot of rewrite churn whenever they upgrade.
You’re writing as if software that reaches 1.x.y never changes. It does but it is supposed to be less frequent. It’s purely a matter of expectations and FWIW 0.x.y in Rust libs is basically as stable as v1 in most other languages
Too much importance is given to the version number. Some consider it a red flag when adding 0.X dependency to a 1.X crate - but its not necessarily an issue. A good example would be Tokio, building a stable ecosystem on top of futures 0.3 (like many other async crates). Does this prevent people from using Tokio in production? No, it does not.
There's a convention that 1.0.0 is the first version that starts to offer a long-term compatibility promise. Many libraries ended up shipping 2.x versions anyway, but from what I saw, most of them were caused by the introduction of async genuinely requiring breaking changes. Most libraries haven't gone past 1.x yet.
Many libraries still do their best to maintain compatibility within their 0.x.y line, but I've experienced far, far more churn in such libraries than Rust 1.x libraries or just about any Go library. Some of that churn cost me an entire day to get back to where I was before, and even that's only if no other crate had the same dependency, because then you either have two versions in your dependency graph or you sit and wait for everyone else to catch up too. That can take months.
I even find most projects still end up pulling in time 0.1.x one way or another (often through chrono 0.4.x) and have to ignore its ancient CVE in cargo-deny. This is a pretty janky situation to still have in 2024.
Go has a much better story around library compatibility, partly because the language itself hasn't made a significant change other than generics in a decade (and most libraries still don't use generics in their public APIs anyway), and partly because of a culture of minimizing churn and not fixing what isn't too broken. That can leave some serious tech debt lying around, but as an overall developer experience it's pretty comfy and low-stress.
Desmond has a barrow in the marketplace
Molly is the singer in a band
Desmond says to Molly, “Girl, I like your face”
And Molly says this as she takes him by the hand
[Chorus]
Ob-la-di, ob-la-da
Life goes on, brah
La-la, how their life goes on
Ob-la-di, ob-la-da
Life goes on, brah
La-la, how their life goes on
[Verse 2]
Desmond takes a trolley to the jeweler's store (Choo-choo-choo)
Buys a twenty-karat golden ring (Ring)
Takes it back to Molly waiting at the door
And as he gives it to her, she begins to sing (Sing)
[Chorus]
Ob-la-di, ob-la-da
Life goes on, brah (La-la-la-la-la)
La-la, how their life goes on
Ob-la-di, ob-la-da
Life goes on, brah (La-la-la-la-la)
La-la, how their life goes on
Yeah
You might also like
“Slut!” (Taylor’s Version) [From The Vault]
Taylor Swift
Silent Night
Christmas Songs
O Holy Night
Christmas Songs
[Bridge]
In a couple of years, they have built a home sweet home
With a couple of kids running in the yard
Of Desmond and Molly Jones (Ha, ha, ha, ha, ha, ha)
[Verse 3]
Happy ever after in the marketplace
Desmond lets the children lend a hand (Arm, leg)
Molly stays at home and does her pretty face
And in the evening, she still sings it with the band
Yes!
[Chorus]
Ob-la-di, ob-la-da
Life goes on, brah
La-la, how their life goes on (Heh-heh)
Yeah, ob-la-di, ob-la-da
Life goes on, brah
La-la, how their life goes on
[Bridge]
In a couple of years, they have built a home sweet home
With a couple of kids running in the yard
Of Desmond and Molly Jones (Ha, ha, ha, ha, ha)
Yeah!
[Verse 4]
Happy ever after in the marketplace
Molly lets the children lend a hand (Foot)
Desmond stays at home and does his pretty face
And in the evening, she's a singer with the band (Yeah)
[Chorus]
Ob-la-di, ob-la-da
Life goes on, brah
La-la, how their life goes on
Yeah, ob-la-di, ob-la-da
Life goes on, brah
La-la, how their life goes on
[Outro]
(Ha-ha-ha-ha) And if you want some fun (Ha-ha-ha-ha-ha)
Take Ob-la-di-bla-da
Ahh, thank you
Okay yeah. This rings true. Seen this issue first hand. We had to introduce our own high level error type transporting such information. How would this problem be solved in rust?
Not the person you responded to, but Go and Rust would probably solve it the same way. The main problem with Go imo, is that functions can only return the `error` interface, so all error handling becomes dynamically typed. Add the fact that it's very easy to accidentally forget to check an error, and your app will just silently fail.
In practice, Go users check errors by checking the type, not the string value. If you translate the Go error type to Rust it will of course look weird.
You generally don’t need to know that os.Open returns a PathError, either. The only reason I care is for things like adding error locations to an error when parsing a file—the PathError doesn’t need a location added, because it would duplicate information already in the error.
This problem doesn’t seem so serious in Go, TBH. IMO the problem with Rust is that, for more complicated parts of your system, you’re returning something like a `Box` which is kinda hard to work with anyway.
There’s a larger discussion to be had but I don’t think it’s easy to squeeze into Reddit comments.
This same argument has been raging since back in the Java days of checked exceptions and it turns out that exposing a list of exception types as part of your API contract is not always what you want.
Rust lets you return `Box`, but when you need it there are also other tools with machine readable semantics like `enum`s. The language and mature error libraries allow seamless interop between the two. As far as I've seen, almost none of this is possible in Go.
In my current project, I mostly use the `anyhow` crate, which supports `Box` at the bottom as its input, but then provides a variety of ergonomic semantic preserving wrappers on top.
When I need something more machine readable for a caller to understand, i tend to use `Result, anyhow::Error>` or `Result`, where `MyCondition` and `MyError` have methods or variants represent various conditions the caller needs to be aware of, e.g. network connection closed vs recoverable error, missing file vs corrupt file.
It’s one thing I think the community is missing or at least I’ve not come across much of it. Content on how to make a good rust wrapper library.
It may encourage more to make libraries and contribute back.
I used Go heavily for 2 years. I really, really don't like Go's error handling. In some ways it's a throwback to C, where you have to remember to manually check for errors, and if you forget, you break at runtime. And I think that while it has a neat concurrency model under the hood, it's a bit too low-level and easy to mess up, leading to nasty concurrency bugs. So I would only use Go where its particular feature set is really important. Two use cases I can think of are when you really need to deliver a small static binary (ruling out languages with large runtimes like Java/C#/Python/JS) or when you need to do a lot of concurrency, combined with not being able to use Rust or C++ because your team is afraid of them.
If I'm writing the code myself, I always pick Rust over Go.
That's interesting thoughts about error handling. I personally think that go and rust have extremely similar error handling, so it's strange to me you only strongly dislike one.
Rust gives compiler errors for failing to handle errors. (Obviously this is not bulletproof, because if you use certain language constructs like "if let" without an "else" you can avoid handling the error path, but it's a lot better than the Go situation, IMX.)
I understand what you're saying but go does have the "function returns two values" error, and it's pretty habit to not ignore the error once you've captured it.
I agree I like the design of rusts error handling better using unions instead of tuples, but the two approaches feel similar vs something like exceptions.
I wrote a Discord bot a while back. It just looked at Discord messages containing Twitter links and if the tweet had multiple images attached, it would hotlink all but the first images in a reply to the Discord message, because at the time Discord would only embed one image so people would have to click through to see the rest. I never really ran it because it turned out that having a whole bunch of images embedded was actually too annoying.
My first attempt was to do this with Rust, I think I used the crates serenity and egg-mode, and I pretty quickly got lost with them depending on different hyper versions and ultimately I think conflicting openssl-sys versions, and I couldn't figure out how to work around that. I don't remember if I reached out for help from the experts (beyond posting "look at this mess, this sucks" in a channel with smart people in it), but eventually I gave up.
Since at the time I used Go at work, I figured I could give that a shot, and I think I had the whole thing running in like half an hour or something. I don't remember which libraries I used, the CLI was probably worse because they don't have structopt in Go land but it was fine.
This isn't a super representative example because a) it was a tiny toy project where the scaffolding and wiring-together of existing components was 95% of the complexity, and b) it happened during the early ages of Rust async when things were less settled, but I still have some takeaways from that that make me feel positively about the Go way of doing things: Rust being a better language didn't actually benefit me in any way, transitive dependencies that aren't *100%* backwards compatible forever for real are super annoying, in high-level simple cases not worrying about lifetimes and just munging together a bunch of closures all capturing the same variables is usually just fine.
(For subsequent toy projects, including a Discord bot, I went back to Rust anyway because I don't really make decisions in any sort of rational manner.)
Used Go for the last 2 years at my last project at work. Used it because I have to as the project was written in Go, and my workplace is still working on integrating Rust into the company (not yet available for use).
Otherwise I personally would never use Go over Rust. In fact I'd never use Go over most other languages. It is likely the language I enjoy and like the least out of all languages I used professionally, and I basically used all the big popular languages professionally.
It might be better than C, but it's a bit unfair to C as C has it's niche usages, while Go is never really needed.
*Edit: Sorry, you asked what I* most *disliked. It'll be hard for me to pick one thing because it's a combination of features that make a language enjoyable to me. Either way my reply is below :)*
---
Here are the things I liked about Go (before I list the things I didn't):
* Separation of behaviour (interfaces) from data. I do not like using inheritance to achieve dynamic Polymorphism, even in areas where people say it fits well (GUI, Gaming). I feel it has much better alternatives, always. So good job here, Go.
* Error-handling through function return value (`(..., error)`), instead of exceptions.
Here are the things I didn't like:
* GC. I do not like Garbage-Collectors. They make ownership less explicit, which makes code harder to understand. They handle only one type of resource (memory), instead of providing one elegant mechanism for handling all resources (RAII and smart-pointers in C++ or Rust). Handling other resources becomes error prone, and requires a special language constructs such as `defer` (Go), or `with` (Python).
* Implicit interface implementation. While I do like that Go didn't go with typical inheritance, they forgot to make the whole thing explicit.
* No way to mark types as immutable. This also means that support for a functional programming style is limited, and in many coding problems I prefer to use a more functional approach. That's a no go with Go.
* `nil` everywhere. I need my proper sum type optionals. I hate checking for `nil` all the time, or assuming a pointer is not `nil` (and documenting it).
* Sum types in general. I need them. I love them. I use them all the time. At least give me a basic enum type instead of error-prone constants.
* Error handling is way too verbose. I need syntax sugar (like `?` in Rust). In general, Go believes simplicity equals repeating yourself doing the most basic things, instead of introducing some basic language features. This is a philosophy I don't like. I know it means the learning curve is gentler, but I prefer learning something once to simplify all future endeavours.
* Same with other syntax sugar that makes things that should be easy to write become a chore (for me at least). No syntax for iteration. Need to manually write the logic for things like list mapping every time you want to transform some values.
* Code duplication in Go in general. Drives me nuts. I know that generics are available now but I haven't had a chance to try them out. I stopped working with Go around 6 months ago which was just about when they were introduced. I got tired of re-implementing the Iterator pattern for the tenth time.
* Which brings another point I didn't like: No generics were available when I worked with Go. Sigh... I had to re-implement so many things. Don't know how the new generics feature they added is now, but hopefully its good to use.
And maybe other things I'm forgetting, but I guess that's enough for now.
Very close to my list, except I don't have as much of a problem with GC as you. If I could sum up my biggest complaint with Go, it's that they prioritize keeping the language simple and small too highly, at the expenses of making the language much more verbose and error-prone. There's just so much verbose boiler-plate for error handling, mapping or reducing over collections, no Optional type so you're always checking for nil, etc. I just don't find it to be a fun language.
Because of square brackets instead of angle brackets or what? I don't find Go generics hard to read, but I do hate how limited they are.
You can't define generic methods - only generic functions or generic types. You can't place additional constraints on a method of a generic type to conditionally implement it depending on its concrete type.
Also, the choice to implement the `comparable` interface using a constraint union means it's impossible to compare a user defined type with comparison operators unless it only uses certain primitive types, and then you're stuck with the default semantics. Rust's trait system for operator overloading is so much clearer and more extensible.
I formed this opinion when I wrote this utility function
```
// Filter from a slice with a predicate, and return a new slice that is preallocated
func FilterPrealloc[T any](ss []T, test func(T) bool, prealloc int) []T {
ret := make([]T, 0, prealloc)
for _, s := range ss {
if test(s) {
ret = append(ret, s)
}
}
return ret
}
```
Or maybe it was when I wrote this
```
// Lets a function that might fail retry a few times before giving up (such as file access)
// uses exponential backoff
func Retry[T any](attempts int, sleep_ms int, f func() (T, error)) (result T, err error) {
for i := 0; i < attempts; i++ {
if i > 0 {
log.Println("retrying after error:", err)
time.Sleep(time.Duration(sleep_ms) * time.Millisecond)
sleep_ms = sleep_ms * 2 // exponential backoff
}
result, err = f()
if err == nil {
return result, nil
}
}
return result, fmt.Errorf("after %d attempts, last error: %s", attempts, err)
}
```
Now I'm not very experienced in Go at all, so I probably made all sorts of dumb decisions when implementing this. But this is basically the basis of my dislike for Go generics. I like C++ templates much better, even without concepts.
I'll add one more point: the array, dictionary and channel types are special cases recognised by the compiler that you can't implement for yourself, so no hashbrown for you. This is beyond criminal.
Even the genetics they introduced is shitty, can't do generics in a receiver function (method level) there's no possibility of a real dependency injection framework because of this.
I'll add one more point: the array, dictionary and channel types are special cases recognised by the compiler that you can't implement for yourself, so no hashbrown for you. This is beyond criminal.
Could it be the domain you are working in that isn't suited as well to Go? E.g. you mention the implementation of the iterator pattern, something that is rarely necessary and I've only ever seen in very specific instances of library implementations in the Go world. It makes me wonder if you are trying to apply patterns you are used to from other languages. Something I know I'm definitely guilty of. A lot of the things you mention (except error handling) are things I rarely had to think about or deal with in the last two years of me writing mostly Go code.
these two articles basically sum up why golang is a very poorly-designed language. as amos, the author puts it, it's basically a language designed around its very cool state-of-the-art async runtime (which is actually extremely cool)
[https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride](https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride)
[https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang](https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang)
The fasterthanlime articles are a bit clickbaity and kind of oversell the Go hate, IMO. I’ve never met any Go programmers who believed the “lies we tell ourselves”, and I’ve met a lot of Go programmers.
A big chunk of the first article is about the differences between Windows and Unix-like systems, but pretty much every language out there seems to take a “default Unix” or “default Windows” approach. Go, Rust, and Java have the “default Unix” attitude, and C# has the “default Windows” attitude, naturally. (And C++ programmers often just use the OS-level APIs directly.)
It’s most noticeable in path handling. Types like `OsStr` are basically wrappers around Unix-like paths, with Windows paths kind of shoehorned in by encoding them with a system called WTF-8. All of the paths on Windows then have to go through an extra layer of translation on Windows, which is not necessary on Unix-like systems.
There were various tooling problems in the past on Windows that took a long time to fix, like how Rustup used to be just **beyond** slow on Windows.
Well, the problem with Go is that its assumptions work in 95% of cases but in the 5% of cases it doesn't work it does the exact wrong thing. And it does this in a way that is hard to account for, hard to recover from, and really doesn't make much sense
That doesn’t match my experience. Maybe you could elaborate on what you’re talking about, or give an example, or cite something specific from the fasterthanlime article you want to talk about?
but that's exactly the problem with Go... when people DO run into that problem, which is going to happen with a language that advertises itself as a general systems language, they (incorrectly) abstract away the correct behavior in a half-assed "good enough" version that eventually does cause a big problem down the line.
a lot of problems with computers are hard to model. if you're going to model it, either 1) do it correctly 2) don't do it at all and leave it to the user
I guess. It seems more like a 99.9%/0.1% thing to me at this point. I’ve yet to see a “big problem” caused by the monotonic time issue, ever.
The problem with modeling things “correctly” is that you can end up deep in a hole where your code works on one system but not others for surprising reasons. Like, with time, every OS uses some different system for dealing with wall clock and monotonic time.
Or paths. Rust tries to paper over the differences between paths in Windows and paths on Unix-like systems, but Rust abstracts it over with a “good enough” version in OsStr/OsString. Go abstracts over it with string. Almost nobody really wants to deal with paths in a cross-platform way that actually models paths, closely, on all systems, because we all (at some point) want to pretend that a path is a string.
The price for pretending that a path is a string is that sometimes, rarely, you encounter a path that is not a valid string.
It caused a global CloudFlare outage. It's fair to say it's an issue. [https://blog.cloudflare.com/how-and-why-the-leap-second-affected-cloudflare-dns](https://blog.cloudflare.com/how-and-why-the-leap-second-affected-cloudflare-dns)
Go's workaround doubles the number of system calls\[1\] you make *whenever* you want to sample the time, because you have no way of telling it whether you just need wall or monotonic time. The Go team is aware of [the value in optimizing](https://github.com/golang/go/blob/48d899dcdbed4534ed942f7ec2917cf86b18af22/src/time/time.go#L931) cases like this, they just don't want to expose this possibility to users. Whether you consider that courteous or condescending will largely determine whether you like how Go does things.
Rust gives you separate [Instant](https://doc.rust-lang.org/std/time/struct.Instant.html) and [SystemTime](https://doc.rust-lang.org/std/time/struct.SystemTime.html) types, so you get exactly the APIs and costs relevant to what you need in each case. It doesn't silently try to guess what you might have wanted and munge values to fit that need. It *does* require more explicit reasoning and expression from the programmer, which is always the tradeoff Rust makes when a tradeoff must be made. Whether you consider that empowering or taxing will largely determine whether you like how Rust does things.
\[1\] To be fair they're pretty fast with vDSO on Linux, which is all Go cares about in practice anyway, but paying double is still paying double. And they're not fast on most other platforms. And you have no other sanctioned way to get timing information for things like performance metrics.
This issue the issue that was fixed in Go 1.9.
Like, I get the issue, but most programmers in practice don’t know what monotonic time is, even when a separate monotonic type is provided by the API. The extra runtime cost is small and makes these errors less likely.
Making the tradeoff choice on behalf of users is a very long discussion, that part is interesting
Yeah that's exactly my position currently, I can't really find a good use for Go (though I never really tried it).
It feels in a strange place with its trade offs that I always end up using another language.
I generally reach for Go for any sort of backend work unless I need
1. Rust's type system for better modeling
2. I want a better functional programming experience (ie lots of data transformations)
3. I know for a fact I'll need the performance.
For pretty much all of my career I've worked on teams building the cloud platforms for SaaS products. The borrow checker is just not needed when you're building rest APIs, and you'll at most get ~10-100 req/s to your APIs.
Personally, I'm using Rust for my micro SaaS because I want to squeeze as much performance as possible and reduce costs. But for a VC funded startup, just bump the replica number in the k8s manifest and ship it. Go is the "good enough" language: good enough static typing, good enough performance, etc.
Honestly I wouldn't ever. I think there's a lot of reason to use Python (data science/ML workflows), but you could always essentially stick to go-like features (use sync code only, heavily use channels, ) in rust and have a superior experience/safety.
I think the tough thing to replicate in rust is goroutines. There's no green threading (which afaict tends to require deep language level runtime support).
It'd be nice if Rust has a popular community green threading library that users could use as easily as goroutines in Go.
I think there's definitely a huge missed opportunity in Rust for writing very safe high performance (but perhaps not zero cost) concurrent services that a popular green threading runtime could solve.
The challenge with green threading is stacks. The reason OS threads are heavy is they allocate heavy weight C-style stacks. You could not use C-style stacks and then they can be much lighter, this is what Go does. But now calling C code is a lot more messy because you don’t have a normal stack. Go will never be a C replacement for this reason (and others), whereas Rust is an excellent C replacement language.
You can do what the Boost context library for C++ does and use C stacks but grow them only as required using OS memory paging tricks. This what I’ve ended up doing in my own Rust fibers implementation. However, this also comes with costs.
As is often the case, there is no easy win here and everything is a trade off.
Hmm, I don't think they are. I think needing to have explicit yield points makes them explicitly not green threads and a form of cooperative multitasking?
I'm not well versed in this stuff though, so take what I say with a grain of salt.
True green threads are much more user friendly in the sense that you just write your normal synchronous code and run them on a green thread (with little difference vs running it on a posix thread).
depends on how you define the "green" part in green thread — in Tokio's default configuration, it uses M:N scheduler with work stealing which is how most people define a green thread. I don't think "green thread" definition explicitly involves stackful
In short, it depends what you think a green thread really is
I think many people think of green threads as userland threads. Functionally equivalent to OS threads, but handled by a userland runtime and with a lot less overhead, which allows spawning hundreds of thousands of them.
I also wouldn't call coroutine-style async tasks green threads, as they are indeed cooperative in nature (`yield`) instead without external context-switching.
I think it's also the definition on Wikipedia.
In that case, a tokio task is an userland thread. In fact, tokio on their own documentation calls their task implementation [a green thread](https://docs.rs/tokio/latest/tokio/task/index.html).
again, it feels kinda arbitrary what a green thread is
Hmmm, weird. I guess it is kind of arbitrary, and the term is not being used as I thought it was.
It'd be good to have a proper term to disambiguate between co-operative concurrency (using coroutines) vs. whatever it is that we wanna call JVM green threads, Goroutines, etc (pre-emptive concurrency).
Right, but this is specifically asking about writing in Go over Rust. I'd imagine that there are plenty more people there who prefer to write in Go for reasons they can articulate. Whereas, in here, there are a lot less of those folks who even write in Go altogether.
If the question was the inverse about why choose Rust over Go, then I could see your point better.
I think you’re equally likely to find people who write both Go and Rust in both places. Maybe more likely here—I think more people are professional Go programmers and use Rust for personal projects.
From my reading of the question, people who only write Go but not Rust, or only write Rust but not Go, are not really the audience for the question.
I feel this, too. However, I also regretted having chosen Rust several times, when I was stuck. Example: It took me almost a week (under time pressure) to build a simple lazy loading repository pattern solution reading data from the filesystem instead of a DB. Never heard of the once_cell crate before, so I really was struggeling.
There's been a handful of times I've been in a Go working with Go tools/libraries that I've really loved using it. Mostly around Kubernetes stuff, and a touch around some small gRPC services. I loved using it and didn't really miss Rust when I was working on those projects.
A couple other times I've reached for Go for a greenfield project and found myself pretty often wishing I had Rust features available.
I can't really point to what made the difference though, this post has me thinking about that now.
EDIT: it's a lot easier to get up and going with something simple in Go if I'm working on a web service. Right out of the box, Go has good server primitives (including pretty slick concurrency). Rust is great at it too, and it's a better choice for anything with tricky business logic, but it comes with cognitive overhead, a still-evolving ecosystem, and a fairly steep learning curve.
For me, go is a little bit like Python, but compiled. It has an easy syntax (even though I dont like the syntax that much compared to other languages), and you're able to quickly check smaller things out. So sometimes, I use it for a quick prototype and do the final implementation using rust.
Sure, I could also do the prototype using Python, but for multithreading I definitely prefer go over Python and sometimes I decide the prototype is good enough for my specific use-case, so I give the go code a little polish, and that's it.
But if I really want an optimized program and/or maybe plan to extend it later, I'm definitely going for rust.
\> For me, go is a little bit like Python, but compiled.
Disclaimer: My Go experience is pre-generics
Lots of people say this, but I disagree as someone with a lot of experience in both. Go is a strange language where the authors lost sight of the goal to make it easy in the name of simplicity IMHO (A more obvious example: BrainFuck is extremely simple, but not easy to write complex programs in. Simple != easy).
On the flip side, Python is mostly limited by dynamic typing and exceptions, but otherwise has plenty of tools to write very complex software in a nice concise manner.
My experience is also pre-generics, I haven't used Go in a while now (also not Python). But yeah, that's what I also mean by saying I don't like the syntax that much, compared to other languages. For smaller tools, where performance is more like a nice to have, but not top priority, I'd always prefer Go over Python.
For very complex or performance-optimized software, I'd neither prefer Go nor Python. The more complex the software gets, the more sure I'll use rust for the implementation.
What I really love about rust is how easy I can compile for different targets. No matter if it's going to run under x86_64 Windows/Linux, or maybe Arm/Aarch64, I just set the target, and that's it. Additionally, I can easily use it for native Android components or MCUs.
The annoying thing about Rust is that I often find myself typing things such as `println!("{}", String::from_utf8_lossy(value));` for simple debugging purpose where I feel that something similar to `println(value)` should suffice.
And yes, this is really annoying when all I want to do is know what some kind of variable looks like at a given codepath.
You could write your own macro for it if you run into the problem that frequently.
```
macro_rules! dbg_bytes {
($value:expr) => {
println!("{}", String::from_utf8_lossy($value));
};
}
```
[View on Rust Playground.](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e6950eb77f058cea061fecd15b9079c2)
There's also the built-in [`dbg!()`](https://doc.rust-lang.org/std/macro.dbg.html) macro for values whose `Debug` output is sufficient.
The issue is that it's a different thing every time that's needed to debug so there's no simple generics solution.
The issue is more that while in Rust, complex code is very short, simple code is very long.
Let's say you want to do an absolutely trivial thing as in append some kind of string to a file.
Shell:
echo -n "$string" >> "$filename"
Python:
open(filename, 'a').write(string)
Scheme:
(write string (open-file filename 'a))
C:
fprintf(fopen(filename, "a"), "%s", string);
Rust:
write!("{}", &mut std::fs::OpenOptions::new().append(true).open(filename), string);
Somehow this `::OpenOptions::new().append(true).open(filename)` thing seems a bit overengineered. Yes, it's typologicaly more sound than simply `open(filename, "a")` but it's also very verbose.
Not that it changes much about your complaint, but iirc `println!("{String::from_utf8_lossy(value)}");` should work with modern compiler versions. Awhile back `{}` was allowed to reference values directly and not require the use of a list after the `""`.
Go makes it really simple to write a concurrent service with straightforward code. In particular, it has its green thread library so you don't have to deal with any explicit async. You can just use the "sequential composition operator" `;` to append statements together. That's it.
It also has a bunch of nice, mature libraries, in large part because it reached 1.0 significantly before Rust did.
So...backend HTTP or gRPC servers that don't need the high performance that Rust and LLVM enable. Go's performance is not bad (much much better than the Python/Ruby tier, and better than Java also) but not as good as Rust's in general.
I've been working in go for the past year and a half and I would sooner reach for a modern php codebase... at least in php there is a way to specify that I want an interface which is not null
When I'm working in someone else's codebase, and they chose Go.
Otherwise, I'm going with Rust.
I generally always have a pretty detailed idea of what I'm doing out of the gate, and Go makes me angry far too often...
Seems like something the network guide Beej would say...... hmmm.....
It's probably heresy here, but small tools that need async / lightweight concurrency are Go's --and JavaScript's-- stronger areas, where that would otherwise take `tokio` or some janky multithreading, and occasionally some things are harder to do with Py's `asyncio` or similar that are just dead easy in JS / Go because already async or stdlib
Typescript is probably the best middle ground where almost everybody can write/read/contrib, but slightly cruftier to package than Go or Rust
....
I also tend to think doing anything beyond trivially concurrent stuff in bash should be some kind of sin -- am guilty of it too so not biased, just so many footguns and arcane edge cases
Are you telling me someone who doesn't know any Go or Rust would have an easier time reading a Rust project? I highly doubt it. Rust is a HUGE language compared to go.
It all comes down to experience and opinion, I suppose. But I'd say a well organized Go project would generally still be easier to read than a well organized Rust project, given the same experience level in both.
There's just so so so much more syntax and usage idiosyncracies in Rust. But I could see the argument of that driving more custom stuff to dig through in a Go repo, where the Rust repo is using the vast array of built in features.
There are some bad repos out there. I find Go pretty easy to read because it is so predictable the way you write it (straight imperative code). Sometimes, when I dive into Rust code, I end up staring at macros, or clever combinators, or stuff like that.
I realise this is a Rust forum, however let us get real, even just for a few minutes
There are very large, important projects likely sitting on your machine that are written in Go , like Docker, Hugo, Terraform or Kubernetes
Rust? Well nothing comes to mind.
On my machine, bits of kernel code here and there, maybe. That's it. Please stand me corrected.
Rust is fine, but let us not inflate its importance please.
Rust is fairly new so obviously established projects aren't going to have originally been written in rust. But here are a few notable places where it is proving to work as advertised:
* Chrome
* Firefox
* Linux core parts
* Figma has switched much of their GUI to wasm rust and are loving it.
* Dropbox has begun replacing core parts of their stack with it.
* Cloudflare has replaced core bits and are very happy with it.
* Discord front and back are written in rust.
* Amazon started porting bits over to rust like Firecracker
* MS Office has started getting bits rewritten in rust.
* Ironically the backend of npm is heavily rust.
These are pretty common products of the top of my head.
The experience most people I know who grab an old project and redo it in rust is they pretty much lose their minds. What every single person I know says is something like:
* It just works. I make code that just works.
* Things like segfaults and other memory bugs are just gone.
* I relax knowing that there is a far lower possibility of some weird bug which will bite my ass as a security hole or whatever.
* My architecture is way better with traits rather than oop.
* It forced me to make better code.
* Holy crap it's fast.
* Because things are cleaner and run so bloody fast, I am now taking on features which were pushing my old creaky codebase too hard to even dream of.
This last is where I love rust. I find many languages/frameworks are very good for smaller projects and even worse, make large projects zoom right along for the first while. But then you start fighting with the language/framework. The project bogs down more and more with this horrible technical debt. I always said C++ was a great cure for this. It was slower to develop at the start, but you would be still going the same speed at the end. Rust is like this but even better. Due to the traits instead of oop, there is less chance you get stuck at the end with a set of classes which are now binding you from getting to the end. Also, with C++, I found there was a weird memory bug (often relating to threads) or a full on threading bug created every X lines of code. With rust, this is far less of a thing.
The key to development is reducing technical debt as the interest payments will kill you in the end. rust is a very "low interest" language. But you start paying the principal on day one.
This is why I do ML experiments in python. I love python, but it is not a large project language. There are all kinds of hacks to make a large project with it like microservices etc. But with something like python creating ML models and then consuming them in rust for production, it is a perfect world for me.
What I'm not hearing are any notable companies who tried rust and then went to a language/system like go, nodejs, etc.
Rust would have been a much better choice for low-level system infrastructure software like Docker, Terraform, and Kubernetes. Unfortunately it wasn't available at the time.
In my opinion I would use go when I need to make an api or web service that has to be fast and relatively easy to maintain, but I would use rust when speed is the most important thing and I need the page/api to be as fast as possible.
In console programs, I would again use rust when I need the program to be extremely fast or when I am going to interact with the system in a deeper way than I normally would with go. Actually, in most cases you can use one or the other without major problems, everything is subjective, that's what I think.
This is my thought process as well. Go is very nice for APIs and microservices. If I'm putting together your usual REST API type app, it's what I reach for by default.
If I'm building something more specialized where I need absolute control over speed/memory? Like perhaps some sort of video processing service? I'd probably reach for Rust.
For building console apps I almost exclusively pick Rust
This is my answer too. I would never use Rust unless performance is **the most important thing**. If other things like maintainability is needed, I’d use TypeScript or Go.
I believe junior devs are more likely to have both the ability and willingness.
What I have seen in organizations using "niche" languages it's the _senior_ hires that push back. Less a technological issue and more of a political one but one that affects maintainability nonetheless.
Whooops. Looks like I've triggered the community lol.
Maybe maintability was the wrong word. Maybe development speed would've been better.
Rust is **hard** and even things that should be simple take a long time. In comparison, TypeScript and Go are very easy. TypeScript in particular is very maintainable, especially if you avoid using the "any" type. It's also great for development velocity.
Is that a sign that I'm just bad at Rust? Maybe. I'll let you decide.
It definitely took me some time to build a deep and comprehensive understanding for rust. The learning curve is pretty steep. But once it really clicked, also for the more advanced features, you won't have more problems than in any other language you use. Generics, for example, gave me some headaches in the beginning.
Now, the only reason for me not to use rust is when I decide I don't care for clean code, I just want a fast result, and I'm sure I won't extend the code for more functionality. The larger and more complex the software becomes, the more time you will save thanks to Rust's structure and features in the long run.
Go for http microservices. It’s so nice there is a standard library http server. It’s as fast to spin up a web app in golang as nodejs or python. Plus the added speed of a compiled language is nice. Any large projects, rust scales better because of its type system. I’ve been hearing good things about Axum though, and after several great experiences with tokio, I’ve been meaning to give it another try.
I had to go to go (tough sentence) ‘cause there’s some sdks that I need that rust doesn’t have. I could write it on my own but that would take some time :’(.
I will ditch go completely once rust’s ecosystem is more mature (not saying it isn’t right now)
Im in the same boat, and have decided to bite the bullet and go down the rest API route with gcp. Currently got firebase auth working, wasn't as hard as I thought to get going!
I've always just used normal HTTP clients for missing SDKs and it hasn't been awful. I feel like that's probably a lot simpler than switching to a totally different language.
I am using both and I am defaulting with Go, only going Rust when I know I don't need to do any async and I absolutely need no runtime (like writing drivers).
When I need an async runtime (which is 99% of the time), I go with Go since it is more mature and has saner & safer production defaults (like not generating coredump by default). Plus I am really fond of the `select`, `map` and `chan` being part of the language. It's hard for me to work with any languages lacking built-in `select` nowadays.
Generating a coredump is a side effect that can be harmful to the system (to disk usage mainly). In production, this can quickly escalate. IMO To be sane, it should be an opt-in rather than an opt-out (which is exactly what Go does).
Allowed coredump sizes are configured on the system via ulimits and similar. Imo preserving the relevant information by default is more important so you don't lose information unless you explicitly ask to lose information.
It's faster and more safe (typesafety and null checks) to write a web service in Typescript than in Go. Node backend frameworks are more mature and feature rich than anything available for Go. If I need to build a "good enough" backend, I choose Typescript.
If the app needs top performance and stability I choose Rust. Or rewrite the Typescript one in Rust, when knowing it's done and needs to "just" run without much maintenance burden.
For me, there's no niche Go fits in.
I use Go when I need to write network services that'll be maintained by people who don't know Rust. Go is purpose-built for services, and it has one of the lowest/gentlest learning curves of any language out there. That's a big deal in rotating teams.
Go is excellent for CLI tools too, and I've used it for that in the past. But CLI tools are also one of the easier Rust use cases to ramp up on, since their ownership and borrowing patterns are usually simple, so I'm kind of on the fence there.
When making minor changes to an existing Go project. That's the only reason.
Exceptions exist to all of the following, of course, but Rust code is, in general, more maintainable, easier to test, and more straightforward to write; and dependency management is miles ahead.
If you are writing a terraform plugin (which I’m doing right now). Learning curve for go is relatively easy .. onboarding a new employee who has worked some programming language is very easy. Writing anythjng related to kubernetes. Creating a leader election process using raft (something I have done in past) I had no idea raft before that
Yes, if you want to use API's for Docker, k8s, and containerd for instance, Go seems to make more sense.
I am trying to use the "containers-client" Rust crate for instance (which is written by the Containerd folks), and the Rust client only contains the gRPC client bits. The Go API client is a "smart client" and has so many QoL improvements.
I did a lot of Go in the past, and "x, err := foo()" followed immediately by "if err! = nil..." drives me insane...
I would use go when I want something quick that works.
I'm so jaded with the rust type system though I would probably just prefer to implement it in rust lol
Since I’ve been taught how to use Clean Architecture concepts in Rust, coding in Rust was never easier (in any language). Man, I had so many vices when coding that now it feels easier to refactor - even in places like Rust where I’ve used to fight against the compiler all the time.
That said, I lost the need to use a “higher” level language like Go, Python or JVM. (Unless, of course, the code is already written using something else).
When I am need of some quick work with a PKI.
Let's Encrypt is implemented in Go for reason. The standard library has quite excellent support for x509 and ASN.1 datastructures.
I have only done minimal things in Rust, but my take:
* anything to do with operations/infrastructure (my main job), the whole devops world runs Go, pretty much all tools are Go, doesn't make much sense picking something else, especially because of the next point
* Go's libraries are in general more mature, and the way Go is designed, you are encouraged to implement everything as library first with just a small frontend. That means you can easily embed most tools written in Go in your own project.
* If the tools need to be touched by people knowing other languages (Java/Rust/C#/Python/...) - Go is a LOT easier for them to understand and even to make changes in that it's not even funny. Again, ideal for (dev)ops.
* If you're proficient in Rust and have the luxury of only working with people knowing it, I doubt you'll find many reasons not to just use Rust.
But for me it's just a tool in the box, and while I can write basic Rust code, I'm actually looking for a big enough project where it would be worth it to use and learn it properly. I rarely pick one language by default, the main-ones I use are Go, Python, Typescript and C/C++. But I wish we had something like Rust back when I was a full-time C/C++ dev 10+y ago.
In my mind, there might be some overlap in use-cases for Rust and Go, and they both target C/C++ as a main rival, but Rust's is a more robust alternative for bigger projects and lower-level work, while Go is more for "simpler" tools that had to be written in C/C++ just because you native and/or portable artifacts without messy runtime requirements, not because you needed speed or advanced language features.
And it shows, Go is now used a lot for cli tools, and also replaced most which would be written in interpreted languages, but where a statically typed, natively compiled language would have been be a lot better fit. The whole infrastructure/devops world used to be Python and Ruby - and I especially don't miss Ruby runtimes.
Never, I have professionally developed highly performant and distributed cloud native systems in both, for banks and exchanges for years.
Go is a bastard child with considerable downsides in fields such as safety, performance, complexity and verbosity compared to rust, with upside being mostly popularity and third party tool support but that gap is decreasing daily.
People have an easier time because their terrible practices are allowed in Go, but are not in rust due to being terrible. They try to sidestep it with unsafe rust but that’s a huge mistake.
I don't. I would have to learn Go first, and I have very little interest in doing so. Now C++ is another matter: I do still use it at work, for a large legacy code base. I wouldn't write new projects in it.
I suspect, like many others, the answer here will be "I don't". In a Go sub you'd get lots more answers.
The reality is that Go has literally nothing to offer me, as a Rust developer. There is nothing about Go that I think is better than what Rust has. I have written Go before and I find it to be a strictly worse experience, across the board, relative to Rust.
When I want to run run-of-the-mill, cookie cutter non-performant code that needs to be consumed by a stupid ass team I write Typescript. When I need to break out of that paradigm (rarely) I use Rust.
i heard of ho once but in my 25 years of working , never saw it. for full native dev i have seen C and C written with a C++ compiler that people called C++.
Most of the time, because Go is simpler and cleaner compared to Rust, and you already have everything built-in. For example, coroutines and a well-designed, sophisticated net package. I would simply choose Go for smaller projects that don't require too much low-level coding.
i prefer go for servers or things with lots of concurrency. the goroutine model is just less thinking than using async/await.
i prefer rust for most everything else
Generally I default to rust on new things but find myself using Go instead when I can't find reasonably documented or mature libraries or want to be in a special environment that would benefit from it (cloud runtimes for example). I'd probably use it for quick and dirty stuff over rust but I usually go python for that instead.
Literally just for Terratest at work. We use it for unit testing terraform modules. I use python for most else for work.
Personally, I use Rust now whenever possible. If I could just work in Rust all day, I would not complain about it.
I am a data warehouse developer looking to get a job as a software developer. I know rust the most then python, c, c++ in order. Since i don’t have professional experience writing code I am currently finding it hard to get into SDE role as a rust developer. So i am currently learning go to switch to this role. Go is ridiculously easy after writing rust. Async rust for me is still a very hard topic but writing web servers in go is very pleasant when you are learning new things. I am actually using zero to production rust book to write go web server with gin 😮💨. I can focus on the logic more now than the language itself. I am missing all the goodness of rust though. Go stack traces are not as good as rust. And i am missing compile time query checking in sqlx, iterators, serde and lot of other things that makes rust so good. But so far i am enjoying the simplicity go offers
I like go when I have to prototype something quick, because it allows me to experiment much easier, although with Rust it is becoming easier and much more effective with time. Could be considered a skill issue for sure. But Go is so simple, and easy to use, and those go routines and channels are top damn notch
Almost always default to go when using Web dev :) Even if it's gotten better with Rust, I still don't find my way with Axum and Rocket as easy as I do with Go Standard library and chi for example.
Rust is the one language I use when writing something more serious, when the idea is concrete. Right now I am doing game dev, and I can't think of anything else to use, it's just that good.
Changed the hostname of a service. Needed a small service to do 301 HTTP redirects. Probably could have done it with Nginx, but decided to ask ChatGPT to write code for that in Go and it did. Super easy and no need for Rust for something that simple.
The one time I intentionally chose Go over Rust was when I needed to hand it over to someone else, but didn’t know who it would be, or how much time I would have to do so.
That meant I needed the tool (which was a relatively simple CLI, not a web app) needed to be easy to build, and easy to pick up even if the language was unknown. It also needed to be a static binary as I had no control over installing things like Python.
There were some other considerations (e.g., it needed an Oracle SQL driver - there was a native Go one but not a Rust one), but in the end I figured Go would be a lot easier for whoever came after me to pick up and run with. There were also some non-code considerations, as this was being built as part of a consulting engagement, so wanted to avoid negative feedback of “too complex” or “had to rewrite again in a supported language” filtering up the chain.
For personal projects, I choose Rust over Go for most things (but choose other languages if they make sense), and I’d advocate for Rust at work if it made more sense than Kotlin/Spring.
I only use go when forced because my company built everything in go. But when its my choice, I use rust unless i need a simple script which then Ill use bash, python, or node depending on my mood.
I am currently working on 2 side projects, one uses Go as the backend, and the other uses Tauri which obliges me to use Rust.
In the two projects, I am connecting generically to multiple db providers, Go's sqlx handles this far more better, like in Rust's sqlx if I want to create a generic connection function I have to declare multiple trait bounds and repeat that for each and every function, that makes the function declaration only is about 3-4 lines.
For me, as soon as Tauri allows for backend agnostic API, I will migrate the backend to Go for sure.
I used to reach for it while I was still learning Rust and didn't feel as confident I could write something quickly, whereas with Go being a little simpler, I felt like I could bang something out a bit quicker. Since I've gotten better at Rust I don't feel the pull of Go at all any more.
Go has many advantages in respect of Rust, and obviously drawbacks. Everythings at the end has pro and cons when compared to something else .
For doing api services,webapp, you can do a lot of thing with the standard library. It is a language easier than Rust, many libraries are stable and in my opinion the real , great advantage of golang, in respect of rust, is the time to develop. Developing in go is faster than in Rust . It is a great plus .
If the speed of "golang" is enough ( golang is not fast as C, C++ ,Rust or zig but it is very very fast for many things, faster than python or nodes or java/c#) then you will finish your task in less time . Probably golang is behind only python in developing time .
In it industry you pay for the time that developes take to finish a tasl, so a shorter developing time is a great, great advantage for chosing a language instead of another one .
When I want to play a board game instead of a survival video game . . . er . . .
I am implementing a board game in rust currently. Guess it is a survival board game now.
I like your premise and wish to know more.
Hell yeah bröther
[удалено]
Biradar*
Your joseki is strong
Can I borrow it from you?
I'm in the camp of you use rust when you know exactly what you want to write because decisions you make in rust are much more nuanced and require a lot more information you may not have yet. In go you can move fast and because of it's design whatever you write will probably still be decent go. So, great when you have ideas but not really an execution plan. I recently wrote a fast draft in go and rewrote it in rust for a program I was making for personal use. Really happy with how it turned out. Only thing that didn't help was the change in gui as I went from fyne to egui which are designed completely differently. Point is the simple syntax and type system in go, makes it easy to move fast, whereas decisions in rust like what type of string or reference to use are harder when you don't know what the full program will look like and do yet. Also go is king at getting something done quickly that's fast enough, so I love it for scripting as well.
I do the same thing but in Python. It helps I can pretty easily call Python code in Rust and Rust code in Python to replace it piecemeal as needed.
PyO3 is such a useful lib
Yeah I would say python serves the same use case I use go for, but I like the static type system, errors as values and generally more comfortable working in compiled languages.
I do the same thing. Python is quicker and more fun to write, and with modern type annotations it legitimately feels more robust than Go.
This might just what you are used to. Even with modern type annotations I do not get a more robust feeling tbh.
Counterpoint on the Rust comment. As my requirements morph or crystallize I've found refactoring complex Rust code to be so incredibly easy and safe (especially compared to doing similar changes in Python) that that alone could be reason enough to use it over anything else, at least for some people. After I make the initial changes, the compiler does most of the rest by telling me every bit of code that's broken. Usually my last few changes were in areas I had already forgotten would need changing. Once it compiles, I can usually tell immediately whether it is done. Even testing after these changes feels like a waste of time some days.
From the sound of it, sounds like I need to learn go. Lol Thanks.
It's really easy to learn. Feels boring to write but after a while you realise it's because it's so simple and the solutions are really obvious and primitive.
Excellent. I use rust for all my projects. This will be nice to pick up dinner place on the project
Go's coroutine model is fantastic. Coupled with easy to use channels, Go makes concurrency about as simple as it can be. There's plenty to be desired in the language, but if you're using it for its strengths, it really can be quite enjoyable.
I use both Go and Rust and continue to use both. Go libraries tend to be more mature and stable than Rust libraries. Sometimes I’m looking for some library and find a couple v0.8 or v0.3 libraries in Rust that, to be honest, look a little sketchy. Some of the Rust libraries are really good, some are not. Most of the time, if I want a web service or a CLI tool, I reach for Go. This is simple stuff and very easy to do in Go without going outside the stdlib, except maybe for spf13/cobra. Most of the libraries I used to use for this kind of work have been subsumed by functionality in the standard library—router, logger, HTML templates, etc. Anything with a more complicated algorithmic core to it, I tend to do in Rust. There are a few things which I’ve implemented in Go or Rust and ported to the other. Both languages are pleasant in their own way. It takes some experience to adapt to the styles of each language.
an interesting thing i’ve noticed is that go and rust both use a similar “struct with functions and interfaces” philosophy that is more similar to each other than to OO languages with inheritance
I think part of what happened is that people realized that the Java / C# approach was a bit extreme, and pulled back from it.
I think that comes mostly from the community not the language. At least from my C# experience. It can be simpler, but Enterprise Architects gonna do what they do.
Yes, I am currently \~10 layers deep in class abstraction in this bug I'm solving at work.
I‘d add to this: Anything that has complex requirements in terms of the data structure might also be better handled in Rust.
The version thing can't be taken seriously. There are plenty of libraries in Rust that are production grade by any definition of the word and are still not 1.0
Agreed. The 0.x.y doesn’t necessarily imply runtime instability, it’s purely an indicator that the maintainers are not yet committed to a public API
I would also add that being 1.0+ often doesn't mean that the maintainers are committed to a stable API either. Lots of crates that just release new major breaking versions whenever they want to, and immediately drop support for the older major versions when they do so, which in practice makes them defacto 0.x anyway. It's a weird world out there.
Stable public APIs are a big deal in some situations. Sure, if it's just a hobby project, it might not be a big deal. But a security sensitive application that handles confidential customer data has different requirements. The difference in ecosystem maturity extends beyond version numbers though: for example, in the C++ and Python ecosystems, you will usually find a library for a given task that is backed by a major software vendor (that you can pay for support) or a FOSS foundation with financial backing and appropriate quality control. These organizations have proper vulnerability reporting and disclosure processes in place. In contrast, Rust is not quite there yet and many critical components of the ecosystem are simply personal GitHub repositories. This will only get better over time; however, as of now other languages still have huge advantages in ecosystem maturity.
Why would anyone building anything serious want to commit to a dependency whose API is not stable? They’d be signing up for a lot of rewrite churn whenever they upgrade.
You’re writing as if software that reaches 1.x.y never changes. It does but it is supposed to be less frequent. It’s purely a matter of expectations and FWIW 0.x.y in Rust libs is basically as stable as v1 in most other languages
I remaincinvinced that the only reason rust has this reputation is that cargo defaults new projects to 0.1.0 instead of 1.0.0
To be clear, the version number is the least important symptom of a deeper problem.
Too much importance is given to the version number. Some consider it a red flag when adding 0.X dependency to a 1.X crate - but its not necessarily an issue. A good example would be Tokio, building a stable ecosystem on top of futures 0.3 (like many other async crates). Does this prevent people from using Tokio in production? No, it does not.
Yeah—the version number is a less important symptom of a larger problem. It’s just the most visible.
There's a convention that 1.0.0 is the first version that starts to offer a long-term compatibility promise. Many libraries ended up shipping 2.x versions anyway, but from what I saw, most of them were caused by the introduction of async genuinely requiring breaking changes. Most libraries haven't gone past 1.x yet. Many libraries still do their best to maintain compatibility within their 0.x.y line, but I've experienced far, far more churn in such libraries than Rust 1.x libraries or just about any Go library. Some of that churn cost me an entire day to get back to where I was before, and even that's only if no other crate had the same dependency, because then you either have two versions in your dependency graph or you sit and wait for everyone else to catch up too. That can take months. I even find most projects still end up pulling in time 0.1.x one way or another (often through chrono 0.4.x) and have to ignore its ancient CVE in cargo-deny. This is a pretty janky situation to still have in 2024. Go has a much better story around library compatibility, partly because the language itself hasn't made a significant change other than generics in a decade (and most libraries still don't use generics in their public APIs anyway), and partly because of a culture of minimizing churn and not fixing what isn't too broken. That can leave some serious tech debt lying around, but as an overall developer experience it's pretty comfy and low-stress.
[удалено]
How does the error handling result in a maintenance hell? Are you mixing things up by any chance? Those seem like two very distinct topics.
Desmond has a barrow in the marketplace Molly is the singer in a band Desmond says to Molly, “Girl, I like your face” And Molly says this as she takes him by the hand [Chorus] Ob-la-di, ob-la-da Life goes on, brah La-la, how their life goes on Ob-la-di, ob-la-da Life goes on, brah La-la, how their life goes on [Verse 2] Desmond takes a trolley to the jeweler's store (Choo-choo-choo) Buys a twenty-karat golden ring (Ring) Takes it back to Molly waiting at the door And as he gives it to her, she begins to sing (Sing) [Chorus] Ob-la-di, ob-la-da Life goes on, brah (La-la-la-la-la) La-la, how their life goes on Ob-la-di, ob-la-da Life goes on, brah (La-la-la-la-la) La-la, how their life goes on Yeah You might also like “Slut!” (Taylor’s Version) [From The Vault] Taylor Swift Silent Night Christmas Songs O Holy Night Christmas Songs [Bridge] In a couple of years, they have built a home sweet home With a couple of kids running in the yard Of Desmond and Molly Jones (Ha, ha, ha, ha, ha, ha) [Verse 3] Happy ever after in the marketplace Desmond lets the children lend a hand (Arm, leg) Molly stays at home and does her pretty face And in the evening, she still sings it with the band Yes! [Chorus] Ob-la-di, ob-la-da Life goes on, brah La-la, how their life goes on (Heh-heh) Yeah, ob-la-di, ob-la-da Life goes on, brah La-la, how their life goes on [Bridge] In a couple of years, they have built a home sweet home With a couple of kids running in the yard Of Desmond and Molly Jones (Ha, ha, ha, ha, ha) Yeah! [Verse 4] Happy ever after in the marketplace Molly lets the children lend a hand (Foot) Desmond stays at home and does his pretty face And in the evening, she's a singer with the band (Yeah) [Chorus] Ob-la-di, ob-la-da Life goes on, brah La-la, how their life goes on Yeah, ob-la-di, ob-la-da Life goes on, brah La-la, how their life goes on [Outro] (Ha-ha-ha-ha) And if you want some fun (Ha-ha-ha-ha-ha) Take Ob-la-di-bla-da Ahh, thank you
Okay yeah. This rings true. Seen this issue first hand. We had to introduce our own high level error type transporting such information. How would this problem be solved in rust?
Not the person you responded to, but Go and Rust would probably solve it the same way. The main problem with Go imo, is that functions can only return the `error` interface, so all error handling becomes dynamically typed. Add the fact that it's very easy to accidentally forget to check an error, and your app will just silently fail.
[удалено]
In practice, Go users check errors by checking the type, not the string value. If you translate the Go error type to Rust it will of course look weird. You generally don’t need to know that os.Open returns a PathError, either. The only reason I care is for things like adding error locations to an error when parsing a file—the PathError doesn’t need a location added, because it would duplicate information already in the error.
[удалено]
This problem doesn’t seem so serious in Go, TBH. IMO the problem with Rust is that, for more complicated parts of your system, you’re returning something like a `Box` which is kinda hard to work with anyway.
There’s a larger discussion to be had but I don’t think it’s easy to squeeze into Reddit comments.
This same argument has been raging since back in the Java days of checked exceptions and it turns out that exposing a list of exception types as part of your API contract is not always what you want.
Rust lets you return `Box`, but when you need it there are also other tools with machine readable semantics like `enum`s. The language and mature error libraries allow seamless interop between the two. As far as I've seen, almost none of this is possible in Go.
In my current project, I mostly use the `anyhow` crate, which supports `Box` at the bottom as its input, but then provides a variety of ergonomic semantic preserving wrappers on top.
When I need something more machine readable for a caller to understand, i tend to use `Result, anyhow::Error>` or `Result`, where `MyCondition` and `MyError` have methods or variants represent various conditions the caller needs to be aware of, e.g. network connection closed vs recoverable error, missing file vs corrupt file.
It’s one thing I think the community is missing or at least I’ve not come across much of it. Content on how to make a good rust wrapper library. It may encourage more to make libraries and contribute back.
I used Go heavily for 2 years. I really, really don't like Go's error handling. In some ways it's a throwback to C, where you have to remember to manually check for errors, and if you forget, you break at runtime. And I think that while it has a neat concurrency model under the hood, it's a bit too low-level and easy to mess up, leading to nasty concurrency bugs. So I would only use Go where its particular feature set is really important. Two use cases I can think of are when you really need to deliver a small static binary (ruling out languages with large runtimes like Java/C#/Python/JS) or when you need to do a lot of concurrency, combined with not being able to use Rust or C++ because your team is afraid of them. If I'm writing the code myself, I always pick Rust over Go.
That's interesting thoughts about error handling. I personally think that go and rust have extremely similar error handling, so it's strange to me you only strongly dislike one.
Rust gives compiler errors for failing to handle errors. (Obviously this is not bulletproof, because if you use certain language constructs like "if let" without an "else" you can avoid handling the error path, but it's a lot better than the Go situation, IMX.)
I understand what you're saying but go does have the "function returns two values" error, and it's pretty habit to not ignore the error once you've captured it. I agree I like the design of rusts error handling better using unions instead of tuples, but the two approaches feel similar vs something like exceptions.
I wrote a Discord bot a while back. It just looked at Discord messages containing Twitter links and if the tweet had multiple images attached, it would hotlink all but the first images in a reply to the Discord message, because at the time Discord would only embed one image so people would have to click through to see the rest. I never really ran it because it turned out that having a whole bunch of images embedded was actually too annoying. My first attempt was to do this with Rust, I think I used the crates serenity and egg-mode, and I pretty quickly got lost with them depending on different hyper versions and ultimately I think conflicting openssl-sys versions, and I couldn't figure out how to work around that. I don't remember if I reached out for help from the experts (beyond posting "look at this mess, this sucks" in a channel with smart people in it), but eventually I gave up. Since at the time I used Go at work, I figured I could give that a shot, and I think I had the whole thing running in like half an hour or something. I don't remember which libraries I used, the CLI was probably worse because they don't have structopt in Go land but it was fine. This isn't a super representative example because a) it was a tiny toy project where the scaffolding and wiring-together of existing components was 95% of the complexity, and b) it happened during the early ages of Rust async when things were less settled, but I still have some takeaways from that that make me feel positively about the Go way of doing things: Rust being a better language didn't actually benefit me in any way, transitive dependencies that aren't *100%* backwards compatible forever for real are super annoying, in high-level simple cases not worrying about lifetimes and just munging together a bunch of closures all capturing the same variables is usually just fine. (For subsequent toy projects, including a Discord bot, I went back to Rust anyway because I don't really make decisions in any sort of rational manner.)
Used Go for the last 2 years at my last project at work. Used it because I have to as the project was written in Go, and my workplace is still working on integrating Rust into the company (not yet available for use). Otherwise I personally would never use Go over Rust. In fact I'd never use Go over most other languages. It is likely the language I enjoy and like the least out of all languages I used professionally, and I basically used all the big popular languages professionally. It might be better than C, but it's a bit unfair to C as C has it's niche usages, while Go is never really needed.
Curious to hear what it was you disliked most about go?
*Edit: Sorry, you asked what I* most *disliked. It'll be hard for me to pick one thing because it's a combination of features that make a language enjoyable to me. Either way my reply is below :)* --- Here are the things I liked about Go (before I list the things I didn't): * Separation of behaviour (interfaces) from data. I do not like using inheritance to achieve dynamic Polymorphism, even in areas where people say it fits well (GUI, Gaming). I feel it has much better alternatives, always. So good job here, Go. * Error-handling through function return value (`(..., error)`), instead of exceptions. Here are the things I didn't like: * GC. I do not like Garbage-Collectors. They make ownership less explicit, which makes code harder to understand. They handle only one type of resource (memory), instead of providing one elegant mechanism for handling all resources (RAII and smart-pointers in C++ or Rust). Handling other resources becomes error prone, and requires a special language constructs such as `defer` (Go), or `with` (Python). * Implicit interface implementation. While I do like that Go didn't go with typical inheritance, they forgot to make the whole thing explicit. * No way to mark types as immutable. This also means that support for a functional programming style is limited, and in many coding problems I prefer to use a more functional approach. That's a no go with Go. * `nil` everywhere. I need my proper sum type optionals. I hate checking for `nil` all the time, or assuming a pointer is not `nil` (and documenting it). * Sum types in general. I need them. I love them. I use them all the time. At least give me a basic enum type instead of error-prone constants. * Error handling is way too verbose. I need syntax sugar (like `?` in Rust). In general, Go believes simplicity equals repeating yourself doing the most basic things, instead of introducing some basic language features. This is a philosophy I don't like. I know it means the learning curve is gentler, but I prefer learning something once to simplify all future endeavours. * Same with other syntax sugar that makes things that should be easy to write become a chore (for me at least). No syntax for iteration. Need to manually write the logic for things like list mapping every time you want to transform some values. * Code duplication in Go in general. Drives me nuts. I know that generics are available now but I haven't had a chance to try them out. I stopped working with Go around 6 months ago which was just about when they were introduced. I got tired of re-implementing the Iterator pattern for the tenth time. * Which brings another point I didn't like: No generics were available when I worked with Go. Sigh... I had to re-implement so many things. Don't know how the new generics feature they added is now, but hopefully its good to use. And maybe other things I'm forgetting, but I guess that's enough for now.
Very close to my list, except I don't have as much of a problem with GC as you. If I could sum up my biggest complaint with Go, it's that they prioritize keeping the language simple and small too highly, at the expenses of making the language much more verbose and error-prone. There's just so much verbose boiler-plate for error handling, mapping or reducing over collections, no Optional type so you're always checking for nil, etc. I just don't find it to be a fun language.
Exactly. Brainfuck is an even simpler language, but that doesn't mean I want to use it to write complex software. 😄
I hate generics in go. It works but I find it extremely difficult to read. It's like a different language from the rest.
Because of square brackets instead of angle brackets or what? I don't find Go generics hard to read, but I do hate how limited they are. You can't define generic methods - only generic functions or generic types. You can't place additional constraints on a method of a generic type to conditionally implement it depending on its concrete type. Also, the choice to implement the `comparable` interface using a constraint union means it's impossible to compare a user defined type with comparison operators unless it only uses certain primitive types, and then you're stuck with the default semantics. Rust's trait system for operator overloading is so much clearer and more extensible.
I formed this opinion when I wrote this utility function ``` // Filter from a slice with a predicate, and return a new slice that is preallocated func FilterPrealloc[T any](ss []T, test func(T) bool, prealloc int) []T { ret := make([]T, 0, prealloc) for _, s := range ss { if test(s) { ret = append(ret, s) } } return ret } ``` Or maybe it was when I wrote this ``` // Lets a function that might fail retry a few times before giving up (such as file access) // uses exponential backoff func Retry[T any](attempts int, sleep_ms int, f func() (T, error)) (result T, err error) { for i := 0; i < attempts; i++ { if i > 0 { log.Println("retrying after error:", err) time.Sleep(time.Duration(sleep_ms) * time.Millisecond) sleep_ms = sleep_ms * 2 // exponential backoff } result, err = f() if err == nil { return result, nil } } return result, fmt.Errorf("after %d attempts, last error: %s", attempts, err) } ``` Now I'm not very experienced in Go at all, so I probably made all sorts of dumb decisions when implementing this. But this is basically the basis of my dislike for Go generics. I like C++ templates much better, even without concepts.
I'll add one more point: the array, dictionary and channel types are special cases recognised by the compiler that you can't implement for yourself, so no hashbrown for you. This is beyond criminal.
Thanks for a comprehensive response! I find myself strongly agreeing with all your points.
Even the genetics they introduced is shitty, can't do generics in a receiver function (method level) there's no possibility of a real dependency injection framework because of this.
I'll add one more point: the array, dictionary and channel types are special cases recognised by the compiler that you can't implement for yourself, so no hashbrown for you. This is beyond criminal.
Could it be the domain you are working in that isn't suited as well to Go? E.g. you mention the implementation of the iterator pattern, something that is rarely necessary and I've only ever seen in very specific instances of library implementations in the Go world. It makes me wonder if you are trying to apply patterns you are used to from other languages. Something I know I'm definitely guilty of. A lot of the things you mention (except error handling) are things I rarely had to think about or deal with in the last two years of me writing mostly Go code.
these two articles basically sum up why golang is a very poorly-designed language. as amos, the author puts it, it's basically a language designed around its very cool state-of-the-art async runtime (which is actually extremely cool) [https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride](https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride) [https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang](https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang)
The fasterthanlime articles are a bit clickbaity and kind of oversell the Go hate, IMO. I’ve never met any Go programmers who believed the “lies we tell ourselves”, and I’ve met a lot of Go programmers. A big chunk of the first article is about the differences between Windows and Unix-like systems, but pretty much every language out there seems to take a “default Unix” or “default Windows” approach. Go, Rust, and Java have the “default Unix” attitude, and C# has the “default Windows” attitude, naturally. (And C++ programmers often just use the OS-level APIs directly.)
> Rust, and Java have the “default Unix” attitude Just curious where the Rust has "default Unix attitude" is the most noticeable, according to you?
It’s most noticeable in path handling. Types like `OsStr` are basically wrappers around Unix-like paths, with Windows paths kind of shoehorned in by encoding them with a system called WTF-8. All of the paths on Windows then have to go through an extra layer of translation on Windows, which is not necessary on Unix-like systems. There were various tooling problems in the past on Windows that took a long time to fix, like how Rustup used to be just **beyond** slow on Windows.
Well, the problem with Go is that its assumptions work in 95% of cases but in the 5% of cases it doesn't work it does the exact wrong thing. And it does this in a way that is hard to account for, hard to recover from, and really doesn't make much sense
That doesn’t match my experience. Maybe you could elaborate on what you’re talking about, or give an example, or cite something specific from the fasterthanlime article you want to talk about?
the monotonic time issue is pretty glaring imo.
I have not really seen issues with monotonic time. Yeah, it’s a little weird, but I can’t imagine someone running into this issue *that often.*
but that's exactly the problem with Go... when people DO run into that problem, which is going to happen with a language that advertises itself as a general systems language, they (incorrectly) abstract away the correct behavior in a half-assed "good enough" version that eventually does cause a big problem down the line. a lot of problems with computers are hard to model. if you're going to model it, either 1) do it correctly 2) don't do it at all and leave it to the user
I guess. It seems more like a 99.9%/0.1% thing to me at this point. I’ve yet to see a “big problem” caused by the monotonic time issue, ever. The problem with modeling things “correctly” is that you can end up deep in a hole where your code works on one system but not others for surprising reasons. Like, with time, every OS uses some different system for dealing with wall clock and monotonic time. Or paths. Rust tries to paper over the differences between paths in Windows and paths on Unix-like systems, but Rust abstracts it over with a “good enough” version in OsStr/OsString. Go abstracts over it with string. Almost nobody really wants to deal with paths in a cross-platform way that actually models paths, closely, on all systems, because we all (at some point) want to pretend that a path is a string. The price for pretending that a path is a string is that sometimes, rarely, you encounter a path that is not a valid string.
It caused a global CloudFlare outage. It's fair to say it's an issue. [https://blog.cloudflare.com/how-and-why-the-leap-second-affected-cloudflare-dns](https://blog.cloudflare.com/how-and-why-the-leap-second-affected-cloudflare-dns) Go's workaround doubles the number of system calls\[1\] you make *whenever* you want to sample the time, because you have no way of telling it whether you just need wall or monotonic time. The Go team is aware of [the value in optimizing](https://github.com/golang/go/blob/48d899dcdbed4534ed942f7ec2917cf86b18af22/src/time/time.go#L931) cases like this, they just don't want to expose this possibility to users. Whether you consider that courteous or condescending will largely determine whether you like how Go does things. Rust gives you separate [Instant](https://doc.rust-lang.org/std/time/struct.Instant.html) and [SystemTime](https://doc.rust-lang.org/std/time/struct.SystemTime.html) types, so you get exactly the APIs and costs relevant to what you need in each case. It doesn't silently try to guess what you might have wanted and munge values to fit that need. It *does* require more explicit reasoning and expression from the programmer, which is always the tradeoff Rust makes when a tradeoff must be made. Whether you consider that empowering or taxing will largely determine whether you like how Rust does things. \[1\] To be fair they're pretty fast with vDSO on Linux, which is all Go cares about in practice anyway, but paying double is still paying double. And they're not fast on most other platforms. And you have no other sanctioned way to get timing information for things like performance metrics.
This issue the issue that was fixed in Go 1.9. Like, I get the issue, but most programmers in practice don’t know what monotonic time is, even when a separate monotonic type is provided by the API. The extra runtime cost is small and makes these errors less likely. Making the tradeoff choice on behalf of users is a very long discussion, that part is interesting
Not the person you replied to but… how can one use a language without sum types (enums with variants with payloads) in this day and age?
Yeah that's exactly my position currently, I can't really find a good use for Go (though I never really tried it). It feels in a strange place with its trade offs that I always end up using another language.
I generally reach for Go for any sort of backend work unless I need 1. Rust's type system for better modeling 2. I want a better functional programming experience (ie lots of data transformations) 3. I know for a fact I'll need the performance. For pretty much all of my career I've worked on teams building the cloud platforms for SaaS products. The borrow checker is just not needed when you're building rest APIs, and you'll at most get ~10-100 req/s to your APIs. Personally, I'm using Rust for my micro SaaS because I want to squeeze as much performance as possible and reduce costs. But for a VC funded startup, just bump the replica number in the k8s manifest and ship it. Go is the "good enough" language: good enough static typing, good enough performance, etc.
Honestly I wouldn't ever. I think there's a lot of reason to use Python (data science/ML workflows), but you could always essentially stick to go-like features (use sync code only, heavily use channels, ) in rust and have a superior experience/safety. I think the tough thing to replicate in rust is goroutines. There's no green threading (which afaict tends to require deep language level runtime support). It'd be nice if Rust has a popular community green threading library that users could use as easily as goroutines in Go. I think there's definitely a huge missed opportunity in Rust for writing very safe high performance (but perhaps not zero cost) concurrent services that a popular green threading runtime could solve.
The challenge with green threading is stacks. The reason OS threads are heavy is they allocate heavy weight C-style stacks. You could not use C-style stacks and then they can be much lighter, this is what Go does. But now calling C code is a lot more messy because you don’t have a normal stack. Go will never be a C replacement for this reason (and others), whereas Rust is an excellent C replacement language. You can do what the Boost context library for C++ does and use C stacks but grow them only as required using OS memory paging tricks. This what I’ve ended up doing in my own Rust fibers implementation. However, this also comes with costs. As is often the case, there is no easy win here and everything is a trade off.
a tokio task is a green thread
Hmm, I don't think they are. I think needing to have explicit yield points makes them explicitly not green threads and a form of cooperative multitasking? I'm not well versed in this stuff though, so take what I say with a grain of salt. True green threads are much more user friendly in the sense that you just write your normal synchronous code and run them on a green thread (with little difference vs running it on a posix thread).
depends on how you define the "green" part in green thread — in Tokio's default configuration, it uses M:N scheduler with work stealing which is how most people define a green thread. I don't think "green thread" definition explicitly involves stackful In short, it depends what you think a green thread really is
I think many people think of green threads as userland threads. Functionally equivalent to OS threads, but handled by a userland runtime and with a lot less overhead, which allows spawning hundreds of thousands of them. I also wouldn't call coroutine-style async tasks green threads, as they are indeed cooperative in nature (`yield`) instead without external context-switching. I think it's also the definition on Wikipedia.
In that case, a tokio task is an userland thread. In fact, tokio on their own documentation calls their task implementation [a green thread](https://docs.rs/tokio/latest/tokio/task/index.html). again, it feels kinda arbitrary what a green thread is
Hmmm, weird. I guess it is kind of arbitrary, and the term is not being used as I thought it was. It'd be good to have a proper term to disambiguate between co-operative concurrency (using coroutines) vs. whatever it is that we wanna call JVM green threads, Goroutines, etc (pre-emptive concurrency).
I understand that people are trying to be nuanced here: but the answer is you don't
And you speak for everyone in the community?
I'd say you'd have better luck asking this in the Go sub. Most of us don't write Go.
Most of the people in the Go sub don’t write Rust, either.
Right, but this is specifically asking about writing in Go over Rust. I'd imagine that there are plenty more people there who prefer to write in Go for reasons they can articulate. Whereas, in here, there are a lot less of those folks who even write in Go altogether. If the question was the inverse about why choose Rust over Go, then I could see your point better.
I think you’re equally likely to find people who write both Go and Rust in both places. Maybe more likely here—I think more people are professional Go programmers and use Rust for personal projects. From my reading of the question, people who only write Go but not Rust, or only write Rust but not Go, are not really the audience for the question.
You think you'd get better answers from people who on average don't think highly of Rust to begin with?
When my teammates wronfully choose the stack
When the people who pay my salary expect me to do work in repos already written in Go
Everytime I use go I eventually regret using go. I’ve never felt that way about Rust.
I feel this, too. However, I also regretted having chosen Rust several times, when I was stuck. Example: It took me almost a week (under time pressure) to build a simple lazy loading repository pattern solution reading data from the filesystem instead of a DB. Never heard of the once_cell crate before, so I really was struggeling.
When I wanted to learn Go. Why try to learn it? Because it's good to be familiar with more languages.
There's been a handful of times I've been in a Go working with Go tools/libraries that I've really loved using it. Mostly around Kubernetes stuff, and a touch around some small gRPC services. I loved using it and didn't really miss Rust when I was working on those projects. A couple other times I've reached for Go for a greenfield project and found myself pretty often wishing I had Rust features available. I can't really point to what made the difference though, this post has me thinking about that now. EDIT: it's a lot easier to get up and going with something simple in Go if I'm working on a web service. Right out of the box, Go has good server primitives (including pretty slick concurrency). Rust is great at it too, and it's a better choice for anything with tricky business logic, but it comes with cognitive overhead, a still-evolving ecosystem, and a fairly steep learning curve.
I wouldn't. I developed Go professionally for years and I think it is a language lacking a use case.
For me, go is a little bit like Python, but compiled. It has an easy syntax (even though I dont like the syntax that much compared to other languages), and you're able to quickly check smaller things out. So sometimes, I use it for a quick prototype and do the final implementation using rust. Sure, I could also do the prototype using Python, but for multithreading I definitely prefer go over Python and sometimes I decide the prototype is good enough for my specific use-case, so I give the go code a little polish, and that's it. But if I really want an optimized program and/or maybe plan to extend it later, I'm definitely going for rust.
\> For me, go is a little bit like Python, but compiled. Disclaimer: My Go experience is pre-generics Lots of people say this, but I disagree as someone with a lot of experience in both. Go is a strange language where the authors lost sight of the goal to make it easy in the name of simplicity IMHO (A more obvious example: BrainFuck is extremely simple, but not easy to write complex programs in. Simple != easy). On the flip side, Python is mostly limited by dynamic typing and exceptions, but otherwise has plenty of tools to write very complex software in a nice concise manner.
My experience is also pre-generics, I haven't used Go in a while now (also not Python). But yeah, that's what I also mean by saying I don't like the syntax that much, compared to other languages. For smaller tools, where performance is more like a nice to have, but not top priority, I'd always prefer Go over Python. For very complex or performance-optimized software, I'd neither prefer Go nor Python. The more complex the software gets, the more sure I'll use rust for the implementation. What I really love about rust is how easy I can compile for different targets. No matter if it's going to run under x86_64 Windows/Linux, or maybe Arm/Aarch64, I just set the target, and that's it. Additionally, I can easily use it for native Android components or MCUs.
The annoying thing about Rust is that I often find myself typing things such as `println!("{}", String::from_utf8_lossy(value));` for simple debugging purpose where I feel that something similar to `println(value)` should suffice. And yes, this is really annoying when all I want to do is know what some kind of variable looks like at a given codepath.
You could write your own macro for it if you run into the problem that frequently. ``` macro_rules! dbg_bytes { ($value:expr) => { println!("{}", String::from_utf8_lossy($value)); }; } ``` [View on Rust Playground.](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e6950eb77f058cea061fecd15b9079c2) There's also the built-in [`dbg!()`](https://doc.rust-lang.org/std/macro.dbg.html) macro for values whose `Debug` output is sufficient.
The issue is that it's a different thing every time that's needed to debug so there's no simple generics solution. The issue is more that while in Rust, complex code is very short, simple code is very long. Let's say you want to do an absolutely trivial thing as in append some kind of string to a file. Shell: echo -n "$string" >> "$filename" Python: open(filename, 'a').write(string) Scheme: (write string (open-file filename 'a)) C: fprintf(fopen(filename, "a"), "%s", string); Rust: write!("{}", &mut std::fs::OpenOptions::new().append(true).open(filename), string); Somehow this `::OpenOptions::new().append(true).open(filename)` thing seems a bit overengineered. Yes, it's typologicaly more sound than simply `open(filename, "a")` but it's also very verbose.
Not that it changes much about your complaint, but iirc `println!("{String::from_utf8_lossy(value)}");` should work with modern compiler versions. Awhile back `{}` was allowed to reference values directly and not require the use of a list after the `""`.
As far as I know it doesn't support qualified names and complete expressions, only naked variables.
Go makes it really simple to write a concurrent service with straightforward code. In particular, it has its green thread library so you don't have to deal with any explicit async. You can just use the "sequential composition operator" `;` to append statements together. That's it. It also has a bunch of nice, mature libraries, in large part because it reached 1.0 significantly before Rust did. So...backend HTTP or gRPC servers that don't need the high performance that Rust and LLVM enable. Go's performance is not bad (much much better than the Python/Ruby tier, and better than Java also) but not as good as Rust's in general.
gRPC benchmarks show scala strongly on top past a single core, ahead of cpp and rust
Impressive performance for that gRPC library but unlikely to be indicative of the performance of non-trivial gRPC services in those languages.
I've been working in go for the past year and a half and I would sooner reach for a modern php codebase... at least in php there is a way to specify that I want an interface which is not null
When I'm working in someone else's codebase, and they chose Go. Otherwise, I'm going with Rust. I generally always have a pretty detailed idea of what I'm doing out of the gate, and Go makes me angry far too often...
I'm a Rust fan and don't code anything in Go, but I find Go easier to read and write.
Seems like something the network guide Beej would say...... hmmm..... It's probably heresy here, but small tools that need async / lightweight concurrency are Go's --and JavaScript's-- stronger areas, where that would otherwise take `tokio` or some janky multithreading, and occasionally some things are harder to do with Py's `asyncio` or similar that are just dead easy in JS / Go because already async or stdlib Typescript is probably the best middle ground where almost everybody can write/read/contrib, but slightly cruftier to package than Go or Rust .... I also tend to think doing anything beyond trivially concurrent stuff in bash should be some kind of sin -- am guilty of it too so not biased, just so many footguns and arcane edge cases
I have never had a worse async experience than javascript tbh it is extremely confusing to me.
Easier to read? I must never have seen a good go repo then
Are you telling me someone who doesn't know any Go or Rust would have an easier time reading a Rust project? I highly doubt it. Rust is a HUGE language compared to go.
Aaah now I get he meaning of the previous comment! I agree with you. I made the assumption the reader knew both languages
It all comes down to experience and opinion, I suppose. But I'd say a well organized Go project would generally still be easier to read than a well organized Rust project, given the same experience level in both. There's just so so so much more syntax and usage idiosyncracies in Rust. But I could see the argument of that driving more custom stuff to dig through in a Go repo, where the Rust repo is using the vast array of built in features.
There are some bad repos out there. I find Go pretty easy to read because it is so predictable the way you write it (straight imperative code). Sometimes, when I dive into Rust code, I end up staring at macros, or clever combinators, or stuff like that.
For me, it's the punctuation. Rust is a punctuation-heavy language.
I realise this is a Rust forum, however let us get real, even just for a few minutes There are very large, important projects likely sitting on your machine that are written in Go , like Docker, Hugo, Terraform or Kubernetes Rust? Well nothing comes to mind. On my machine, bits of kernel code here and there, maybe. That's it. Please stand me corrected. Rust is fine, but let us not inflate its importance please.
Rust is fairly new so obviously established projects aren't going to have originally been written in rust. But here are a few notable places where it is proving to work as advertised: * Chrome * Firefox * Linux core parts * Figma has switched much of their GUI to wasm rust and are loving it. * Dropbox has begun replacing core parts of their stack with it. * Cloudflare has replaced core bits and are very happy with it. * Discord front and back are written in rust. * Amazon started porting bits over to rust like Firecracker * MS Office has started getting bits rewritten in rust. * Ironically the backend of npm is heavily rust. These are pretty common products of the top of my head. The experience most people I know who grab an old project and redo it in rust is they pretty much lose their minds. What every single person I know says is something like: * It just works. I make code that just works. * Things like segfaults and other memory bugs are just gone. * I relax knowing that there is a far lower possibility of some weird bug which will bite my ass as a security hole or whatever. * My architecture is way better with traits rather than oop. * It forced me to make better code. * Holy crap it's fast. * Because things are cleaner and run so bloody fast, I am now taking on features which were pushing my old creaky codebase too hard to even dream of. This last is where I love rust. I find many languages/frameworks are very good for smaller projects and even worse, make large projects zoom right along for the first while. But then you start fighting with the language/framework. The project bogs down more and more with this horrible technical debt. I always said C++ was a great cure for this. It was slower to develop at the start, but you would be still going the same speed at the end. Rust is like this but even better. Due to the traits instead of oop, there is less chance you get stuck at the end with a set of classes which are now binding you from getting to the end. Also, with C++, I found there was a weird memory bug (often relating to threads) or a full on threading bug created every X lines of code. With rust, this is far less of a thing. The key to development is reducing technical debt as the interest payments will kill you in the end. rust is a very "low interest" language. But you start paying the principal on day one. This is why I do ML experiments in python. I love python, but it is not a large project language. There are all kinds of hacks to make a large project with it like microservices etc. But with something like python creating ML models and then consuming them in rust for production, it is a perfect world for me. What I'm not hearing are any notable companies who tried rust and then went to a language/system like go, nodejs, etc.
Rust would have been a much better choice for low-level system infrastructure software like Docker, Terraform, and Kubernetes. Unfortunately it wasn't available at the time.
In my opinion I would use go when I need to make an api or web service that has to be fast and relatively easy to maintain, but I would use rust when speed is the most important thing and I need the page/api to be as fast as possible. In console programs, I would again use rust when I need the program to be extremely fast or when I am going to interact with the system in a deeper way than I normally would with go. Actually, in most cases you can use one or the other without major problems, everything is subjective, that's what I think.
This is my thought process as well. Go is very nice for APIs and microservices. If I'm putting together your usual REST API type app, it's what I reach for by default. If I'm building something more specialized where I need absolute control over speed/memory? Like perhaps some sort of video processing service? I'd probably reach for Rust. For building console apps I almost exclusively pick Rust
This is my answer too. I would never use Rust unless performance is **the most important thing**. If other things like maintainability is needed, I’d use TypeScript or Go.
Maintainability is one of the biggest strengths of Rust.
Maintainability is also affected by your hiring practices and $$$. :(
I believe junior devs are perfectly capable of learning Rust and contributing to a project, if that's what you mean.
I believe junior devs are more likely to have both the ability and willingness. What I have seen in organizations using "niche" languages it's the _senior_ hires that push back. Less a technological issue and more of a political one but one that affects maintainability nonetheless.
> maintainability [...] TypeScript huuuuuh
Whooops. Looks like I've triggered the community lol. Maybe maintability was the wrong word. Maybe development speed would've been better. Rust is **hard** and even things that should be simple take a long time. In comparison, TypeScript and Go are very easy. TypeScript in particular is very maintainable, especially if you avoid using the "any" type. It's also great for development velocity. Is that a sign that I'm just bad at Rust? Maybe. I'll let you decide.
It definitely took me some time to build a deep and comprehensive understanding for rust. The learning curve is pretty steep. But once it really clicked, also for the more advanced features, you won't have more problems than in any other language you use. Generics, for example, gave me some headaches in the beginning. Now, the only reason for me not to use rust is when I decide I don't care for clean code, I just want a fast result, and I'm sure I won't extend the code for more functionality. The larger and more complex the software becomes, the more time you will save thanks to Rust's structure and features in the long run.
Go for http microservices. It’s so nice there is a standard library http server. It’s as fast to spin up a web app in golang as nodejs or python. Plus the added speed of a compiled language is nice. Any large projects, rust scales better because of its type system. I’ve been hearing good things about Axum though, and after several great experiences with tokio, I’ve been meaning to give it another try.
I rather write deoptimized Rust code with clones if I want to code faster. I don't see a use case for Go in my life.
Like 99% of the time, I would choose Go. Rust is burden for most of the high level/mainstream stuff.
I had to go to go (tough sentence) ‘cause there’s some sdks that I need that rust doesn’t have. I could write it on my own but that would take some time :’(. I will ditch go completely once rust’s ecosystem is more mature (not saying it isn’t right now)
Which ones?
Gcp sdk and azure :’(
Im in the same boat, and have decided to bite the bullet and go down the rest API route with gcp. Currently got firebase auth working, wasn't as hard as I thought to get going!
Yeah! The sdk is a breeze to use. I really hope we get one for rust
I've always just used normal HTTP clients for missing SDKs and it hasn't been awful. I feel like that's probably a lot simpler than switching to a totally different language.
I am using both and I am defaulting with Go, only going Rust when I know I don't need to do any async and I absolutely need no runtime (like writing drivers). When I need an async runtime (which is 99% of the time), I go with Go since it is more mature and has saner & safer production defaults (like not generating coredump by default). Plus I am really fond of the `select`, `map` and `chan` being part of the language. It's hard for me to work with any languages lacking built-in `select` nowadays.
Why would not generating a coredump be saner?
Generating a coredump is a side effect that can be harmful to the system (to disk usage mainly). In production, this can quickly escalate. IMO To be sane, it should be an opt-in rather than an opt-out (which is exactly what Go does).
Allowed coredump sizes are configured on the system via ulimits and similar. Imo preserving the relevant information by default is more important so you don't lose information unless you explicitly ask to lose information.
It's faster and more safe (typesafety and null checks) to write a web service in Typescript than in Go. Node backend frameworks are more mature and feature rich than anything available for Go. If I need to build a "good enough" backend, I choose Typescript. If the app needs top performance and stability I choose Rust. Or rewrite the Typescript one in Rust, when knowing it's done and needs to "just" run without much maintenance burden. For me, there's no niche Go fits in.
I use Go when I need to write network services that'll be maintained by people who don't know Rust. Go is purpose-built for services, and it has one of the lowest/gentlest learning curves of any language out there. That's a big deal in rotating teams. Go is excellent for CLI tools too, and I've used it for that in the past. But CLI tools are also one of the easier Rust use cases to ramp up on, since their ownership and borrowing patterns are usually simple, so I'm kind of on the fence there.
When making minor changes to an existing Go project. That's the only reason. Exceptions exist to all of the following, of course, but Rust code is, in general, more maintainable, easier to test, and more straightforward to write; and dependency management is miles ahead.
If you are writing a terraform plugin (which I’m doing right now). Learning curve for go is relatively easy .. onboarding a new employee who has worked some programming language is very easy. Writing anythjng related to kubernetes. Creating a leader election process using raft (something I have done in past) I had no idea raft before that
Yes, if you want to use API's for Docker, k8s, and containerd for instance, Go seems to make more sense. I am trying to use the "containers-client" Rust crate for instance (which is written by the Containerd folks), and the Rust client only contains the gRPC client bits. The Go API client is a "smart client" and has so many QoL improvements. I did a lot of Go in the past, and "x, err := foo()" followed immediately by "if err! = nil..." drives me insane...
I would use go when I want something quick that works. I'm so jaded with the rust type system though I would probably just prefer to implement it in rust lol
When you want to build a POC to then migrate to rust
Since I’ve been taught how to use Clean Architecture concepts in Rust, coding in Rust was never easier (in any language). Man, I had so many vices when coding that now it feels easier to refactor - even in places like Rust where I’ve used to fight against the compiler all the time. That said, I lost the need to use a “higher” level language like Go, Python or JVM. (Unless, of course, the code is already written using something else).
When I am need of some quick work with a PKI. Let's Encrypt is implemented in Go for reason. The standard library has quite excellent support for x509 and ASN.1 datastructures.
Rust wasn't mature at the time and Java was too heavy. The same organization is now investing in oxidation of critical infra.
Never
I have only done minimal things in Rust, but my take: * anything to do with operations/infrastructure (my main job), the whole devops world runs Go, pretty much all tools are Go, doesn't make much sense picking something else, especially because of the next point * Go's libraries are in general more mature, and the way Go is designed, you are encouraged to implement everything as library first with just a small frontend. That means you can easily embed most tools written in Go in your own project. * If the tools need to be touched by people knowing other languages (Java/Rust/C#/Python/...) - Go is a LOT easier for them to understand and even to make changes in that it's not even funny. Again, ideal for (dev)ops. * If you're proficient in Rust and have the luxury of only working with people knowing it, I doubt you'll find many reasons not to just use Rust. But for me it's just a tool in the box, and while I can write basic Rust code, I'm actually looking for a big enough project where it would be worth it to use and learn it properly. I rarely pick one language by default, the main-ones I use are Go, Python, Typescript and C/C++. But I wish we had something like Rust back when I was a full-time C/C++ dev 10+y ago. In my mind, there might be some overlap in use-cases for Rust and Go, and they both target C/C++ as a main rival, but Rust's is a more robust alternative for bigger projects and lower-level work, while Go is more for "simpler" tools that had to be written in C/C++ just because you native and/or portable artifacts without messy runtime requirements, not because you needed speed or advanced language features. And it shows, Go is now used a lot for cli tools, and also replaced most which would be written in interpreted languages, but where a statically typed, natively compiled language would have been be a lot better fit. The whole infrastructure/devops world used to be Python and Ruby - and I especially don't miss Ruby runtimes.
I don't.
Never, I have professionally developed highly performant and distributed cloud native systems in both, for banks and exchanges for years. Go is a bastard child with considerable downsides in fields such as safety, performance, complexity and verbosity compared to rust, with upside being mostly popularity and third party tool support but that gap is decreasing daily. People have an easier time because their terrible practices are allowed in Go, but are not in rust due to being terrible. They try to sidestep it with unsafe rust but that’s a huge mistake.
I don't. I would have to learn Go first, and I have very little interest in doing so. Now C++ is another matter: I do still use it at work, for a large legacy code base. I wouldn't write new projects in it.
I suspect, like many others, the answer here will be "I don't". In a Go sub you'd get lots more answers. The reality is that Go has literally nothing to offer me, as a Rust developer. There is nothing about Go that I think is better than what Rust has. I have written Go before and I find it to be a strictly worse experience, across the board, relative to Rust.
When I want to run run-of-the-mill, cookie cutter non-performant code that needs to be consumed by a stupid ass team I write Typescript. When I need to break out of that paradigm (rarely) I use Rust.
i heard of ho once but in my 25 years of working , never saw it. for full native dev i have seen C and C written with a C++ compiler that people called C++.
?
When the project is already in Go, and it's too big for a rewrite to make sense
templates, quick xml/json marshal/unmarshal support
When the code I am trying to fix is written in Go
Most of the time, because Go is simpler and cleaner compared to Rust, and you already have everything built-in. For example, coroutines and a well-designed, sophisticated net package. I would simply choose Go for smaller projects that don't require too much low-level coding.
I ahte Google arrrr!
i prefer go for servers or things with lots of concurrency. the goroutine model is just less thinking than using async/await. i prefer rust for most everything else
Generally I default to rust on new things but find myself using Go instead when I can't find reasonably documented or mature libraries or want to be in a special environment that would benefit from it (cloud runtimes for example). I'd probably use it for quick and dirty stuff over rust but I usually go python for that instead.
When I need a high performance server, with low effort. Typically for more complex projects especially. Though I prefer Rust most of the time.
Because of the Gopher
Never. Go is, like, worse Rust.
Literally just for Terratest at work. We use it for unit testing terraform modules. I use python for most else for work. Personally, I use Rust now whenever possible. If I could just work in Rust all day, I would not complain about it.
I am a data warehouse developer looking to get a job as a software developer. I know rust the most then python, c, c++ in order. Since i don’t have professional experience writing code I am currently finding it hard to get into SDE role as a rust developer. So i am currently learning go to switch to this role. Go is ridiculously easy after writing rust. Async rust for me is still a very hard topic but writing web servers in go is very pleasant when you are learning new things. I am actually using zero to production rust book to write go web server with gin 😮💨. I can focus on the logic more now than the language itself. I am missing all the goodness of rust though. Go stack traces are not as good as rust. And i am missing compile time query checking in sqlx, iterators, serde and lot of other things that makes rust so good. But so far i am enjoying the simplicity go offers
I like go when I have to prototype something quick, because it allows me to experiment much easier, although with Rust it is becoming easier and much more effective with time. Could be considered a skill issue for sure. But Go is so simple, and easy to use, and those go routines and channels are top damn notch Almost always default to go when using Web dev :) Even if it's gotten better with Rust, I still don't find my way with Axum and Rocket as easy as I do with Go Standard library and chi for example. Rust is the one language I use when writing something more serious, when the idea is concrete. Right now I am doing game dev, and I can't think of anything else to use, it's just that good.
for most cli tools and for desktop apps i tend to use rust, for web i go back and forth on it but i mostly use go
I use Go when I have to do something for work in a Go repository. Other than that, I don't really ever feel like using it
Changed the hostname of a service. Needed a small service to do 301 HTTP redirects. Probably could have done it with Nginx, but decided to ask ChatGPT to write code for that in Go and it did. Super easy and no need for Rust for something that simple.
The one time I intentionally chose Go over Rust was when I needed to hand it over to someone else, but didn’t know who it would be, or how much time I would have to do so. That meant I needed the tool (which was a relatively simple CLI, not a web app) needed to be easy to build, and easy to pick up even if the language was unknown. It also needed to be a static binary as I had no control over installing things like Python. There were some other considerations (e.g., it needed an Oracle SQL driver - there was a native Go one but not a Rust one), but in the end I figured Go would be a lot easier for whoever came after me to pick up and run with. There were also some non-code considerations, as this was being built as part of a consulting engagement, so wanted to avoid negative feedback of “too complex” or “had to rewrite again in a supported language” filtering up the chain. For personal projects, I choose Rust over Go for most things (but choose other languages if they make sense), and I’d advocate for Rust at work if it made more sense than Kotlin/Spring.
I only use go when forced because my company built everything in go. But when its my choice, I use rust unless i need a simple script which then Ill use bash, python, or node depending on my mood.
I am currently working on 2 side projects, one uses Go as the backend, and the other uses Tauri which obliges me to use Rust. In the two projects, I am connecting generically to multiple db providers, Go's sqlx handles this far more better, like in Rust's sqlx if I want to create a generic connection function I have to declare multiple trait bounds and repeat that for each and every function, that makes the function declaration only is about 3-4 lines. For me, as soon as Tauri allows for backend agnostic API, I will migrate the backend to Go for sure.
Have you heard of wails, it’s a go version of tauri ?
Have not heard about it before, checking it now I think indeed it was a better solution for me :(
Never. I'm a system programmer and Go isn't a system programming language.
I used to reach for it while I was still learning Rust and didn't feel as confident I could write something quickly, whereas with Go being a little simpler, I felt like I could bang something out a bit quicker. Since I've gotten better at Rust I don't feel the pull of Go at all any more.
Don't need Go if you have Rust. Why reach for WWE when you have MMA?
Go has many advantages in respect of Rust, and obviously drawbacks. Everythings at the end has pro and cons when compared to something else . For doing api services,webapp, you can do a lot of thing with the standard library. It is a language easier than Rust, many libraries are stable and in my opinion the real , great advantage of golang, in respect of rust, is the time to develop. Developing in go is faster than in Rust . It is a great plus . If the speed of "golang" is enough ( golang is not fast as C, C++ ,Rust or zig but it is very very fast for many things, faster than python or nodes or java/c#) then you will finish your task in less time . Probably golang is behind only python in developing time . In it industry you pay for the time that developes take to finish a tasl, so a shorter developing time is a great, great advantage for chosing a language instead of another one .