I didn’t say it’s a war or anything like that, I actually like both languages, I just don’t see much of a point to Go anymore for my priorities. Look at my final paragraph:
So if syntax matters more than the benefits Rust provides, use Go. But if correctness is more important and you’re willing to put up with some verbosity, use Rust.
Go makes many things easy, and that’s absolutely a good trait to have. My point is that, long term, it has enough footguns that I’d rather put in the time to use Rust, which will prevent most of those by forcing me to contend with concurrency issues upfront.
If I want something quick, I’ll probably use Python. With Python, I have a lot fewer options to screw myself over with concurrency long term, which means worse performance, but I don’t need that for something quick.
I think Go makes sense if your project will remain small and focused, performance is really important (but not critical), and you’re familiar with it. It’s easy to write, easy to deploy, and has a high quality standard library. But long term, it has a lot of footguns that become serious issues as projects get larger.
Generics
Agreed. Go doesn’t need generics, what it needs imo are scope guards similar to Rust’s Mutex or Python’s with. defer is close, but it’s too easy to make a mistake. I have longed for deterministic destructors, but Go leans way too heavily on its GC to make that feasible.
Interfaces are good enough in most cases to provide what generics are intended to provide. I think there are problems in the implementation (e.g. interface{}((*int)(nil)) != nil; I’ve run into something similar way too often), but the concept is fine.
I never said Rust is the best language. I just said I don’t have a use case anymore for Go, because either I’ll want Python or Rust.
Yes, and I named some both in my original comment and this one.
Again, I don’t use Rust for everything. I made that clear I’m my original comment and this one.
Yes, Rust’s async is a bit tedious, and I mentioned that in my initial comment. However, you also get a lot of help from the compiler to eliminate most tricky concurrency bugs. I think that’s a fair price to pay for software that’s intended to be maintained long term. Go doesn’t, so I can’t recommend it for larger projects. Python gets halfway there, so it’s good enough for prototyping and smaller projects, so that’s what I reach for instead of Go, and that’s with using Go for almost 10 years (I started with 1.0).
C++
Yes, I think C++ is actually harmful, I see no value in using it whatsoever. The only reason I think it is still being used is inertia, so many libraries use it that it just has the lowest barrier to getting started. But that’s not a very good sales pitch (use C++ because everyone else does!).
I much rather write in C than C++ because at least that way I know I’m not likely to make assumptions that do not hold, so I’m much more careful.
Rust sucks at async and multithreading
That’s just not true. It’s perhaps the best language I’ve ever used for async and multithreading, and I’ve used plenty.
But I seem to be looking for something different than you. I want correctness so I don’t have as many tricky concurrency bugs to contend with in production, and I’m fine with development being a bit slower to get that. Async and multithreaded Rust can still have bugs, but at least not concurrent modification bugs.
You seem to be looking for quick prototypes, and Rust won’t give you that. That said, Rust has gotten a lot better in terms of async ergonomics in the last year or two, and I’ve found it incredibly productive for my async-heavy projects that the difference between prototype and production code isn’t that large. Once I noticed the kinds of issues that the borrow checker catches, I adjusted how I structure the code to be more provably correct, and I very rarely have compile issues anymore.
Go makes it way too easy to write multithreaded code, to the point where it’s easy to assume things are correct when they aren’t. Go is technically memory safe, but only in a “we’ll protect the system from your mistakes” sense and not a “we’ll help you avoid the mistakes” sense. Python is also memory safe, and it comes at the problem by making it difficult to write multithreaded code in the first place. That’s absolutely fine for prototyping.
problem with interfaces in Go, is that theyre not compile time. which means
No errors - debug later (HAHAHAHAHA EVIL) jk
Runtime-Casting.
So, tbh I dont think interfaces are a solution. Problem is that Go was built with “Simplicity in mind” and “Remove every single feature modern languages have” like enums … or generics … which were both made for very good reasons. And I hate that. It makes me think that some kind of hipster made that language (yes I know who the “hipster” is :P damn you Rob Pike and your hipster mind) and now they’re trying to retaliate with “putting Generics 10 years later” … generics that barely work or are useful at all, let alone the things they still don’t have but should have. I dont wanna pollute my package namespace with ““enums”” that have HUMONGOUS names just to make them different from other enums. Reminds me of C when Golang is supposed to be … “the modern C” or “how modern C should have looked like”?? (which is stupid assessment imo, it’s not comparable in any way) As they advertised it? Or at least I’ve heard that many couple of times.
Well let’s not be unfair, aside from things like enums or other features, sometimes generics do work, but in comparison with Rust’s, C++, C#, Java’s generics they’re not comparable at all. It’s like a drawing on top of Go. It doesn’t feel like it’s Go-ish and that Go has adopted generics properly at all. But still, good enough for making performant but not critical as you said projects, in an efficient way without having to deal with memory too much and still keeping some middle ground until you need the “critical” part.
tbh happy we came to a middle ground. thanks for discussing through it.
And I think the idea of interfaces is fine, just not Go’s implementation. Interfaces could be a compile-time, duck-typed abstraction with very basic runtime reflection (basically just a type-assertion switch), but they’re not. They instead leaned way too hard into it and made interfaces a value type, when they really shouldn’t be like that at all.
The vast majority of the time, I just want to pass a concrete type as an abstract type, and occasionally check if that abstract type has any extra features (e.g. does this io.Reader have a Close() error?). I’ve done runtime reflection a few times in Go, and every time it was a disgusting hack.
Rust goes the opposite direction and forces the developer to explicitly opt in to traits. That’s a bit more annoying, but it makes for much more scalable software. I don’t know how many times I accidentally didn’t implement an interface fully and my types didn’t come through until I ended up with forcing the compiler to help out: var_ someInterface = concreteType{}. I ended up doing that pretty much everywhere because I ran into so many times I accidentally didn’t fully implement a type.
I still think Go is a fine language, I just don’t think it scales well to larger applications. And that’s what I want to build, so I don’t use Go much anymore.
I didn’t say it’s a war or anything like that, I actually like both languages, I just don’t see much of a point to Go anymore for my priorities. Look at my final paragraph:
Go makes many things easy, and that’s absolutely a good trait to have. My point is that, long term, it has enough footguns that I’d rather put in the time to use Rust, which will prevent most of those by forcing me to contend with concurrency issues upfront.
If I want something quick, I’ll probably use Python. With Python, I have a lot fewer options to screw myself over with concurrency long term, which means worse performance, but I don’t need that for something quick.
I think Go makes sense if your project will remain small and focused, performance is really important (but not critical), and you’re familiar with it. It’s easy to write, easy to deploy, and has a high quality standard library. But long term, it has a lot of footguns that become serious issues as projects get larger.
Agreed. Go doesn’t need generics, what it needs imo are scope guards similar to Rust’s
Mutexor Python’swith.deferis close, but it’s too easy to make a mistake. I have longed for deterministic destructors, but Go leans way too heavily on its GC to make that feasible.Interfaces are good enough in most cases to provide what generics are intended to provide. I think there are problems in the implementation (e.g.
interface{}((*int)(nil)) != nil; I’ve run into something similar way too often), but the concept is fine.Yes, I think C++ is actually harmful, I see no value in using it whatsoever. The only reason I think it is still being used is inertia, so many libraries use it that it just has the lowest barrier to getting started. But that’s not a very good sales pitch (use C++ because everyone else does!).
I much rather write in C than C++ because at least that way I know I’m not likely to make assumptions that do not hold, so I’m much more careful.
That’s just not true. It’s perhaps the best language I’ve ever used for async and multithreading, and I’ve used plenty.
But I seem to be looking for something different than you. I want correctness so I don’t have as many tricky concurrency bugs to contend with in production, and I’m fine with development being a bit slower to get that. Async and multithreaded Rust can still have bugs, but at least not concurrent modification bugs.
You seem to be looking for quick prototypes, and Rust won’t give you that. That said, Rust has gotten a lot better in terms of async ergonomics in the last year or two, and I’ve found it incredibly productive for my async-heavy projects that the difference between prototype and production code isn’t that large. Once I noticed the kinds of issues that the borrow checker catches, I adjusted how I structure the code to be more provably correct, and I very rarely have compile issues anymore.
Go makes it way too easy to write multithreaded code, to the point where it’s easy to assume things are correct when they aren’t. Go is technically memory safe, but only in a “we’ll protect the system from your mistakes” sense and not a “we’ll help you avoid the mistakes” sense. Python is also memory safe, and it comes at the problem by making it difficult to write multithreaded code in the first place. That’s absolutely fine for prototyping.
problem with interfaces in Go, is that theyre not compile time. which means
So, tbh I dont think interfaces are a solution. Problem is that Go was built with “Simplicity in mind” and “Remove every single feature modern languages have” like enums … or generics … which were both made for very good reasons. And I hate that. It makes me think that some kind of hipster made that language (yes I know who the “hipster” is :P damn you Rob Pike and your hipster mind) and now they’re trying to retaliate with “putting Generics 10 years later” … generics that barely work or are useful at all, let alone the things they still don’t have but should have. I dont wanna pollute my package namespace with ““enums”” that have HUMONGOUS names just to make them different from other enums. Reminds me of C when Golang is supposed to be … “the modern C” or “how modern C should have looked like”?? (which is stupid assessment imo, it’s not comparable in any way) As they advertised it? Or at least I’ve heard that many couple of times.
Well let’s not be unfair, aside from things like enums or other features, sometimes generics do work, but in comparison with Rust’s, C++, C#, Java’s generics they’re not comparable at all. It’s like a drawing on top of Go. It doesn’t feel like it’s Go-ish and that Go has adopted generics properly at all. But still, good enough for making performant but not critical as you said projects, in an efficient way without having to deal with memory too much and still keeping some middle ground until you need the “critical” part.
tbh happy we came to a middle ground. thanks for discussing through it.
Yeah, no worries.
And I think the idea of interfaces is fine, just not Go’s implementation. Interfaces could be a compile-time, duck-typed abstraction with very basic runtime reflection (basically just a type-assertion switch), but they’re not. They instead leaned way too hard into it and made interfaces a value type, when they really shouldn’t be like that at all.
The vast majority of the time, I just want to pass a concrete type as an abstract type, and occasionally check if that abstract type has any extra features (e.g. does this
io.Readerhave aClose() error?). I’ve done runtime reflection a few times in Go, and every time it was a disgusting hack.Rust goes the opposite direction and forces the developer to explicitly opt in to traits. That’s a bit more annoying, but it makes for much more scalable software. I don’t know how many times I accidentally didn’t implement an interface fully and my types didn’t come through until I ended up with forcing the compiler to help out:
var _ someInterface = concreteType{}. I ended up doing that pretty much everywhere because I ran into so many times I accidentally didn’t fully implement a type.I still think Go is a fine language, I just don’t think it scales well to larger applications. And that’s what I want to build, so I don’t use Go much anymore.