Hacker News Reader

Comment by mongol | Hacker News Reader

I don't think Java is fit for "the small". And there is nothing wrong with that. My go-to language for "the small" is Go. Java is good for enterprise heavy-lifting, not for quick and nimble tools.

View on HN

Every function call is 4 lines in Go. No basic error propagation support means Go code bloats up very fast in line count.

  result, err := callFoo()
  if err != nil {
      return nil, err
  }

No collection streams means LOTS of mind-numbing/eye-glazing for loops. Things have improved slightly with the slices and maps package but these are just hacks. Maybe with the new iterator support, Go will slowly and steadily get a bit more expressive.

Go is good for middleware coding thanks to Go-routines and and excellent networking support in the standard library but is cumbersome slow and inexpressive for scripts.

Also go.mod does NOT separate dev/test/prod dependencies - unlike Java Maven or Rust Cargo. You don't want your script dependencies coming into production code.

Go is severely less expressive than Java, so.. disagree. You will end up with longer files with more boilerplate for questionable benefits.

Also, in many areas Java's standard library is more expansive.

Can you tell us about how you use Go in the small? I like Go, but it doesn't strike me as particularly nimble for scripty use cases like this - error handling is part of it, but I know that's fixable with the Must() pattern.

I just write a small Go program. I agree that error handling is a weak point, but the tooling is well integrated. The article mentions that Java does not know about Maven. The go tool is much more versatile in that sense.

Also, go run is almost like running a script.

You can quickly whip up a single-file go program anywhere, without any boilerplate or setup:

    package main

    import "fmt"

    func main () {
      fmt.Println("hi")
    }

    // go run file.go

You can write this in any text editor, but using one with LSP support means that `import` statement is added automatically, and with CoPilot or another assistant, the `main` function writes itself as well as any `if err ...` statements. Go is extremely well suited to code generation due to how predictable it is.

Adding dependencies with `go mod` is uneventful.

It will never be as 'scripty' as JS or Ruby, but the readability, safety and performance are totally worth it.

I don't really see how this is different from `dotnet run`, `python main.py`, or `lua main.lua`. Like the commenter, I don't find Go very nimble.

Is limited features (Go) gonna be better for AI generation then breadth of examples? (C#). I'm not sure.

I see 3 or four lines of boilerplate in your example, depending on if the closing brace is counted or not. Compare with the following equivalent program in ruby or crystal (it is valid in both):

    puts "hi"

And the crystal version is just as typesafe and performant as the go version. I also find it more readable, but that is a very individual metric.

I don't think minimal examples are so useful. I reach for Go when bash is insufficient. That means there is a minimal starting size that is large enough that package and imports boilerplate are insignificant, all things considered

I love Crystal and have been a sponsor for a long time, but it's not comparable yet. Compiling is much slower, you have to manually add dependencies to shards.yml, cross-compilation is not as simple. And when it comes to scripts and tools, popularity / stability is a main concern.

This is literally longer than the java version mentioned in the article, and that can be started just as simply with a single command.

The question I responded to was 'how you use Go in the small', not a comparison to the post.

As I mentioned, yes, it's verbose, but simple and worth the effort and peace of mind. My primary language is JS, I've written a fair share of shell and Ruby but would still choose go a lot of the time, just because it doesn't pull in any extra complexity.

For the small I like Groovy. Especially as Grapes is like Maven but in annotations that you include in the script file. Being Java-based means that if it goes from "in the small" into something larger you are already on a stable foundation.

Go refuses to compile if you have an unused variable and that is the opposite of quick and nimble.

and you get a nice little portable binary that doesn't force someone to install a compatible version of an interpreter/virtual machine to run.

Exactly

That's if they're on the same architecture and operating system as you. Half the people I know are on mac, half of them are on arm. The other half are on windows and x86.

Now I'm having flashbacks to porting a whole stack of applications from x86 to a customized Linux distribution running on a big-endian PC platform. A mishmash of C/C++, Java, Node-JS, Python...

It was really dumb, but that's what the client needed. So much cross compiling.

Go has cross compilation.

Actually, you can specify to build portable binaries for all 3 of these platforms. You can even make them totally static, so that deployment is as easy as "copy the executable file with windows/Linux/Mac/etc in the name and run it".

This is part of my standard Go build.sh script. You just never know who might want to run a given thing where.

Who the heck is on ARM (outside data centers)? But yeah, with golang that's just:

GOOS=linux GOARCH=amd64 go build

GOOS=linux GOARCH=arm64 go build

GOOS=darwin GOARCH=amd64 go build

Which again, let's me distribute a binary to my end user as a single file, without directing them to install java or python3 or whatever.

(The ARM question is kinda immaterial, but I'm curious)

Who the heck is on ARM (outside data centers)?

Mac people, for a few years now.

Reply on news.ycombinator.com