Live data from Hacker News

Just Use Go

blainsmith.com

161–170 of 238 posts

Re: Just Use Go

#161
post #81

> `if err != nil` is the feature, not the bug. It forces you to look at every place something can go wrong and decide what to do about it 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 t…

Personally, I don’t want to swallow errors I want to throw them. 90% of the time, I have a few small cross-cutting points (like an api controller) I want to catch and handle exceptions that get thrown from the rest of the code base.

Re: Just Use Go

#162
post #66
post #6

> 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?

EJB, Spring, Ant, Struts (I'm getting old - Like Hot Java Alpha 3 and Java applets old), maven, pom files, etc. 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.

jeberle made a completely factual reply to this, but people hate Java so much it's downvoted to dead.

Re: Just Use Go

#163
Every time I see those kind of posts, it seems reasonable on the surface. But then you remember than a typical web app might want to do something beyond just serving an HTML template.

Like, what if you want some styling or javascript along with your HTML? Either write everything by hand like it's 2003 again, or start inventing a complex pipeline from scratch in Go. Countless of people have spent thousands of man-hours on solving this problem, but you use Go, so now you do this yourself from scratch.

Or maybe your app needs some relatively complex database access? Writing SQL-spaghetti only gets you so far until you need to do conditional joins and unions and parameterized subqueries etc. God forbid you want migrations too. Go has no answer for this and you either have to hand roll all those things as well, or spend tons of time comparing countless libraries that do some of things you want, but not quite everything, or don't fit into your pipeline for whatever reason.

I'd take an opinionated framework with fat dependency stack that has way more features than I'd ever need over trying to reinvent migrations or CSS preprocessing from scratch in Go, thank you very much.

Re: Just Use Go

#164
post #39

I often think of go as a "better" python. As in, easy to learn and easy to use. But also performant and the module system and package manager seem to be a little neater. (sorry for flamebait) But I wonder how well it can cover similar use cases? Go is great for devops and web backends. But what about AI and data science?

If Go interfaced with C as well as Python, I’d use it a lot more. But I’m using the slower language because it still integrates with more things For example, one reason AI is all in Python is because CUDA is basically part of the C ecosystem (ie build system)

Have you tried purego?

You can just embed the C library into the binary of the Go app call it directly in Go. Most of the time I have found calling C from Go faster or on par with calling C from Python.

https://github.com/ebitengine/purego

Re: Just Use Go

#165
post #115

Earlier quoted context omitted.

The point being that's how you've decided to deal with the error, by ignoring it.

Silently ignoring errors by leaving out some boilerplate doesn't really seem like an active/forced decision, or a selling point over the languages it disparages ("[...] hellscape doesn't make errors disappear, it just hides them"). Then that the correct path is the one of more resistance seems poor design, in my surface-level opinion.

It is a decision though, and one you have to consciously make for each and every occurrence. You can't just hope some catch block will eventually handle it...

Re: Just Use Go

#166
post #61

Earlier quoted context omitted.

var _ MyInterface = &MyStruct{} Now your compiler will tell you you stopped implementing the interface. Pretty? No. But it works. And gopls will even offer to implement stubs for missing methods.

This also works: var _ MyInterface = (*MyStruct)(nil) In my mind as I read this, I am reminded that it is the receiver type *MyStruct that implements MyInterface. YMMV.

This is a useful hack but just imagine someone coming from another language reading this. They'd have no idea what it's for. It looks a bit like the things C people do to themselves. And all just because someone didn't want a keyword or another form of annotation to signal that a struct should implement an interface.

These are the small things that annoy me about go.

Re: Just Use Go

#167
post #66
post #6

> 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?

EJB, Spring, Ant, Struts (I'm getting old - Like Hot Java Alpha 3 and Java applets old), maven, pom files, etc. 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.

That was a long and dark time in history. We're still in the shadow of it. But these days a much better world is available - a more powerful language, good libraries, and much, much simpler frameworks.

To be clear, all the annotation and Java EE stuff is still going if you want it!

Re: Just Use Go

#168
> No base image CVE alerts every Tuesday.

Citation needed. Go's fat binaries and big stdlib cause most enterprise-mandated CVE scanners to light up with zillions of false positives constantly, because too much shit is present in the binary.

Logger package technically could speak protobuf over gopher, even though you use it to write text to syslog? Congrats, gopher and protobuf ecosystems are compiled in, with their vulnerabilities! Multiply that by every single golang binary anywhere in your system (seriously, I was getting CVE alerts for un-hardened stdlib cryptography in a 50loc file copying backup tool that could have been a shell script, and audio format conversion buffer underflow CVEs for Traefik, and many many more for months) and it adds up to a pain in the ass.

And heaven help you if you do actually have a vuln in third-party software that needs to be patched without an upstream fix (usually because "upstream doesn't make distributions on golang-$LATEST or $TRANSITIVE-$LATEST and they have a roadmap item to do that next millenium"). You can't install an updated transitive and fix it, you have to recompile and somehow distribute the whole thing. Doing that is never as simple as "go build" for big projects: the remaining 20% of build/toolchain needs that Go itself doesn't cover are inevitably fulfilled by the same pile of it-works-on-the-maintainer's-machine rickety Makefile bullshit we always had, but without even the sanity and conventions of autoconf and friends--and yeah, building others' Go projects in anger/in a hurry is enough of a pain in the ass that it makes me miss fucking autoconf.

On balance, I like Go. And there's a lot to hate about dynamic linking and package manager hell. But Go's approach is definitely not without its drawbacks in the CVE/security space.

Re: Just Use Go

#169
post #49

I got turned off of Go pretty fast by GOPATH shenanigans and polluting my home directory for no reason, since I don't think a programming language should really have any say on my filesystem. Error handling also seems pretty dumb in comparison to Rust. Admittedly Rust is a much more complicated language, but I felt like I could just go learn more Rust instead of bothering with Go and have more fun.

Doesn't Rust/Cargo dump stuff into your home directory as well? https://doc.rust-lang.org/cargo/reference/environment-variab...

Like, if the gripe is that Go should be better about following XDG conventions, fair enough. But pretty much every language other than C, C++, and Node tends to use system paths for transitives/compilation artifacts/registries/downloads.

Re: Just Use Go

#170
post #51
post #35

If you like a sort of weakly-typed version of Python or PHP, use Go. As the article points out it can be good for web forms. Not all development is web forms.

how is go a weakly typed version of python or php? or even more generic, how is go weakly typed? explain please.

I suspect that this is breaking type systems out onto separate axes: strong/weak and static/dynamic. Many consider Python to be strong/dynamic.
Post reply on HN