81–90 of 238 posts
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).
I would like someone to explain me Go. Really, I will use strong words but that's really what I feel. The syntax changes a lot from the C one, and I can't see any reason for it. To me, it looks unstructured, with the lack of colons for example. It ignores memory safety, it feels like it ignored all of the typing system research since C, no discriminated union, and structures and types in general are heavy to write. I…
Go, similar to Rust, has a horrible ecosystem, IMHO. I want to like it, but they already broke backwards compatibility with older systems (try to get the Go compiler running on a slightly older OS X, f.ex.), and for a compiler that's a no-go to me.
I regret to inform you, but the post was not about maintaining old systems, it was about simplicity in creating services using a language purpose-designed for creating services. The modern underlying os/docker image was kind of a baked-in assumption.
Maybe I develop games. Maybe I develop IoT devices. I might even be working in a high-stakes environment where formal verification is needed, who knows.
Whatever the case may be, we all have our reasons for choosing certain technologies. Not everyone is building run-of-the-mill 'backends' after all.
So please, let's stuff that neckbeardy arrogance away. It serves no purpose and distracts from the discussion.
Thanks.
P. s. I develop my backends in go.
Why is this flagged? Because of the swearing? Cause there have been previous posts with swearing in them? Or do people in general hate Go so much? 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
It's likely being flagged because people believe it's more AI-written than not
"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"
Go, similar to Rust, has a horrible ecosystem, IMHO. I want to like it, but they already broke backwards compatibility with older systems (try to get the Go compiler running on a slightly older OS X, f.ex.), and for a compiler that's a no-go to me.
Isn't that the same thing that Homebrew does? It only has CI for the last couple of Mac OS X versions. Seems like this is more of an issue with Mac OS X architecture than Go.
> The boring choice is the right choice. It always was. Right, absolutely correct, Java is a great choice, so why does this post keep going on about Go?
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.
I know it doesn't matter, but... ...who invented this letter-casing convention? import ( "embed" "html/template" "net/http" ) //go:embed templates/*.html var files embed.FS var tmpl = template.Must(template.ParseFS(files, "templates/*.html")) why is the name of a module lower-cased but the names of functions accessed via its namespace upper-cased? how does this make sense?
You cose something and if you don't use some weird 3rd party packages (Go stdlib is quite complete) you can check that code again in 3 years and will still work.
I like go, but a lot of little things stop me from loving it. Like, enums. I get a lot out of the box when I use an enum in Java or Kotlin. Converting to/from a String is trivial. Type safety ... exists. I can do that in Go, but I have to hack it in, for every single enum type I want to represent. Enums are not a thing in the language, which means its easier to keep the language in your brain all at once, but at the…