/go-is-not-good forked from ksimka/go-is-not-good

A curated list of articles complaining that go (golang) isn't good enough
  1. Go 96.5%
  2. Makefile 3.5%
Branch: updates
Find file
Clone or download

Clone with HTTPS

Use Git or checkout with SVN using the web URL.

Open in Desktop Download ZIP

Launching GitHub Desktop...

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop...

If nothing happens, download GitHub Desktop and try again.

Launching Xcode...

If nothing happens, download Xcode and try again.

Launching Visual Studio...

If nothing happens, download the GitHub extension for Visual Studio and try again.

Pull request Compare This branch is 38 commits ahead of ksimka:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
FOOTER.md
HEADER.md
Makefile
README.md
entries.json
generator.go

README.md

What's this

This repository is a list of articles that complain about golang's imperfection.

Motivation

Seems like complaining about go's flaws is becoming a trend. Any newbie must have a chance to read all the go-is-bad arguments before they go too far. So here it is.

What it's for

This repo is not aimed to offend or insult someone (at least not more than each author does it in its article), especially golang itself, its authors and the community. It is for educational purpose only. Any contributor can have an absolutely different point of view.

I don't think anyone would deny that go has weaknesses: it certainly has. But how do you know, is it really a language design flaw or is it just you, doing something completely wrong? This list here to help you quickly answer the question.

How to use it

You're writing some code. And suddenly you understand you need something that language can't give you. You go here and check if you're the one with that issue or not. If it's a common issue, it'll be here. Then you decide what to do: choose another tool for your task or go find a better solution or a workaround.

See also

How to complain about Go

