I know the OP said dont use external libraries, but I love bubble tea (And their related libs), they are a great reason to use Go for TUI
that said, I only use Go for hobby projects, I dont know how good it feels if you have to use it for work 40 hours a week
"This is getting really fucking irritating. Every 3rd comment on every HN post is "This is LLM", which has become a proxy for "I dont like it so it must be llm"
LLM witch hunts are tiresome.
(Perhaps the worst part too is that an accusation can be leveled and there's no way to counter. If it's a vacuous fluff piece, say so—irregardless of who/how it was written. And there we are judging a piece on its merits…)
Witch hunts are bad because they target innocent people and burn them at the stake. When the whole internet has been filled with LLM content, it is not unreasonable, expected even, that you start accusing everything of being an LLM, because, most likely, it is.
Normal humans who rant like, actually rant. This is AI generated rant.
In the parallel HTTP fetcher, the error is discarded. This will likely result in a panic when the response is nil. Also, what if it a server locks up? Or the underlying socket never connects and never times out?
I know it’s a toy example, but one must consider all these things in a real system. Go does have good pathways for these concerns, but it’s also easy to do it wrong. I still have to manually reason about access to variables/struct fields from multiple go routines.
The language that actually solves concurrency is Rust, but they will never acknowledge that.
It's one of the dullest, most mediocre languages out there and despite a nice toolchain and the fact it's undoubtedly a "safe" choice, I just have zero interest.
Things I dislike:
- if err != nil. Just give me some syntactic sugar instead of letting me write the same thing a bajillion time.
- no way to bind a struct to an interface. I'd like my IDE to tell me when I accidentally stopped implementing an interface
- some stdlib parts are too bare bones. Unpacking an archive requires me to handle all files, directories, links, etc. myself. There is no move command that can move a file or directory across fs boundaries. The little things.
var _ MyInterface = &MyStruct{}
var _ MyInterface = (*MyStruct)(nil)
These are the small things that annoy me about go.
I don't know about others, but Goland's analyser is pretty powerful and can navigate from interface to implementation(s) and vice versa.
Right, absolutely correct, Java is a great choice, so why does this post keep going on about Go?
I used to love Java but the complexity merchants showed up and ruined the party. 1.5 was just coming out when I stopped doing Java dev. Kotlin might pull me back into the fold though for when I can't use Go.
https://en.wikipedia.org/wiki/Java_version_history#Java_SE_8...
To be clear, all the annotation and Java EE stuff is still going if you want it!
Java's warts are far worse than Go. Everything is nullable. There's no module system to speak of. It's so IDE-dependant.
I agree with the spirit of "use boring technology." So thank god Go is boring enough that I don't have to write Java anymore.
Only reference types, the same as in golang (which also has nullable pointers, and its interfaces interact weirdly with null). Java is getting value types, which can be declared as non-nullable.
> There's no module system to speak of.
https://dev.java/learn/modules/
> It's so IDE-dependant.
Modern Java has been simplified that you can run a hello world program as follows:
$ cat Hello.java
void main() {
IO.println("Hello");
}
$ java Hello.java
Hello
Everything's a reference in Java except primitives, and even primitives get object wrappers. In Java, String, Long, and Bool can all be null. Go isn't like that—only explicit pointer types and interfaces can be nil. In practice it really cuts down on NPEs.
> https://dev.java/learn/modules/
Ok, granted, but I have never seen these in actual use. Java's ecosystem is big enough that you can use Java for years and not even know it has modules. I find this profusion of features unboring for the same reason that C++ is unboring.
In Go, everything's already in modules. It's just simpler. And when they did add generics, it was backwards-compatible, so there was no Java 8/Java 11 thing.
> Furthermore, any non-trivial project is better served with an IDE
In any other language, I can get by fine with vim + LSP regardless of project size. Java has a uniquely bad LSP story.
Lets write Web applications in C powered CGIs via LLMs instead. /s
And of course there is Rust, which compared to Go has better performance, lower memory usage, smaller binaries, safe concurrency, safe resource handling, and a real type system with tagged unions.
The Go team built good tooling around a mediocre language. Now most other languages have caught up, and Gophers are left writing mind numbing `if err != nil` checks with no benefits left to show for it.
Oh boy, the author has clearly not seen some of the Go codebases I’ve seen.
Haven't really used Go, but can't someone just `result, _ := foo()` and go on using `result`, not checking any errors?
The way Rust does it seems closer to forcing you to handle any errors in order to obtain the result (though it is still easy to just `.unwrap()` without properly thinking about it).
Even when it is intentional, like writing some quick/dirty code and planning on handling errors properly later, I'd imagine it's difficult to grep for instances of unchecked errors in the way you can with `.unwrap()` - though tooling should help.
You need a lot of linters e.g. to make sure errors are being handled, and the lack of algebraic data types make expressing data difficult.
I do think it has merits, but I’ll take type safety over simplicity