41–50 of 75 posts
It highly depends on the nature of the project. I like Go, but after prototyping my side project in a bunch of lang. ended up using Python (FastAPI, SQLModel) because it was literally order of magnitude less code than say doing same thing in Go.
This horse has been long flogged to death. My list: Mostly fits in my head, gc, not horribly slow, boring concurrency, low effort cross-compilation, good distribution story. It's contentious but I like the "low abstraction ceiling". Go punishes people who want to turn everything into a framework or abstraction and rewards people who just knuckle down and write the code that solves the actual problem instance. Is it t…
What exactly does Go have over C# other than being “sexy” and an emphasis on minimalism? I’ve watched from the sidelines over the years. I hear more people talk about it than use it.
If you don't see a lot of people using it, maybe you're looking in the wrong place? I work with platforms, and Go is everywhere.
Earlier quoted context omitted.
> For example, in a language without generics, if you have 10 different versions of the same function that only differ by a type parameter, Can you give an example of why you would need to do this? I use go everyday and have never had multiple copies of the same function as described here.
There are tons of examples. So here's a random one: a function that sorts an array. You either need generics, need to write it using runtime polymorphism (making it significantly slower), or need to re-write it for every type of element that you want to sort an array of. The fact that Go has functions called sort.Strings, sort.Floats, sort.Ints, etc. is just silly duplication that wouldn't have happened in any other…
Doesn’t go having such type specific functions mean you don’t have to? Feels like that makes your codebase _less_ complex since the core logic is handled by the language stdlib, not code written and maintained by your team.
Earlier quoted context omitted.
For the record, I love Rust. It’s an amazing language and my example was not meant to discourage the use of Rust. But, it is verbose and generally takes longer time to write and understand compared to Go. For most projects, Go simply fits the bill for speed of development, ease of use, onboarding new people and performance.
> But, it is verbose and generally takes longer time to write and understand compared to Go. I respectfully disagree, and I don't think I'm alone in that. I would be willing to bet that the majority of people who have used both languages professionally would agree with me. Reading or writing N lines of Go is easier and faster than reading or writing N lines of Rust, true. But you have to repeat yourself so much in Go…
The repetition in Go, in my experience, mostly happens at the beginning and then you only have to deal with ‘if err != equal nil’, which to be fair is probably a good thing. Is it really more verbose and repetitive than error handling in rust?
I would love to have the type system rust has in go. It really allows you to be expressive and put in guard rails in a way you can’t using go. But I don’t think most applications need that.
My experience tells me something different than yours, maybe I’m wrong. But I can’t reconcile your arguments with my experience writing rust web applications. Even if I still miss writing my queries using sqlx and my views with asakama.
What exactly does Go have over C# other than being “sexy” and an emphasis on minimalism? I’ve watched from the sidelines over the years. I hear more people talk about it than use it.
Minimalism is the biggest selling point, if you are comparing it to C#. If you don't see a lot of people using it, maybe you're looking in the wrong place? I work with platforms, and Go is everywhere.
Earlier quoted context omitted.
There are tons of examples. So here's a random one: a function that sorts an array. You either need generics, need to write it using runtime polymorphism (making it significantly slower), or need to re-write it for every type of element that you want to sort an array of. The fact that Go has functions called sort.Strings, sort.Floats, sort.Ints, etc. is just silly duplication that wouldn't have happened in any other…
Wouldn’t you just use sort.Slice? Doesn’t go having such type specific functions mean you don’t have to? Feels like that makes your codebase _less_ complex since the core logic is handled by the language stdlib, not code written and maintained by your team.
https://pkg.go.dev/golang.org/x/exp/slices#Sort
Sort on its own is maybe not the best example because it's relatively easy to work around, but those workarounds quickly break down. Write me a function that returns the keys of a map in order without using generics...
I'm not exactly sure what your second point is.
Earlier quoted context omitted.
For the record, I love Rust. It’s an amazing language and my example was not meant to discourage the use of Rust. But, it is verbose and generally takes longer time to write and understand compared to Go. For most projects, Go simply fits the bill for speed of development, ease of use, onboarding new people and performance.
> But, it is verbose and generally takes longer time to write and understand compared to Go. I respectfully disagree, and I don't think I'm alone in that. I would be willing to bet that the majority of people who have used both languages professionally would agree with me. Reading or writing N lines of Go is easier and faster than reading or writing N lines of Rust, true. But you have to repeat yourself so much in Go…
go has excessive verbosity, poor error handling, rough edges for package/dependency management, and forces you to use interface for too many things. it’s not a bad language, but i would not choose it for a new project or base my company around it
But the verbosity and "one way to do it" is a plus for large enough teams. There's no need to decipher someone else's code when you come in to it. The way they did it is the way you'd do it, because there's just one way to do it.
Verbosity is less important for reading code than writing it, and on big projects you do a lot of reading.
It highly depends on the nature of the project. I like Go, but after prototyping my side project in a bunch of lang. ended up using Python (FastAPI, SQLModel) because it was literally order of magnitude less code than say doing same thing in Go.
I bet that just using standard C# and first-party back-end and ORM would have been even less code that works an order of magnitude faster, is easier to deploy and significantly less brittle.