Go doesn't have a build system, so I don't have to learn that. (I spend every second I'm using Gradle to curse it's very existence -- and wish I had `go build`)
Go cross compiles natively, so I don't have to think about the toolchain.
Go has go:embed, so I don't have to think about bundling/packaging as a separate step.
Go has fantastic backwards compatibility, so I don't have to spend time getting an old project to even build.
Go's stdlib is extremely high quality, so much so that I've never run into a serious bug in it.
When jumping into other ecosystems, I'm shocked at how much time is spent fiddling with build scripts, packaging, deprecations, unfixed bugs in the tooling etc...
Still wish it didn't explode on null pointers though. And any large dependency authored by Google will be unidiomatic and over-complex, of course (see: grpc)
Very well said. As someone who rarely touches Go (only used it for a couple of simple web servers, something like a WebSub subscriber), you've named much of what I like about it. I'd love to see more languages achieve all these features, or even make that a goal.
I'd also mention how great the documentation is. Truly best in class. For instance, see https://pkg.go.dev/net/http
* Has enough examples to fully understand how to use the package.
* Links to the individual source code files so you can read those if needed.
* Has a highly visible link for reporting vulnerabilities.
* Has a great search tool accessible with a keyboard shortcut.
Lack of support for operator overloading is a bit sad. As a result, Go can't get used in numerical applications, unless you like writing `matrix_plus(A, B)` instead of `A + B`.
Is there a programming language that has a "simple" design like Go but which supports some operator overloading?
But then you'll soon want to do A*B+C, and you'll find that fused multiply/add is a much faster operation than doing a multiplication and then addition, and soon you'll either be writing mul_add(A, B, C) anyway, or you'll overengineer a complex solution to make A*B return some kind of object that can recognize the subsequent + operation etc.
I'm really not a fan of small qol features like this. I think it really hurts readability for the general audience. The function itself is minimal overhead and is clearer to the reader.
I mentioned this before, but I wish that Go has a Numeric interface where operator overload methods can be added and confined only for numerical objects.
I once had a hard time finding a bug, and it turned out someone had overloaded assignment to the boolean member dbIsOpen in some inherited monstrosity class to open/close a database connection. Since then, I prefer functions with clear names. They may still not do what their name says, but it doesn't lull you into thinking local.
I think the right answer to your question would be NimLang[0]. In reality, if you're seeking to use this in any enterprise context, you'd most likely want to select the subset of C++ that makes sense for you or just use C#.
Zig also does it this way and I think it makes sense. Operator overloading gives the same symbols different semantic meaning in different contexts. This hurts readability and simplicity.
I was with you until you slagged on the other options. Rust and Scala are designed for other use cases than yours. That doesn’t trivialize their worth.
This is just a personal opinion. No offense intended if you disagree.
I started go 6 months a go and while I like the language I hate the team. There's so much emphasis on making everything elegant perfect, organized and clean and the way go is designed just doesn't fit well with that. I feel like I'm working with a giant java program.
Looking at the libraries I feel this is the go culture. Elegance over simplicity seems to be the philosophy and that leads to java like programs rather than c like programs.
I personally liked the language but the ecosystem and the culture around it I'm not particularly a fan of because it's so at odds with the design of the language.
Funnily enough many years back before generics I didn't feel this way about the language. Now I do, so it might be that?
Your comment makes it look as if you're saying you hate the Go development team, but it seems that isn't the case.
I get a little of what you're saying, I wouldn't say I hate anyone, but I strongly dislike how a lot of projects are organized. I think a lot stems from https://github.com/golang-standards/project-layout , which pretended to be standard and was so (ab)used one of the creators opened an issue about it. If you look at the actual Go src, it's much, much cleaner.
[+] [-] oefrha|2 years ago|reply
Go: What we got right, what we got wrong - https://news.ycombinator.com/item?id=38872362 - Jan 2024 (694 comments)
The outline of that post is very clear, you can skim the original very quickly.
That link is conspicuously missing here, giving readers the impression that the talk is only available in video form. Not cool.
[+] [-] misoukrane|2 years ago|reply
[+] [-] iamcalledrob|2 years ago|reply
Go doesn't have a build system, so I don't have to learn that. (I spend every second I'm using Gradle to curse it's very existence -- and wish I had `go build`)
Go cross compiles natively, so I don't have to think about the toolchain.
Go has go:embed, so I don't have to think about bundling/packaging as a separate step.
Go has fantastic backwards compatibility, so I don't have to spend time getting an old project to even build.
Go's stdlib is extremely high quality, so much so that I've never run into a serious bug in it.
When jumping into other ecosystems, I'm shocked at how much time is spent fiddling with build scripts, packaging, deprecations, unfixed bugs in the tooling etc...
Still wish it didn't explode on null pointers though. And any large dependency authored by Google will be unidiomatic and over-complex, of course (see: grpc)
[+] [-] bscphil|2 years ago|reply
I'd also mention how great the documentation is. Truly best in class. For instance, see https://pkg.go.dev/net/http
* Has enough examples to fully understand how to use the package.
* Links to the individual source code files so you can read those if needed.
* Has a highly visible link for reporting vulnerabilities.
* Has a great search tool accessible with a keyboard shortcut.
* Clearly marks deprecated functions.
* The page even works without Javascript enabled.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] ogogmad|2 years ago|reply
Is there a programming language that has a "simple" design like Go but which supports some operator overloading?
[+] [-] tsimionescu|2 years ago|reply
But then you'll soon want to do A*B+C, and you'll find that fused multiply/add is a much faster operation than doing a multiplication and then addition, and soon you'll either be writing mul_add(A, B, C) anyway, or you'll overengineer a complex solution to make A*B return some kind of object that can recognize the subsequent + operation etc.
Update: corrected * representation
[+] [-] campbel|2 years ago|reply
[+] [-] didip|2 years ago|reply
[+] [-] tomcam|2 years ago|reply
Think that one through again
[+] [-] scaredginger|2 years ago|reply
[+] [-] tgv|2 years ago|reply
[+] [-] jimbob45|2 years ago|reply
[0]https://nim-lang.org/
[+] [-] coldtea|2 years ago|reply
I am.
Also, this would be trivial with a DSL and a preprocessor, so...
[+] [-] __loam|2 years ago|reply
[+] [-] munificent|2 years ago|reply
https://en.wikipedia.org/wiki/CLU_(programming_language)
[+] [-] cyberpunk|2 years ago|reply
[deleted]
[+] [-] kstrauser|2 years ago|reply
[+] [-] tikhonj|2 years ago|reply
As we know, any technology that would require experienced programmers to learn something is a crime against engineering.
[+] [-] adamnemecek|2 years ago|reply
Rust is the most pragmatic language out there.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] ninetyninenine|2 years ago|reply
I started go 6 months a go and while I like the language I hate the team. There's so much emphasis on making everything elegant perfect, organized and clean and the way go is designed just doesn't fit well with that. I feel like I'm working with a giant java program.
Looking at the libraries I feel this is the go culture. Elegance over simplicity seems to be the philosophy and that leads to java like programs rather than c like programs.
I personally liked the language but the ecosystem and the culture around it I'm not particularly a fan of because it's so at odds with the design of the language.
Funnily enough many years back before generics I didn't feel this way about the language. Now I do, so it might be that?
[+] [-] silisili|2 years ago|reply
I get a little of what you're saying, I wouldn't say I hate anyone, but I strongly dislike how a lot of projects are organized. I think a lot stems from https://github.com/golang-standards/project-layout , which pretended to be standard and was so (ab)used one of the creators opened an issue about it. If you look at the actual Go src, it's much, much cleaner.
[+] [-] mseepgood|2 years ago|reply
Can you link to where you have interacted with them personally, so that we can judge whether your hatred is justified?