Go
From APIDesign
(→Hard for Coding) |
(→Hard for Coding) |
||
| Line 50: | Line 50: | ||
One of the original [[Go]] mottos was to [[wikipedia::Go_(programming_language)#History|not require integrated development environments]]. Obviously one can code with '''vi''' or '''sed''', but at cost of complete loss of productivity. Thus I doubt the IDE-less vision materialized. Definitely not more than for [[C]]. | One of the original [[Go]] mottos was to [[wikipedia::Go_(programming_language)#History|not require integrated development environments]]. Obviously one can code with '''vi''' or '''sed''', but at cost of complete loss of productivity. Thus I doubt the IDE-less vision materialized. Definitely not more than for [[C]]. | ||
| - | Coding, editing, compiling, fixing errors, debugging when writing [[Go]] code feels to me like editing [[Java]] twenty years ago (at that time [[I]] was writing the 1st [[IDE]] for [[Java]] - [[Xelfi]] which later became [[NetBeans]] - obviously there was no [[IDE]] for [[Java]] at that time). Do your edits in '''notepad''' or etc., go to command line, compile, read the errors, locate them in the editor, try to fix them (without any hint about the [[Go]] [[API]]s), repeat until the [[Go]] compiler is happy and you get your executable. Run to get a failure. Try to seek for a debugger. No, it is not '''gdb''', search more. Give up, and resort to '''printf''' logging. Honestly, it is a disaster | + | Coding, editing, compiling, fixing errors, debugging when writing [[Go]] code feels to me like editing [[Java]] twenty years ago (at that time [[I]] was writing the 1st [[IDE]] for [[Java]] - [[Xelfi]] which later became [[NetBeans]] - obviously there was no [[IDE]] for [[Java]] at that time). Do your edits in '''notepad''' or etc., go to command line, compile, read the errors, locate them in the editor, try to fix them (without any hint about the [[Go]] [[API]]s), repeat until the [[Go]] compiler is happy and you get your executable. Run to get a failure. Try to seek for a debugger. No, it is not '''gdb''', search more. Give up, and resort to '''printf''' logging. Honestly, it is a disaster to usability for everyone spoiled by enormous competition between [[IDE]]s for [[Java]] in the last twenty years. But maybe the whole story shouldn't be that dark. Maybe there are people productive with [[Go]] - especially if you want to hire the few most expensive experts that code [[Go]] for living... |
There is an [[IDE]] that supports [[Go]], but even its basic editing isn't for free. There is a [[LSP]] server, but your mileage may vary. Looks like [[Go]] is years behind any language adopted by the industry. | There is an [[IDE]] that supports [[Go]], but even its basic editing isn't for free. There is a [[LSP]] server, but your mileage may vary. Looks like [[Go]] is years behind any language adopted by the industry. | ||
Revision as of 06:10, 27 September 2018
Go is a programming language developed by Google. When it was introduced in 2009, it was promoted as:
- statically typed
- compiled language in the tradition of C
- with memory safety
- and garbage collection
- and structural typing
- and CSP-style concurrency
After the usual initial hype it managed to keep some of its coolness. Primarily because of the rise of docker (as most of the docker ecosystem is written in Go).
Contents |
Forget Go!
The above is probably all you need to know about Go. Because the goal of this post isn't to promote Go, the post is written to explain that you don't need Go at all. That there are better, faster, more approachable, more toolable alternative languages. If you are a happy Go user, stick to it, but if you are considering to use Go for development of a new system, then the main take away should be: Forget Go!, there is a better way.
Let's start by enumerating what are the problems with the Go language.
Slow
Go is slow. The same algorithm written in Go runs at least twice as slow than the same algorithm written in Java or C. I maintain a project to measure Turing Speed of various programming languages on a variant of Ancient and well known Sieve of Eratosthenes algorithm. What follows are result of https://github.com/jtulach/sieve revision a671eb115 compiled with go1.9.2 on Ubuntu 16.04:
sieve/go$ ./go | grep Hundred Hundred thousand prime numbers in 253 ms Hundred thousand prime numbers in 263 ms Hundred thousand prime numbers in 261 ms Hundred thousand prime numbers in 270 ms Hundred thousand prime numbers in 250 ms Hundred thousand prime numbers in 277 ms Hundred thousand prime numbers in 241 ms
now change the directory to C version and try the same:
sieve/c$ sieve | grep Hundred Hundred thousand prime numbers in 100 ms Hundred thousand prime numbers in 101 ms Hundred thousand prime numbers in 98 ms Hundred thousand prime numbers in 102 ms Hundred thousand prime numbers in 101 ms Hundred thousand prime numbers in 108 ms Hundred thousand prime numbers in 97 ms
Can anybody explain to me what is so interesting on a language 2.5x times slower than C!?
Hard for Coding
One of the original Go mottos was to not require integrated development environments. Obviously one can code with vi or sed, but at cost of complete loss of productivity. Thus I doubt the IDE-less vision materialized. Definitely not more than for C.
Coding, editing, compiling, fixing errors, debugging when writing Go code feels to me like editing Java twenty years ago (at that time I was writing the 1st IDE for Java - Xelfi which later became NetBeans - obviously there was no IDE for Java at that time). Do your edits in notepad or etc., go to command line, compile, read the errors, locate them in the editor, try to fix them (without any hint about the Go APIs), repeat until the Go compiler is happy and you get your executable. Run to get a failure. Try to seek for a debugger. No, it is not gdb, search more. Give up, and resort to printf logging. Honestly, it is a disaster to usability for everyone spoiled by enormous competition between IDEs for Java in the last twenty years. But maybe the whole story shouldn't be that dark. Maybe there are people productive with Go - especially if you want to hire the few most expensive experts that code Go for living...
There is an IDE that supports Go, but even its basic editing isn't for free. There is a LSP server, but your mileage may vary. Looks like Go is years behind any language adopted by the industry.
Proprietary
Go is proprietary. The whole stack is written from scratch and not based only anything the industry shares. It is not based on LLVM stack. It is not build around GCC infrastructure. It is written by Google from top to bottom.
This has a negative effect on features, as well as speed. The team paid for Go support isn't infinite, and thus it cannot address all the incoming requests immediately. Yet it needs to reinvent everything (including a wheel) again due to uniqueness of the overall Go language/compiler implementation. As a result Go lacks in many features behind languages well adopted by the industry.
This is not to say everything in bad in Go. If you are working in an ecosystem that is build with Go (e.g. you are coding against Docker APIs or your are a Google employee), it may still be beneficial to use Go. But otherwise, let's consider Java!
Go, Java go!
Java!? That slow, interpreted language which eats enormous amount of memory to execute its virtual machine and feels like an operating system on its own? That Java which every real OS level hacker hates? Yes, that one. Well, not exactly that Java, but rather a SubstrateVM - an ahead of time compiler. Let's enumerate what Java is:
- statically typed
- compiled language + (together with SubstrateVM) in the tradition of C
- with memory safety
- and garbage collection
- and object oriented typing
- with multi-threading concepts built into the language since day one
Does that sound familiar? Yes, the Java language has the same benefits as attributed to Go. Moreover (in combination with SubstrateVM) one also gets similar runtime behavior. SubstrateVM gives Java (and any other JVM language) following:
- instant startup
- no interpretter/dynamic compilation overhead
- low memory consumption
If you have a pre-occupations against Java forget them. We'll use the best of Java (or any other JVM language like Kotlin) and combine them with SubstrateVM to form an ecosystem which is clearly better than anything Go can provide.
Java is Fast
Running the same Sieve of Eratosthenes algorithm with standard Java 1.8 gives you:
sieve$ mvn -f java/algorithm/ package exec:java | grep Hundred Hundred thousand primes computed in 100 ms Hundred thousand primes computed in 108 ms Hundred thousand primes computed in 93 ms Hundred thousand primes computed in 90 ms Hundred thousand primes computed in 84 ms Hundred thousand primes computed in 87 ms Hundred thousand primes computed in 85 ms Hundred thousand primes computed in 84 ms Hundred thousand primes computed in 84 ms Hundred thousand primes computed in 84 ms Hundred thousand primes computed in 86 ms
with SubstrateVM it is slightly slower, but still way faster than Go:
...TBD...
Follow
