3 ms·

There are a lot of bad things in Go, sure. And some are really annoying, like "goroutine all the things" mantra. But no matter how I dislike it there is just n

by zzzcpan 12y ago

There are a lot of bad things in Go, sure. And some are really annoying, like "goroutine all the things" mantra. But no matter how I dislike it there is just no other choice today. It all comes down to support, bug fixing, ease to learn and to use, good standard library, built in cross-compilation and a pretty fast one, static binaries, good enough dependency management, reasonable performance and memory usage, especially in comparison to python/perl/ruby, integrated unit testing, code formatting tool, etc. All these things together matter more, than the language itself.

grogers 12y ago
Except for "static binaries" (which isn't clear what benefits you desire out of them), java has all those things. The other choices are certainly there.
- Alphasite_ 12y ago
  And even Java is getting that.
  - zzzcpan 12y ago
    Too late. Also Java is not as easy to learn and to use as Golang.
    - waps 12y ago
      Too bad you can't unlearn functional programming. Or generic programming. Or algebraic datatypes. Or having actual useful datatypes. Or ... Just the basic thing of sorting a list containing a struct. And the suggested solution by the Go team is a 50 line program. WTF. They actually claim the err = function(); if err != nil {}. This is the reason I originally left C. And those criticisms really apply to Go as well. Firstly nobody sanely checks those errors, often outright ignoring them. Second when they do, they always just pass the error up (in other words: manually implementing exceptions), or worse, they panic on the error (meaning you cannot trust external libraries won't panic on you, negating the single advantage that leaving out exceptions had). Even if you do check those errors they interrupt the train of thought you have. Imagine someone telling you how to open a door in Go : first, put your hand on the handle. If you don't have a hand then go to the hospital. If there is no hospital near you then go to the car. If there is no car then check for a bike. If the door is locked ... wait what was I doing ? Thirdly functions that might return a variable or might not ... the official Go team's advice is use a pointer. Sigh. The amount of times I've seen people commit Go code into my program that doesn't check for nil-ness ... Grrrr. If you don't mind living in the dark ages, then yes, Go is great.
- NateDad 12y ago
  Except for "reasonable memory usage".
MichaelGG 12y ago
F# has that. With Mono you can produce static binaries. And the F# compiler can also make statically linked assemblies, including the bits it needs from all its dependencies. Although I'm not sure if there is an F# code formatter tool. Which is made up for by F# being a vastly more capable language.
- kolektiv 12y ago
  Yes, some code formatting tools exist (within Visual Studio as part of F# Power Tools, and also I believe standalone in some binary form). However, as a community we're currently a little less dogmatic than Go (for example) about what "correct" formatting is. Tabs vs. Spaces is decided at the language level (it's spaces or it doesn't work) but other things are often a matter of taste. It doesn't tend to matter too much though because (well written) F# code is expressive almost regardless of minor formatting issues (poorly written code in any language is a comprehensibility mess, regardless of "neatness" or newline consistency!)

by zzzcpan 12y ago

grogers 12y ago

Except for "static binaries" (which isn't clear what benefits you desire out of them), java has all those things. The other choices are certainly there.

Alphasite_ 12y ago
And even Java is getting that.
- zzzcpan 12y ago
  Too late. Also Java is not as easy to learn and to use as Golang.
  - waps 12y ago
    Too bad you can't unlearn functional programming. Or generic programming. Or algebraic datatypes. Or having actual useful datatypes. Or ... Just the basic thing of sorting a list containing a struct. And the suggested solution by the Go team is a 50 line program. WTF. They actually claim the err = function(); if err != nil {}. This is the reason I originally left C. And those criticisms really apply to Go as well. Firstly nobody sanely checks those errors, often outright ignoring them. Second when they do, they always just pass the error up (in other words: manually implementing exceptions), or worse, they panic on the error (meaning you cannot trust external libraries won't panic on you, negating the single advantage that leaving out exceptions had). Even if you do check those errors they interrupt the train of thought you have. Imagine someone telling you how to open a door in Go : first, put your hand on the handle. If you don't have a hand then go to the hospital. If there is no hospital near you then go to the car. If there is no car then check for a bike. If the door is locked ... wait what was I doing ? Thirdly functions that might return a variable or might not ... the official Go team's advice is use a pointer. Sigh. The amount of times I've seen people commit Go code into my program that doesn't check for nil-ness ... Grrrr. If you don't mind living in the dark ages, then yes, Go is great.
NateDad 12y ago
Except for "reasonable memory usage".

MichaelGG 12y ago

F# has that. With Mono you can produce static binaries. And the F# compiler can also make statically linked assemblies, including the bits it needs from all its dependencies. Although I'm not sure if there is an F# code formatter tool. Which is made up for by F# being a vastly more capable language.

kolektiv 12y ago
Yes, some code formatting tools exist (within Visual Studio as part of F# Power Tools, and also I believe standalone in some binary form). However, as a community we're currently a little less dogmatic than Go (for example) about what "correct" formatting is. Tabs vs. Spaces is decided at the language level (it's spaces or it doesn't work) but other things are often a matter of taste. It doesn't tend to matter too much though because (well written) F# code is expressive almost regardless of minor formatting issues (poorly written code in any language is a comprehensibility mess, regardless of "neatness" or newline consistency!)