4 ms·

I've been writing in Go at work nearly every day for the past year. I think that of the problems both Go and Rust attempt to solve, Rust solves them better in a

I've been writing in Go at work nearly every day for the past year. I think that of the problems both Go and Rust attempt to solve, Rust solves them better in a technical and academic sense. As someone who prefers C and C++ over Python and Java, I personally would rather use Rust, but I have to say that Go strikes a great balance for general-purpose use. It is as fast to develop and as flexible and extendable as Python. Similar performance to Java but with much less code, better interoperability, and a more robust standard library. More features than C without the needless complexity of C++. Entirely too opinionated and the build system and dependency management are 80% solutions / hacks, but for the most part you can work around them. Most importantly, I think Go can be easily picked up and used by C, C++, Java, PHP, JavaScript, Python, C#, Objective-C, XYZ, ETC programmers alike with very little learning curve (some more than others perhaps). I think with Rust, you are going to have a hard time training someone who has depended on GC for so long that they have to be explicit about the ownership and transfer of ownership of memory and that it's elegant and cool and performant to do so. You are going to have trouble explaining traits and composability and the syntax around it to someone who is used to using more verbose syntax to implement complicated inheritance trees. Pattern matching and enums are fantastic, but also foreign to most of the programming public. This is why Go is spreading - good middle ground for productivity and performance, easy to pick up, seemingly bright future, Google backing, good documentation (no doc is perfect - Sphinx is frequently not great, Javadoc is terrible, Doxygen is meh, MSDN is overgrown with cruft - but Godoc is decent), etc.

voltagex_ 11y ago
Is there a good (say, produced by JetBrains) IDE for Go yet? Edit: http://plugins.jetbrains.com/plugin/?idea&id=5047 http://plugins.jetbrains.com/plugin/?idea&id=5047
- look_lookatme 11y ago
  It's worth noting that a number of JetBrains employees seem to be working on this plugin every day [1]. I suspect we'll see a proper JetBrain Go IDE before too long. [1] https://github.com/go-lang-plugin-org/go-lang-idea-plugin/commits/master https://github.com/go-lang-plugin-org/go-lang-idea-plugin/co...
- cyri 11y ago
  I'll work with the latest commits from https://github.com/go-lang-plugin-org/go-lang-idea-plugin/commits/master https://github.com/go-lang-plugin-org/go-lang-idea-plugin/co... every day (fresh compiled) and it is getting better and better! Those guys are doing an awesome job. There is not yet a need for a Go-specific IDE by JetBrain.
  - frik 11y ago
    Does it support Go 1.4? In Jan/February it was still only compatible with previous Go versions - the stable release.
    - cyri 11y ago
      I only work with Go 1.4 :-) I was aware that the plugin didn't support for a long time the new Go structure. But with the overall refactoring it works now perfect.
- YZF 11y ago
  I use Eclipse with the Goclipse plug-in. I still have the command prompt on the side for some stuff but the plug-in covers a fair bit of what you need to get done... http://goclipse.github.io/ http://goclipse.github.io/
- robmccoll 11y ago
  Asking the wrong person for that one - I just use Vim ;-) I do use a few of the Go scripts (https://github.com/robmccoll/dotfiles https://github.com/robmccoll/dotfiles). There are some really nice ones (continuous build, syntax checking, continuous testing, etc), but most of what I work on has longer build times due to linking in a good bit of C.
pron 11y ago
> Similar performance to Java but with much less code, better interoperability, and a more robust standard library. I disagree on all points. 1. The similar performance to Java is usually in small benchmarks. Once the program grows, the difference in quality of the GC and code generation starts to show (in favor of Java, of course). 2. Less code? I've seen Go programs in the wild that are indeed shorter than their Java counterparts, but that's almost invariably because the Go code is less "careful" (less attention to error handling, logging, monitoring, maintainability etc.) But when you compare programs that actually do the same thing, I find that the code size is similar, with Go winning fewer characters and Java 8 fewer lines. 3. Interoperability is, IMO, much better in Java, where you can interoperate with both C as well as JVM languages (including JVM ports of Python, Ruby and R); for Go it's just C. 4. As to the standard library -- especially when it comes to concurrent data structures -- there are few if any languages out there with implementations of as high a quality as Java, and the difference between the variety and quality of available third-party libraries is beyond comparison. All in all, I find Go and Java to be quite similar, and the choice between them boils down to the runtime. I reach for Go when I need small command-line programs where JVM warmup is unacceptable and static linking to a native executable is a plus, and Java for long-running, "important" server apps, where top performance and deep monitoring (and sometimes hot code swapping) are necessary.
- fauigerzigerk 11y ago
  I agree that Go and Java are very similar indeed. Without goroutines, Go would be little more than a rewind of Java to a moment before J2EE happened. A major motivation for both languages was to take dangerous weapons out of the hands of mediocre programmers (or programmers made mediocre by being forced into large and ever changing teams). But I have to disagree on performance. What kills Java performance is memory consumption and the way memory is laid out. It has always been the number one killer. It killed Applets. It killed Java on the desktop. And it makes Java a bad choice for most server side infrastructure. I predict that Go is going to wipe out Java for that latter kind of task within 5 years if not less. Memory consumption is what constrains performance for most tasks. That's why most benchmarks are entirely irrelevant. Java's creators made two huge mistakes: 1) Throwing out structured value types, which is the root cause for Java's insatiable appetite for memory. 20 years of garbage collection research were unable to compensate for the damage done by not having structured value types. 2) Throwing out so many (supposedly too complex and too dangerous) meta programming features that everything meta had to be built around the language. Trading complexity at the language level for a much more unsound form of complexity on the runtime and tooling side is what caused the J2EE disaster. Go's creators avoided the first mistake but they are busy repeating the second one with even greater determination.

