51–60 of 265 posts
[flagged]
The whole purpose of Go is to make building concurrent and scalable programs simple. Which is does achieve. Someone that knows basic Go can build a server that would be just as performant as one in Rust with no optimizing, no external dependencies, fewer lines of code, and in minutes not hours or weeks. Yes, obviously a server in Rust will be faster once you optimize it, but the point is that you don't really have to…
[flagged]
The whole purpose of Go is to make building concurrent and scalable programs simple. Which is does achieve. Someone that knows basic Go can build a server that would be just as performant as one in Rust with no optimizing, no external dependencies, fewer lines of code, and in minutes not hours or weeks. Yes, obviously a server in Rust will be faster once you optimize it, but the point is that you don't really have to…
[flagged]
The whole purpose of Go is to make building concurrent and scalable programs simple. Which is does achieve. Someone that knows basic Go can build a server that would be just as performant as one in Rust with no optimizing, no external dependencies, fewer lines of code, and in minutes not hours or weeks. Yes, obviously a server in Rust will be faster once you optimize it, but the point is that you don't really have to…
So unless you're only interested in playing around, what the core language can do isn't important. When writing a server in Rust, probably the first thing you would do is pull in Tokio/Tower or similar. At which point you'll already have a better foundation than Go provides out of the box, plus all the other benefits of Rust like a proper type system.
Adding manual arena memory management seems like a weird choice for a supposedly memory-safe and GC'd language where this is supposed to be an implementation issue. I mean, you should hear the screams from Rust/Go people about how bad C is, and now you're just going to do it?
> I mean, you should hear the screams from Rust/Go people about how bad C is, and now you're just going to do it? Wait until you learn how Rust now has a crate that implements seamless concurrent tracing GC, just like Go... https://redvice.org/2023/samsara-garbage-collector/
But if you have a compacting GC, you shouldn't need an arena. You should be able to get away with fixing the GC.
[flagged]
This sounds like a common mantra from people who love Rust to the point they'd use it even for basic scripting.
No, Go does not losing any mindshare to Rust whatsoever. Rust is an interesing choice when you need all these memory management tricks but treality is - in most cases you don't really care because Go is just good enough.
Add to this that developing in Go requires much less time and effort (in other words money) and you will see that it won't be replaces by Rust in areas of web dev, systems integration etc.
Rust is good for systems programming, embeded devices and so on.
Just when you think you have The Best Way of handling errors in Go figured out, they add yet another paradigm. Is a shared err type package on the way out? I use it to bubble up HTTP status codes consistently, is there a better way? Should you always use sentinel errors?
This is the same way of handling errors Go has always had. The point of Go errors is that they're just values; you program them like you would anything else. People have had multi-error packages for years, and Go encouraged it. Now there's a standard one.
[flagged]
>Go from losing more mindshare to Rust This sounds like a common mantra from people who love Rust to the point they'd use it even for basic scripting. No, Go does not losing any mindshare to Rust whatsoever. Rust is an interesing choice when you need all these memory management tricks but treality is - in most cases you don't really care because Go is just good enough. Add to this that developing in Go requires much…
Show me the empirical evidence otherwise it's just an opinion.
I also have an opinion which is that Go and Rust are about equal in complexity.
Earlier quoted context omitted.
>Go from losing more mindshare to Rust This sounds like a common mantra from people who love Rust to the point they'd use it even for basic scripting. No, Go does not losing any mindshare to Rust whatsoever. Rust is an interesing choice when you need all these memory management tricks but treality is - in most cases you don't really care because Go is just good enough. Add to this that developing in Go requires much…
> developing in Go requires much less time and effort Show me the empirical evidence otherwise it's just an opinion. I also have an opinion which is that Go and Rust are about equal in complexity.
I don't think this is really a "citation needed" kind of discussion. This is basically how Rust is advocated--you do work to satisfy the borrow checker, but in return, you get a program which is both high-performance and safe. In Go, the safety cost is paid at runtime.
I also wouldn't ask for evidence that Rust is faster than Go at runtime. This is well known.
If it helps, think of the language ecosystem, including Go and Rust, as Pareto-efficient.
[flagged]
This is a strange take to me. The last thing in the world that I would accuse the Go developers of is being frantic. There have been discussions about generics for a decade. See this post, for example, that goes into a bit of the history: https://go.dev/blog/generics-proposal Keep in mind that the arena thing is not from the Go developers for general purpose usage, I suspect it’s an internal detail that might be usef…
Now suddenly we have generics, and a bunch of other pretty significant changes, but no clear vision of where Go is going. Will "Go 2.0" with breaking changes happen or not? Will error handling be overhauled or not? Will radical changes proposed by core developers, like arbitrary-precision integers, be implemented? I'm not sure if there's really a lack of vision or just a lack of proper communication, but from the outside it's very confusing.
[flagged]