3 ms·
For me Go is a smooth brain C with an enormous standard library, making it very pleasant for weekend side projects or quick and dirty "scripting". Not having su
by platinumrad 9y ago
For me Go is a smooth brain C with an enormous standard library, making it very pleasant for weekend side projects or quick and dirty "scripting". Not having sum types is a huge pain sometimes and generics would be nice but otherwise I wouldn't want the language specification to change too much. Tail call optimization would also be nice but that's on the implementation side. In particular, I wouldn't want Go to become more restrictive like Rust or Haskell.
- egeozcan 9y agoI wanted to use go for scripting but working with gopath weirdness made me hate my life and went back to nim (which is perfectly fine, I just still envy the go ecosystem).
- weberc2 9y agoThis is the opposite of my experience. I picked up Go 5 years ago because it was the only (reasonably mature) programming language I could find that didn't require a turing complete programming language (Python, CMake, Gradle, etc) or a sufficiently complex configuration format that it may as well be a programming language (ANT, MSBuild, etc). GOPATH took me a few hours to figure out at the time, but that was because the documentation was incredibly sparse at the time (this was before Go hit 1.0). Now it's just: mkdir -p ~/go/src/hello echo "package main" >> ~/go/src/hello/main.go" echo "func main() { println("Hello world") }" >> ~/go/src/hello/main.go" go build hello ./hello
- majewsky 9y agoYou do not need any of this. You can use `go run` with a source file outside the GOPATH. Put the following in a file, make it executable and execute it: ///usr/bin/env go run "$0" "$@"; exit $? package main import "fmt" func main() { fmt.Println("Hello World") }
- weberc2 9y agoMy point was to show that GOPATH is easy; not the fastest path to hello world. :)