voltagex_ 11y ago

Is there a good (say, produced by JetBrains) IDE for Go yet? Edit: http://plugins.jetbrains.com/plugin/?idea&id=5047 http://plugins.jetbrains.com/plugin/?idea&id=5047

look_lookatme 11y ago
It's worth noting that a number of JetBrains employees seem to be working on this plugin every day [1]. I suspect we'll see a proper JetBrain Go IDE before too long. [1] https://github.com/go-lang-plugin-org/go-lang-idea-plugin/commits/master https://github.com/go-lang-plugin-org/go-lang-idea-plugin/co...
cyri 11y ago
I'll work with the latest commits from https://github.com/go-lang-plugin-org/go-lang-idea-plugin/commits/master https://github.com/go-lang-plugin-org/go-lang-idea-plugin/co... every day (fresh compiled) and it is getting better and better! Those guys are doing an awesome job. There is not yet a need for a Go-specific IDE by JetBrain.
- frik 11y ago
  Does it support Go 1.4? In Jan/February it was still only compatible with previous Go versions - the stable release.
  - cyri 11y ago
    I only work with Go 1.4 :-) I was aware that the plugin didn't support for a long time the new Go structure. But with the overall refactoring it works now perfect.
YZF 11y ago
I use Eclipse with the Goclipse plug-in. I still have the command prompt on the side for some stuff but the plug-in covers a fair bit of what you need to get done... http://goclipse.github.io/ http://goclipse.github.io/
robmccoll 11y ago
Asking the wrong person for that one - I just use Vim ;-) I do use a few of the Go scripts (https://github.com/robmccoll/dotfiles https://github.com/robmccoll/dotfiles). There are some really nice ones (continuous build, syntax checking, continuous testing, etc), but most of what I work on has longer build times due to linking in a good bit of C.

pron 11y ago

> Similar performance to Java but with much less code, better interoperability, and a more robust standard library. I disagree on all points. 1. The similar performance to Java is usually in small benchmarks. Once the program grows, the difference in quality of the GC and code generation starts to show (in favor of Java, of course). 2. Less code? I've seen Go programs in the wild that are indeed shorter than their Java counterparts, but that's almost invariably because the Go code is less "careful" (less attention to error handling, logging, monitoring, maintainability etc.) But when you compare programs that actually do the same thing, I find that the code size is similar, with Go winning fewer characters and Java 8 fewer lines. 3. Interoperability is, IMO, much better in Java, where you can interoperate with both C as well as JVM languages (including JVM ports of Python, Ruby and R); for Go it's just C. 4. As to the standard library -- especially when it comes to concurrent data structures -- there are few if any languages out there with implementations of as high a quality as Java, and the difference between the variety and quality of available third-party libraries is beyond comparison. All in all, I find Go and Java to be quite similar, and the choice between them boils down to the runtime. I reach for Go when I need small command-line programs where JVM warmup is unacceptable and static linking to a native executable is a plus, and Java for long-running, "important" server apps, where top performance and deep monitoring (and sometimes hot code swapping) are necessary.

fauigerzigerk 11y ago
I agree that Go and Java are very similar indeed. Without goroutines, Go would be little more than a rewind of Java to a moment before J2EE happened. A major motivation for both languages was to take dangerous weapons out of the hands of mediocre programmers (or programmers made mediocre by being forced into large and ever changing teams). But I have to disagree on performance. What kills Java performance is memory consumption and the way memory is laid out. It has always been the number one killer. It killed Applets. It killed Java on the desktop. And it makes Java a bad choice for most server side infrastructure. I predict that Go is going to wipe out Java for that latter kind of task within 5 years if not less. Memory consumption is what constrains performance for most tasks. That's why most benchmarks are entirely irrelevant. Java's creators made two huge mistakes: 1) Throwing out structured value types, which is the root cause for Java's insatiable appetite for memory. 20 years of garbage collection research were unable to compensate for the damage done by not having structured value types. 2) Throwing out so many (supposedly too complex and too dangerous) meta programming features that everything meta had to be built around the language. Trading complexity at the language level for a much more unsound form of complexity on the runtime and tooling side is what caused the J2EE disaster. Go's creators avoided the first mistake but they are busy repeating the second one with even greater determination.