30 ms·

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

by mongol 2y ago

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.

Pet_Ant 2y ago
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.
jknoepfler 2y ago
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.
- mongol 2y ago
  Exactly
- vips7L 2y ago
  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.
  - Terr_ 2y ago
    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.
  - evantbyrne 2y ago
    Go has cross compilation.
  - hiAndrewQuinn 2y ago
    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.
  - jknoepfler 2y ago
    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)
    - mrkeen 2y ago
      Who the heck is on ARM (outside data centers)? Mac people, for a few years now.
tmiku 2y ago
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.
- mongol 2y ago
  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.
- ricardobeat 2y ago
  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.
  - Capricorn2481 2y ago
    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.
  - yxhuvud 2y ago
    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.
deleted 2y ago
[deleted]
booleandilemma 2y ago
Go refuses to compile if you have an unused variable and that is the opposite of quick and nimble.
gf000 2y ago
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.
lenkite 2y ago
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.

by mongol 2y ago

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.

Pet_Ant 2y ago

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.

jknoepfler 2y ago

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.

mongol 2y ago
Exactly
vips7L 2y ago
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.
- Terr_ 2y ago
  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.
- evantbyrne 2y ago
  Go has cross compilation.
- hiAndrewQuinn 2y ago
  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.
- jknoepfler 2y ago
  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)
  - mrkeen 2y ago
    Who the heck is on ARM (outside data centers)? Mac people, for a few years now.

tmiku 2y ago

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.

mongol 2y ago
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.
ricardobeat 2y ago
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.
- Capricorn2481 2y ago
  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.
- yxhuvud 2y ago
  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.

deleted 2y ago

[deleted]

booleandilemma 2y ago

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

gf000 2y ago

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.

lenkite 2y ago

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.