Lack of dlls is a feature in my mind. I've seen the 9th level of dependency
hell in .Net. It's not a place I ever want to go back too.
Here are a few deficiencies:
- Go is not low level enough to convince c programmers to use it.
- It doesn't give you enough control to convince c++ programmers (or in
the future rust developers)
- It's not dynamic or meta enough to convince ruby programmers
- Go doesn't play well with a functional approach to programming (map,
filter, reduce, ...)
- Not that other solutions are great, but Go doesn't have a standard
package management system (like maven, bundler, npm, ...)
- Go seems to straddle the fence between languages where the computer
does exactly what you tell it to (like c, c++, ...) and languages where you
describe your solution and the computer figures out how to implement it
(like haskell). For example goroutines and channels are a very high level
abstraction, but structural types are lower level. This seems to work well,
but ideologically speaking, given my aversion to magic and my fear of
abstraction, I wonder what sorts of problems you will run into when trying
to build a robust, high performance application which pushes your system to
This sucks in Java, but its a kind of suckage that people have
- Though strongly opinionated in some ways, Go is very conservative in
others. Go can feel like you're throwing out the last 10 years of work done
in other languages, or rather like you're jumping into a conversation with
someone you've not seen in 20 years. The language throws out more than it
adds. (though I personally think this is better: generic programming is
often way too complex, exceptions were probably a bad idea anyway, getting
rid of null pointers, STM in haskell and all the crazy memory stuff in rust
are often a whole lot harder to use than just living with the older model)
- Go is currently a fad. In a year or two something else will take over.
Will companies still care about Go after that? Will skills in the language
still be useful? As a developer things like Java are still a safer bet.
- Poor 3rd party library support. Both in terms of there's not
necessarily a lot of libraries, and in terms of the reliability of what is
out there. For example there's like 40 forks of the AWS library, all of
them incomplete in various ways.
- Poor IDE and 3rd party tool support. I agree with the comment about
poor debugging. I've been spoiled by intellij.
- Go isn't the most inter-operable language. You can't use it in your
browser and you can't use it on your phone. (and given the move to cloud
and mobile that's a whole lot of the development space)
On Saturday, March 29, 2014 4:48:45 PM UTC-6, Patrick Bennett wrote:
Off the top of my head, some of my nits so far would be:
* The lack of any kind of a thread-local storage equivalent that provides
a context for a given stack frame so I can provide better logging
functions. Without it, I'm forced to create a 'context' struct that has to
be passed around *everywhere* so that I can provide 'scoped' enter/exit
tracing - which also means everything I use has to then alter its interface
so it can take this context. For a lot of code, TLS is seldom needed, but
when it is... it really stinks to have to work around it.
* The terrible state of debugging support - gdb is lacking and many of
Go's features aren't supported within it [you can't pause all but the
current goroutine for example).
* Lack of dynamically loaded modules. This isn't a big problem for me
'yet,' but it drastically changes how Go can be supported for commercial
software. If you have a bug in a common library used by 800 other modules,
with DLLs you can just hotfix that one file. If everything is statically
linked, you have to ship out new versions of all 800 modules. For most
applications people seem to be developing with Go this seems to be a
complete non-issue but for it to really compete against C++, being forced
to always statically link everything is a liability IMO.
* Inability to force arbitrary RAII resource 'close' scoping - defer
always goes to the end of the function, not the current scope. You can
introduce an anonymous function and defer within that, but then a return
within the anonymous function returns from it, not from the function it is
contained in - greatly complicating and confusing what should be simple
code just to get around a defer weakness. While I still think it was
hacked in, a C# 'using' like equivalent would be very helpful.
* I 'guess' I could say generics - but honestly it hasn't been an issue
for me so far. I would just hate to see the language go down the path of
so many others and get so much more complex for very real little gain. I
see C++ template code often enough that's just horrendous to even figure
out compilation errors for let alone be able to see what you're really
going to end up with. Very simple support would probably go a long way.
That's one of the things I like about Go. Pretty much what you see is
what you get.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.