5 ms·

> for me what is great about Go is it removes BS and incidental complexity, & is just really well-designed and pleasant to work with. i happily choose it for pe

by adwhit 9y ago

> for me what is great about Go is it removes BS and incidental complexity, & is just really well-designed and pleasant to work with. i happily choose it for personal projects. Go was the first compiled language I learned coming from Python and scientific computing. And I felt the same way and was so delighted to write fast native multithreaded code without ceremony. But then I learned some other languages that have elegant and powerful type systems (namely, Rust, OCaml and Haskell) and now I'm somewhat disgusted at my former self. Go could have been great, but it ain't. It's a blub language if ever there was one. I know my opinion on these things doesn't matter. But I feel resentful of Go, I feel like I was duped.

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 ago
  I 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 ago
    This 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 ago
      You 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 ago
        My point was to show that GOPATH is easy; not the fastest path to hello world. :)
chickenfries 9y ago
To be fair, Go never promised you the future. The documentation and community is pretty oblique about their values.
dilap 9y ago
i've played around a bit and with haskell and ocaml, very interesting languages. i've seen people do stuff with haskell that's amazing, though more in the realm of almost mathematical exploration than large, end-user software. (maybe there is some, i just haven't run across it.) rust also looks extremely promising (shame about the slow compile times, though that's getting better)). but i wouldn't feel "duped". those are much more ambitious languages than go; they're in a different space. go is simple, easy to learn, small... (a lot what's nice about go is beyond the language too -- the whole ecosystem is just very pleasant to work with.)
dnautics 9y ago
Go's type system is indeed atrocious, but I'd say that the only major problem. For a high-uptime server, I'd probably prefer to go a BEAM-based sanguage, and for numerical computation and data analysis, I would prefer using Julia (especially if it were more well adopted) but as "a replacement for C" it's quite nice (still need C for things like cross-platform libraries, NIFs, anything kernel).
- weberc2 9y ago
  I don't mind Go's type system. It's a pain for some things, but I haven't found a better one. The languages that have sum types and generics are too restrictive to be practical in virtually all of the software I write (Rust, Haskell) or they lack a decent ecosystem (ReasonML, OCaml, typed-racket). I would welcome a language with a better, practical type system. Bonus points if it shares Go's runtime.
  - ernst_klim 9y ago
    Ocaml’s ecosystem feels much better than Go’s. At least Ocaml has such a great package manager, better compiler, repland an allocation profiler. The only thing it lacks is multicore runtime.
    - weberc2 9y ago
      I disagree. Here are a few things about OCaml's ecosystem that are strictly worse than Go's, and which I find to be particularly frustrating: 1. Documentation. It's lacking or spread thinly across the Internet, and it's mostly low quality in my experience. 2. Windows support was dodgy last I checked. 3. Build tooling is byzantine and fragmented 4. Standard libraries - The official standard library is limited and frustrating - Other standard libraries are limited and frustrating - There is more than one standard library 5. Devs seem more interested in adding language features than making it useful to people who want to write real applications > At least Ocaml has such a great package manager As long as I'm consuming packages, it's great. Making packages is a nuisance. Go's dependency and distribution tooling isn't pretty, but at least it gets out of my way--`dep` does what I need it to do and I haven't had any problems. Still, both Go and OCaml's package management story is a far cry from Rust's Cargo. > better compiler What does this mean? Certainly not "faster" or "produces faster code" or "works better across platforms". > repl Granted, but I program in Python professionally and rarely touch the repl. I use it more often as a command line calculator than anything. If I were doing data science, I might feel differently, but for application development I don't miss it. > allocation profiler Go has had an (excellent) allocation profiler built into the toolchain for years. Besides, it's much easier to intuit about (and control) allocations in Go than it is in OCaml. If I could borrow anything into Go from OCaml, it would be generics and sum types. The rest (syntax, runtime, tooling, libraries, etc) I'll leave be.

by adwhit 9y ago

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 ago
I 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 ago
  This 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 ago
    You 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 ago
      My point was to show that GOPATH is easy; not the fastest path to hello world. :)

chickenfries 9y ago

To be fair, Go never promised you the future. The documentation and community is pretty oblique about their values.

dilap 9y ago

i've played around a bit and with haskell and ocaml, very interesting languages. i've seen people do stuff with haskell that's amazing, though more in the realm of almost mathematical exploration than large, end-user software. (maybe there is some, i just haven't run across it.) rust also looks extremely promising (shame about the slow compile times, though that's getting better)). but i wouldn't feel "duped". those are much more ambitious languages than go; they're in a different space. go is simple, easy to learn, small... (a lot what's nice about go is beyond the language too -- the whole ecosystem is just very pleasant to work with.)

dnautics 9y ago

Go's type system is indeed atrocious, but I'd say that the only major problem. For a high-uptime server, I'd probably prefer to go a BEAM-based sanguage, and for numerical computation and data analysis, I would prefer using Julia (especially if it were more well adopted) but as "a replacement for C" it's quite nice (still need C for things like cross-platform libraries, NIFs, anything kernel).

weberc2 9y ago
I don't mind Go's type system. It's a pain for some things, but I haven't found a better one. The languages that have sum types and generics are too restrictive to be practical in virtually all of the software I write (Rust, Haskell) or they lack a decent ecosystem (ReasonML, OCaml, typed-racket). I would welcome a language with a better, practical type system. Bonus points if it shares Go's runtime.
- ernst_klim 9y ago
  Ocaml’s ecosystem feels much better than Go’s. At least Ocaml has such a great package manager, better compiler, repland an allocation profiler. The only thing it lacks is multicore runtime.
  - weberc2 9y ago
    I disagree. Here are a few things about OCaml's ecosystem that are strictly worse than Go's, and which I find to be particularly frustrating: 1. Documentation. It's lacking or spread thinly across the Internet, and it's mostly low quality in my experience. 2. Windows support was dodgy last I checked. 3. Build tooling is byzantine and fragmented 4. Standard libraries - The official standard library is limited and frustrating - Other standard libraries are limited and frustrating - There is more than one standard library 5. Devs seem more interested in adding language features than making it useful to people who want to write real applications > At least Ocaml has such a great package manager As long as I'm consuming packages, it's great. Making packages is a nuisance. Go's dependency and distribution tooling isn't pretty, but at least it gets out of my way--`dep` does what I need it to do and I haven't had any problems. Still, both Go and OCaml's package management story is a far cry from Rust's Cargo. > better compiler What does this mean? Certainly not "faster" or "produces faster code" or "works better across platforms". > repl Granted, but I program in Python professionally and rarely touch the repl. I use it more often as a command line calculator than anything. If I were doing data science, I might feel differently, but for application development I don't miss it. > allocation profiler Go has had an (excellent) allocation profiler built into the toolchain for years. Besides, it's much easier to intuit about (and control) allocations in Go than it is in OCaml. If I could borrow anything into Go from OCaml, it would be generics and sum types. The rest (syntax, runtime, tooling, libraries, etc) I'll leave be.