The List

  • http://www.lessonsoffailure.com/software/googles-go-not-getting-us-anywhere-part-2/ (Dave Rodenbaugh, 2009)
    • slower than C++
    • CSP implementation is only partial
    • standard library is limited
    • no GUI support in standard library
    • no database support in standard library
    • statically linked
    • no exceptions
    • syntax is too different from C, C++, and Java
  • https://cowlark.com/2009-11-15-go/ (David Given, 2009)
    • c-style
    • poor design
    • no constructors
    • new and make instead of one
    • stuck in '70s
    • no OOP
    • types go after identifiers, not before
    • return types after function name, not before
    • no while loops
    • can't range over user-defined types
    • constants can only be numbers or strings
    • pointers are a mess
    • can't name nested functions
    • single-pass compiler
    • designers did not consult the literature
    • too simple / lack of syntactic sugar
  • http://www.lessonsoffailure.com/software/google-go-good-for-nothing/ (Dave Rodenbaugh, 2009)
    • slower than C++
    • memory footprint is worse than C++
    • syntax is too different from C, C++, and Java
  • https://dzone.com/articles/i-don%E2%80%99t-much-get-go (Jon Davis, 2010)
    • no language interoperability (only C)
    • no versioning model
    • no OOP
    • no GUI support
    • new and make instead of one
    • internationalization is limited to Unicode support
    • has pointers
    • no semicolons at line endings
    • no this
    • no function/operator overloading
    • not real-world oriented
    • defer lets you be lazy
    • ignores C#
    • no exceptions
  • http://ridiculousfish.com/blog/posts/go_bloviations.html (ridiculousfish, 2012)
    • c-style
    • unused imports are compile errors
    • unused variables are compile errors
    • bad Unicode support
    • types go after identifiers, not before
    • return types after function name, not before
    • no ternary operator
    • too verbose
    • semicolons are injected by the lexer
    • hard to pass function pointers to C
    • no incremental or parallel compilation
    • closures capture variables by reference, not by value
    • no assertions
  • https://uberpython.wordpress.com/2012/09/23/why-im-not-leaving-python-for-go/ (Yuval Greenfield, 2012)
    • error handling is mandatory
    • stuck in '70s
    • no exceptions
  • http://www.darkcoding.net/software/go-lang-after-four-months/ (Graham King, 2012)
    • un-Googlable name
    • stuck in '70s
    • no exceptions
    • is compiled
    • no read-eval-print loop
    • fork() is either wrong or impossible
    • string manipulation is a library package
    • too young
  • http://how-bazaar.blogspot.ru/2013/04/the-go-language-my-thoughts.html (Tim Penhey, 2013)
    • error handling is mandatory
    • no exceptions
    • inconvenient range
    • can't range over user-defined types
    • tab width too wide
    • gofmt's style is no one's favourite
    • no generics
  • http://corte.si/posts/code/go/go-rant.html (Aldo Cortesi, 2013)
    • too opinionated
    • unused imports are compile errors
    • unused variables are compile errors
  • https://blog.carlmjohnson.net/post/google-go-the-good-the-bad-and-the-meh/ (Carl Johnson, 2013)
    • too simple / lack of syntactic sugar
    • no generics
    • string manipulation is a library package
    • too young
    • error handling is not mandatory
    • compiler warnings are errors
    • no function/operator overloading
    • no keyword arguments
    • no shebang lines
  • http://magicmakerman.blogspot.ru/2013/07/why-googles-go-programming-language.html (Magic Maker Man, 2013)
    • no OOP
    • no assertions
    • has pointers
    • solves nobody's problem
    • no inheritance
    • no function/operator overloading
    • designers did not consult the literature
    • weird mascot (gopher)
  • https://rule1.quora.com/Golang-Not-yet (Jordan Zimmerman, 2014)
    • no decent IDE
    • GOPATH is a mess
    • pointers are a mess
    • case-defined scoping is bad
    • hidden types
    • immature GC
    • hard to extend
    • no exceptions
    • no generics
    • channels are overrated
    • duck typing of local variables
    • dependency management sucks
  • http://www.yinwang.org/blog-cn/2014/04/18/golang (Wang Yin, 2014)
    • confusing/stupid syntax
    • immature toolchain
    • immature GC
    • no generics
    • multiple return values have no type checking
    • cumbersome interface
    • goroutines are not original
    • defer is abused
    • stuck in Unix thinking
    • types go after identifiers, not before
    • no decent IDE
    • dependency management sucks
    • unwieldy to code new collections
    • designers did not consult the literature
    • error handling is mandatory
    • summary: not elegant as Python, not strong as Java
  • http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/ (Keith Wesolowski, 2014)
    • the worst compiler toolchain ever
    • Rob Pike and other core developers are arrogant
    • stuck in '70s
    • Fisher-Price assembly language
    • stuck in Plan9 thinking
    • technical hubris
    • assembler uses Unicode mid-dot character
    • confusing and undebuggable
  • http://yager.io/programming/go.html (Will Yager, 2014)
    • no generics
    • no function/operator overloading
    • nil as a failure marker
    • type inference is too simple
    • no immutables
    • not a good language
    • unwieldy to code new collections
    • can't range over user-defined types
    • no ternary operator
    • dynamic memory allocation
    • garbage collector requires implicit (hidden) trade-offs
    • not real-time oriented
    • no unsafe code isolation
    • stuck in '70s
    • no pattern matching
  • https://www.upguard.com/blog/our-experience-with-golang (Mark Sheahan, 2014)
    • no decent IDE
    • error handling is mandatory
    • unexpected variable shadowing
    • no generics
    • no map/reduce/filter
    • no immutables
    • not-so-obvious slices behaviour
  • http://oneofmanyworlds.blogspot.co.uk/2014/01/another-go-at-go-failed.html (Srinivas Jonnalagadda, 2014)
    • no built-in set type
    • no built-in BitSet/BitArray type
    • maps are slow
    • slower than Java
    • Rob Pike and other core developers are arrogant
    • no generics
  • http://spaces-vs-tabs.com/4-weeks-of-golang-the-good-the-bad-and-the-ugly/ (Freddy Rangel, 2015)
    • not-so-obvious slices behaviour
    • error handling is mandatory
    • hard to test, hard to mock
  • https://bravenewgeek.com/go-is-unapologetically-flawed-heres-why-we-use-it/ (Tyler Treat, 2015)
    • no generics
    • interfaces are not contracts
    • no function/operator overloading
    • no exceptions
    • can't range over user-defined types
    • sending to a closed channel panics
    • channels are not as efficient as plain mutexes
    • defer is slow
    • interface indirection is expensive
    • can't peek into channels
    • can't receive multiple values from channels
    • goroutines make it easy to leak things
    • dependency management sucks
    • immature toolchain
    • Rob Pike and other core developers are arrogant
    • can't add methods to types from other packages
  • http://blog.goodstuff.im/golang (David Pollak, 2015)
    • no immutables
    • no ternary operator
    • inconvenient range
    • := is weird
    • no exceptions
    • unused imports are compile errors
    • unused variables are compile errors
    • no read-eval-print loop
    • too simple / lack of syntactic sugar
    • confusing/stupid syntax
    • too opinionated
    • error handling is mandatory
    • error handling is not mandatory
    • designers did not consult the literature
    • stuck in '70s
    • no generics
    • case-defined scoping is bad
    • no map/reduce/filter
  • http://tmikov.blogspot.com/2015/02/you-dont-like-googles-go-because-you.html (Tzvetan Mikov, 2015)
    • designed for stupid people
    • too verbose
    • no ternary operator
    • no macros or templates
    • can't change hash function in maps
    • unwieldy to code new collections
    • inconvenient range
    • no function/operator overloading
    • can't declare/validate implements interface
    • no virtual functions
    • case-defined scoping is bad
  • https://thenewstack.io/switching-to-go-and-learning-what-features-its-missing-along-the-way/ (Matthew Campbell, 2015)
    • regex engine is slow
    • no generics
    • serialization is inefficient
    • is garbage-collected
    • no good integration test suite
    • no dynamic linking / plugins
    • no decent XML parser
  • http://www.evanmiller.org/four-days-of-go.html (Evan Miller, 2015)
    • unused imports are compile errors
    • too opinionated
    • poor std math lib
    • := is weird
    • no while loops
    • 'rune' is a weird name
    • is garbage-collected
    • unused variables are compile errors
    • pseudointellectual arrogance of Rob Pike and everything he stands for
    • weird mascot (gopher)
  • http://byrd.im/go-is-poor/ (Ian Byrd, 2015)
    • not-so-obvious slices behaviour
    • nil interfaces are not entirely nil
    • unexpected variable shadowing
    • interfaces are not first-class values
    • questionable compiler rigidity
    • go generate is a quirk
  • https://kaushalsubedi.com/blog/2015/11/10/golang-sucks-heres-why/ (Kaushal Subedi, 2015)
    • no generics
    • slow json parsing
    • dependency management sucks
    • too verbose
    • GOPATH is a mess
    • no subpackages
  • http://valuedrivenit.blogspot.ru/2015/12/to-go-language-is-mess.html (Cliff Berg, 2015)
    • un-Googlable name
    • confusing/stupid syntax
    • polymorphism is broken
    • compilation rules are too confining
    • designed for stupid people
    • can't declare/validate implements interface
    • dependency management sucks
  • https://www.teamten.com/lawrence/writings/why-i-dont-like-go.html (Lawrence Kesteloot, 2016)
    • case-defined scoping is bad
    • interfaces are not first-class values
    • no exceptions
    • difficult to generate code automatically
    • no ternary operator
    • sort.Interface approach is clumsy
    • no versioning model
    • import-based vendoring is terrible
    • no generics
  • http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-feel-bad/ (JT Olds, 2016)
    • channels are slow
    • channels are an anti-pattern
    • channels are not as efficient as plain mutexes
    • channel buffers are a fixed size
    • sending to a closed channel panics
    • sending to a nil channel does not panic
    • channel API is inconsistent
  • https://memo.barrucadu.co.uk/three-months-of-go.html (Michael Walker, 2016)
    • dependency management sucks
    • no generics
    • no sum types
    • no separation of pure code from effectful code
    • godoc doesn't support even basic formatting
    • godoc doesn't use source code ordering
    • profiler doesn't graph allocations over time
    • profiler doesn't track threads or garbage collection
    • zero values are a bad idea
    • too verbose
    • error handling is mandatory
    • weak typing
  • https://medium.com/@rgausnet/3-reasons-why-go-isnt-the-perfect-language-yet-25e0da5ec04c (Ryan Gaus, 2016)
    • not stable
    • no map/reduce/filter
    • no OOP
    • dependency management sucks
  • http://dtrace.org/blogs/ahl/2016/08/02/i-love-go-i-hate-go/ (Adam Leventhal, 2016)
    • stuck in Plan9 thinking
    • no assertions
    • un-Googlable name
    • tracebacks limited to 100 stack frames
    • confusing and undebuggable
    • no frame pointers
    • too opinionated
  • https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e#.62yek82xg (Mike Hearn, 2016)
    • misleading marketing around garbage collector
    • garbage collector is nothing new; concurrent mark/sweep from the '70s
    • garbage collector requires implicit (hidden) trade-offs
    • stuck in '70s
    • garbage collector optimized for pause times at the cost of other desirable GC features
  • https://faiface.github.io/post/context-should-go-away-go2/ (Michal Štrba, 2017)
    • context spreads like a virus
    • context is an inefficient linked list
    • context is not an elegant solution to the cancellation problem
    • ctx.Value is a map of meaningless objects to meaningless objects
  • http://sitr.us/2017/02/21/changes-i-would-make-to-go.html (Jesse Hallett, 2017)
    • no non-nullable types
    • error handling is mandatory
    • error handling is not mandatory
    • no generics
    • no sum types
    • zero values are a bad idea
    • too verbose
    • no macros or templates
    • tuples are not first-class values
    • no map/reduce/filter
    • can't range over user-defined types
    • can't make user-defined types
    • unwieldy to code new collections
    • designers did not consult the literature
    • concurrency and parallelism are mixed
  • https://maryvilledevcenter.com/golang-thinks-you-are-a-bad-programmer/ (Dane Johnson, 2017)
    • too opinionated
    • error handling is mandatory
    • pointers are a mess
  • https://awalterschulze.github.io/blog/post/sum-types-over-multiple-returns/ (Walter Schulze, 2017)
    • no sum types
    • no algebraic data types
    • tuples are not first-class values
    • can't pass multiple return values to a function
    • multiple return parameters are overrated
  • https://bugfender.com/blog/go-pros-cons-using-go-programming-language/ (Aleix Ventayol, 2017)
    • shortage of experienced developers
    • import-based vendoring is terrible
    • compiler warnings are errors
    • circular dependencies are errors
    • unwieldy to code new collections
    • no generics
    • too young
    • debugging support is poor
    • profiling support is poor
    • public library packages are half-baked or abandoned
    • dependency management sucks
  • https://zapier.com/engineering/go-no-go/ (Jordan Sherer, 2017)
    • unwieldy to code new collections
    • dependency management sucks
    • no inheritance
    • no classes
    • no generics
    • no exceptions
  • https://grimoire.ca/dev/go (Owen Jacobson, 2018)
    • hostile to developer ergonomics
    • too opinionated
    • dependency management sucks
    • GOPATH is a mess
    • Rob Pike and other core developers are arrogant
    • no sum types
    • too verbose
    • error handling is mandatory
  • https://bluxte.net/musings/2018/04/10/go-good-bad-ugly/ (Sylvain Wallez, 2018)
    • no generics
    • sort.Interface approach is clumsy
    • designers did not consult the literature
    • Fisher-Price assembly language
    • no functional programming
    • is garbage-collected
    • interfaces are not contracts
    • can't declare/validate implements interface
    • no enums
    • unexpected variable shadowing
    • zero values are a bad idea
    • error handling is mandatory
    • writing to a zero map panics
    • dependency management sucks
    • GOPATH is a mess
    • not-so-obvious slices behaviour
    • no immutables
    • race conditions are possible
    • io.EOF is an error
    • not Rust
    • interface values that hold nil concrete values are non-nil
    • struct field tags are free-form strings
    • no constructors
    • unwieldy to code new collections
    • can't range over user-defined types
    • no macros or templates
    • go generate is a quirk
    • no exceptions

Reverse complaints index

It's a reverse complaints index, generated by https://github.com/ksimka/go-is-not-good/blob/master/generator.go (thanks to @capoferro)

Get involved

Feel free to add a PR with a new or old article you found on the internet. The structure is simple, just look at existing entries. Run make and check in the resulting README.md along with your updated entries.json.

{
	"URL": "https://kaushalsubedi.com/blog/2015/11/10/golang-sucks-heres-why/",
	"Author": "Kaushal Subedi",
	"Year":  2015,
	"Complaints":[
		"no generics",
		"slow json parsing",
		"bad dependency management",
		"no subpackages"
	]
}

TODO

  • merge complaints with the same ideas under the same names (make the complaints list smaller)
  • sort reverse index by the number of articles which have that complain (popular complains to the top)