10 ms·

Why I’m Frustrated with Go

166 points by WolfOliver 9y ago

andreasgonewild 9y ago
Go contains many good ideas that may be carried over to more pragmatic languages. Using it for anything beyond simple, self-contained command-line tools and network servers never really worked out for me. And that makes sense, since it was explicitly designed to scale over groups of inexperienced developers at any cost; the opposite of my needs. Modern C++ runs circles around Go for more complex software, and it provides the tools to add as much convenience as needed on a case-by-case basis. I recently ported a 7kloc Go codebase to C++ and wrote down some of my impressions here: https://github.com/andreas-gone-wild/blog/blob/master/rewriting_good_idea.md https://github.com/andreas-gone-wild/blog/blob/master/rewrit...
- dvfjsdhgfv 9y ago
  Your blog entry you're referring to contains surprisingly little information to support the arguments mentioned in your posts. Maybe if you provided some specific example of why a given fragment of code works better in C++ rather than Go, we could have some interesting discussion.
  - andreasgonewild 9y ago
    I can't take responsibility for your expectations, differences between languages and their consequences for the code we write is a tricky thing to quantify. I have no proof and I'm not here to argue, only to share my authentic experience in the hope that it helps someone else. Both codebases are clearly linked from the post for comparison. Feel free to ignore my advice if Go is working out for you.
- user5994461 9y ago
  So... Go is excellent to write the software it was designed to write and it's no good at other things.
  - brango 9y ago
    Which is fine if you happen know what it was designed for prior to starting your project, and can also be 100% sure your project will never mutate into anything else...
JamesMcMinn 9y ago
Worth reading the comments where someone points out a much simpler and more elegant solution, although it's still not an ideal situation. As noted in the post, generics could solve this, so I'm looking forward to Go 2 if indeed generics is included. There's a few QOL issues I'd like to see addressed in 2 which would make Go a lot nicer to work with, and I say that as someone who spends most of their time working on Go codebases.
- noir-york 9y ago
  > Worth reading the comments where someone points out a much simpler and more elegant solution, although it's still not an ideal situation. I'm always wary of such "<language X> isn't great because..." posts as I find that the frustration is as much a function of the developer's competence, (lack of) imagination and familiarity with the language and its idioms, as it is with the language itself.
- NateDad 9y ago
  Generics don't solve immutability.
  - JamesMcMinn 9y ago
    No, Generics make it possible to create a generic immutable data structure which can be used instead of re-writing the same boilerplate for every data type, which is the authors complaint.
    - xfer 9y ago
      You are still talking about immutable data structures, which has nothing to do with generics.
      - JamesMcMinn 9y ago
        No, YOU are still talking about immutable data structures, where as I am talking about the need to write boilerplate code in Go due to lack of Generics. The blog posts topic was not "immutable data structures", rather the need for boilerplate code in Go because of the lack of generics. The particular example was one of immutable data structures, however that was an example rather than the topic. The author themselves notes that "generics would solve all of the issues above".
forgottenacc57 9y ago
What is the perfect language?
- josteink 9y ago
  Let's just say it can't have a type-system limited to not understanding generics.
doublerebel 9y ago
So, once upon a time I wanted to associate information with http connections (as I am accustomed to in every other language I've ever written) just to enable proper http keepalive and debugging through a proxy written in Go. Ended up with this. [0] Turns out the Go authors don't think you should do this so I had to majorly alter and recompile the stdlib. I still appreciate many go tools and the cross platform single binaries that work great on Solaris/Illumos. But in many cases the strong opinions of Go authors really stand in the way of getting work done. [0]: https://github.com/doublerebel/publictransport https://github.com/doublerebel/publictransport
- dvirsky 9y ago
  These days you have http requests with context (I think starting from Go 1.8), see https://golang.org/pkg/net/http/#Request.Context https://golang.org/pkg/net/http/#Request.Context
- lobster_johnson 9y ago
  That's more a criticism of the standard HTTP server, which is a bit of a black box, apparently intentionally. There's nothing wrong with writing your own server to make up for it's limitations.
  - meesterdude 9y ago
    except for the fact that you shouldn't have to write your own server?
    - pebers 9y ago
      Why not? Plenty of languages don't come with one built in at all, or not one widely used in production (e.g. Python's http.server, there are a heap of other Python web servers out there).
      - codegladiator 9y ago
        They count 24 lines of code as "infuriating amount of code to write". Why do you think they would interested in writing a web server ?
dvfjsdhgfv 9y ago
I personally tend to choose Go for newer projects as I'm looking for the efficiency of C and safety/elegance of more "modern" languages. However, I always keep an eye on D and Nim. It seems these are the only two languages that can compete with Go in both above aspects.
- Ar-Curunir 9y ago
  Go is not in the league of C for efficiency though? Very different kinds of languages...
  - _ph_ 9y ago
    In my day to day work, I find Go very much in the league of efficiency of C, if, for robust and real programs, not beyond. Low level Go code compiles the same as C code does (yes, C compilers have better optimizers), you have sometimes to pay for some overhead (bounds checks, GC), but that often pales compared doing this by hand in C, when you need a reliable and robust application.
- nhumrich 9y ago
  Go is nowhere near the speed of C. But why not consider Rust?
  - dvfjsdhgfv 9y ago
    The Rust team decided to promote Rust as a "systems programming" language. And even though it can obviously do much more, and the bindings for most popular libraries are available [1], this label somehow attracts programmers who are more systems oriented and I think the language will continue to develop in this way, whereas Go/D/Nim will tend to try to be more general. [1] Imagine how surprised I was the other day to find Rust bindings to Allegro, a venerable game programming library from the old days of DOS and DJGPP...
    - lobster_johnson 9y ago
      Rust is getting to be popular for graphics and games, precisely because it has the performance of, and easy interoperability with, C, without GC, and in a much more modern environment. Low memory requirements means portability to memory-constrained platforms. Interoperability with C presumably also implies easier access to low-level resources such as GPUs, and being able to take advantage of existing libraries for C, such as SDL. People are also experimenting with Go in the same space, but it seems much less promising. Go is notoriously slow at calling C (or being called from C) due to goroutine context save/restore. It also has GC and a runtime.
thinbeige 9y ago
OT: I recently learned that the newer ETH client Parity is written in Rust and much faster than the older Go-based Geth ETH client. Guess it is due to a different architecture and design which makes the client faster (e.g. chaindata is smaller) but does anyone know why they chose Rust instead of Go for the Parity client?
- dvirsky 9y ago
  I don't know specifically why that is for this specific project, but in general Go has GC and bounds checking that slow things down.
  - masklinn 9y ago
    Rust bounds-checks indexes by default (there exist indexing methods which bypass that, they are unsafe).
    - dvirsky 9y ago
      Another thing I can think of - Go's interface mechanism overhead is usually significant, and I've also found that the networking stack is slow compared to raw C. When I brought this up on the user group a few years ago I was told that this is a fair price to pay for Go's safety and concurrency abstractions. I pretty much agree actually. I won't be necessarily writing a database in Go, but for robust and fast application services it's very very good.
      - kasey_junk 9y ago
        The channel primitives are also slow and it is really painful to write fast alternatives as you have to resort to code gen.
        dvirsky 9y ago
        yes, and they are heavily used under the hood in the standard library, for things like http connection pooling.
latch 9y ago
I did Go for years, but stopped doing any serious work in it about a year ago. In general, I found it a chore to maintain Go-based systems. There's a lot to like about Go. But it doesn't seem pragmatic for the types of applications I see people using it for. For example, the entire error thing is absurd. Anders Hejlsberg got this right many years ago: 9 out of 10 errors are "handled" by a central error handler (log + "sorry, try again"). You can do this with error values, but at best it's verbose. Maybe error values makes sense for system programming, I could certainly believe it makes more sense. But, really, the main problem is the type system. I'm a huge fan of dynamic languages. I think they're so much more productive. This is especially true when your system is interacting with external data - like user input and a database. I did C# and Java for years. These interactions are, at best, painful with static languages. But they're downright infuriating in Go (poor reflection, no generics). I wrote a somewhat popular library to help deal with map[string]interface{} nonsense (2), but it's not enough. When it comes to web/tcp stuff, I think OpenResty for any middleware-ish system and Elixir for everything else are far more productive and enjoyable ecosystems. We've been doing Elixir for about a year now, and I've never seen such a consensus on productivity and quality (everything else always had some issue: Ruby is slow, Node is single threaded, Java is verbose). There's certainly more space than just that. Go might still be a good choice for CLI tools, and both OpenResty and Elixir have a distinct memory/threading model that precludes some use cases - but those are in the minority. (1) - Nothing against Erlang model, but I do think it's more restrictive. (2) - https://github.com/karlseguin/typed https://github.com/karlseguin/typed
- 43224gg252 9y ago
  >I found it a chore to maintain Go-based systems My opinion is the opposite. Almost every go code base I've seen is extremely consistent compared to other languages. Going from one code base to another is almost always seamless because learning Go involves learning the Go tools which forces you to follow Go coding standards. I'd choose to work on a Go code base over Java or C++ any day of the week. I don't have much experience with elixir, but that's because I like to stay employed. >the entire error thing is absurd. Anders Hejlsberg got this right many years ago: 9 out of 10 errors are "handled" by a central error handler This is almost always unacceptable in production, especially when it comes to mission critical hard/software. You need to be able to handle errors in production that you may not even be able to catch in testing and that means you need to catch all the errors and think critically about what should be done when that error is encountered. "Central error checkers" are almost never robust enough for mission critical systems. Go basically forces people to write high-quality, resilient code bases, and I like it for that.
humanrebar 9y ago
> You know how much code I’d have to write if this were C++, C#, or Java? None. They all have reusable notions of an immutable, ordered map. Actually C++ doesn't have immutable data unless you count compile-time constants and literals. You can declare things 'const', but that only provides a read-only (1) view on mutable data. Also, to provide good 'const' support in containers, you usually have to provide extra read-only iterators that are largely identical to the writeable iterators. Go look at the C++ standard library. All the containers have both 'iterator' and 'const_iterator' (not just a 'const iterator'). Another approach is to just declare member variables 'const'. So you have a 'const map<int, int>' as a member variable. Except for that to work, you need to construct that member variable in the initializer list. The body of the constructor is too late. This likely means taking an already-initialized map as a constructor argument and copying it (probably exposing implementation details in the process) or writing a helper that returns the appropriate map type and copying it. Good optimizers will elide many or all of these copies, but relying on quality of optimizers isn't portable. Anyway, I'd say the complexity of the Go approach isn't significantly worse that the C++ alternatives, if it's worse at all. (1) Of course, with casting shenanigans or use of the 'mutable' keyword, anyone can circumvent 'const' without a lot of work.
- user5994461 9y ago
  And java doesn't have them either. You need to use an external library, likely the google containers library.
  - Sharlin 9y ago
    Java does have unmodifiable wrappers but they implement the same basic mutable Map/List/etc. interfaces, just throwing at runtime if mutating methods are called. Not exactly optimal but better than nothing.
    - fauigerzigerk 9y ago
      Better than nothing but worse than the C++ solution of returning a const reference which can be checked at compile time. Both are just immutable views on top of mutable containers. But in both C++ and Java it is trivial to create a truly immutable container of T. Not so in Go.
43224gg252 9y ago
In any production grade application where order and persistence is truly important you need to supply a time stamp anyway and at that point you'd want to just store your animals in a database. This is pretty trivial imo. If you just want a very temporary ordered list you could probably use a channel.
jbg_ 9y ago
The link to the immutable, ordered map that "Java provides" seems to be a link to a third-party library created by Google. If that's enough for you to consider that a language provides a feature, just wrap the immutable ordered map implementation in your blog post in a library, publish it, and now Go provides that functionality too.
- rvense 9y ago
  Is it possible to write a reusable version of something like this in Go without using interface{}?
  - masklinn 9y ago
    If "static codegen" is considered OK, then I guess yes, and I guess you can use The Thing[0] to even make them look like actual generics. Every user of the library will need to run codegen to post-process their source files and generate the relevant instantiations of the "generic" collection. [0] https://www.reddit.com/r/rust/comments/5penft/parallelizing_enjarify_in_go_and_rust/dcsq64p/?context=42 https://www.reddit.com/r/rust/comments/5penft/parallelizing_...
    - nine_k 9y ago
      Then I could take almost any reasonable language, and transpile it to Go source. This worked for years for Javascript 5, and for C before that, and for Fortran even before that. In either case, the reason was that the target language was considered not expressive enough, though ubiquitous.
    - TheCoelacanth 9y ago
      So you can do it in Go in the same sense that you can do it in assembly language.
      - masklinn 9y ago
        Exactly.
deleted 9y ago
[deleted]
alkonaut 9y ago
Having to encapsulate data to ensure read only semantics seems like par for the course from an OO perspective. In C# (which is 15ish years old at least) I don't think there has been an immutable map until very recently. Also (and this is probably a code style thing) I can't remember having reached for an immutable ordered map in a long career.
- eterm 9y ago
  ReadOnlyDictionary has been around for 5 years, and even before that you could implement this with generics in a way that is re-usable everywhere rather than having to constantly 're-write the wheel' as in Go as the author laments.
  - alkonaut 9y ago
    Yeah lack of generics with the argument of "simplicity" is a special kind of crazy. I was thinking of the ImmutableDictionary that's more recent. Normally in C#/Java you should rarely expose collection types directly so you almost always encapsulate the list/dictionary and provide e.g GetReservation(string id) to the outside, which makes it less common to even need the readonly types at all. Immutable ones are a whole different thing since they enable proper sharing of whole collections.
- kasey_junk 9y ago
  > I can't remember having reached for an immutable ordered map in a long career. Me neither. But I have reached for a fast single producer, multi consumer queue, futures/promises, concurrent safe maps, non-blocking queues, and even plain async queues with batch semantics, many many times. So either the author, me and everyone else that is claiming this is a problem are doing it wrong or its actually a problem.
jmaa 9y ago
Go was explicitly designed to be a simple language, without a rich tapestry of data structures to suit every use case. Languages are like tools. If you need a saw, use a saw, instead of complaining about the knife you are using.
- rebolek 9y ago
  No, languages are like toolboxes, they provide you with set of tools.
  - yupyup 9y ago
    No, languages are like Ogres, they have layers.
  - tscs37 9y ago
    Then you should be using the toolbox for metalwork when trying to weld two steel plates instead of using the one for woodwork.
_ph_ 9y ago
I am not sure where the authors exact requirements fit in the greater picture of the desired application. But one important tool which works great in Go is functional representation. If you want e.g. an immutable map, make it a structure with private fields, and give access vial functions (methods). The first comment to the article describes a nice example of this approach. I often read criticism of Go which is based on a missing "feature". In my experience, implementing these features is surprisingly easy in Go, as the building blocks are all there. In this respect, Go has some resemblance on Lego :). My background contains a lot of Scheme/Lisp, so abstracting things with functions comes natural to me. It turns out that Go has basically the equivalent function concept (first class functions, closures, ..) so enables all the powerful abstractions coming from them.
- kuschku 9y ago
  But you still have to write the function a hundred times — once each for every immutable map you'll use. This is the opposite of DRY.
  - 43224gg252 9y ago
    Go also supports libraries.
    - kuschku 9y ago
      Go doesn’t really support libraries of data structures and containers, though. You can’t build a library of different kinds of immutable and mutable maps, trees, etc that are reusable – precisely because generics are missing.
  - _ph_ 9y ago
    Yes, if you needs lots of different immutable maps as your interface to a library, then the lack of generics is annoying. But the question is, is the immutable map such a common interface, or should your library and abstraction barrier be something else? I am a professional programmer and have prefer abstractions via objects/functions.
- 9y ago
rst 9y ago
The OP suggests "some form of codegen" as a way of getting around the Go dev team's, shall we say ... unusual hostility toward generics. But that way lies C++ templates, which were originally meant to be implemented as macro-generation -- and which lead to the messiness and complexity of C++ builds which were one of their major reasons for doing a new language in the first place.
- VHRanger 9y ago
  Templates don't help C++ build times, but the root problem is that it uses the C model for compilation (several sequential passes). D compiles faster than Go usually and with templated generics all over its std lib
jpz 9y ago
I think you have to work with the language you're in. I had similar frustrations when I first moved into doing some dev in Java and C# and it really bugged me that there was no compile-time guarantee that an Object reference passed as a method parameter would not be modified within that method (as I was so used to using const-refs with in C++) In retrospect however, I was frustrated with these languages because I was wanting it to be something it wasn't. To my mind, the loss of that feature meant that programs were less expressive - particularly in large codebases - I had to read methods to work out if something was being modified or not. To complain here about Go lacking immutability and constness features seems to be the same as complaining that it is missing in Python, Ruby or JavaScript. It's a fact that constness isn't a feature of these languages, if you want these features, use a different language.
- blub 9y ago
  Sometimes it doesn't cost much if anything to add a feature which improves (type) safety. Now that Python has some type annotation support, it could make sense to also add a const annotation. Go should have had it from the beginning IMO, immutability can help avoid some coding mistakes and also makes it easier to reason about code. It'a nice match for a language with static typing.
- fauigerzigerk 9y ago
  I don't see what's wrong with venting frustrations with particular technologies. It helps no one if people just move on silently. It deprives the creators of that technology of the opportunity to react to any complaints and it deprives everyone else of the opportunity to choose a different technology from the start.
oelmekki 9y ago
Out of curiosity, what is the use case for immutable structs? (asking as I'm a ruby/js/go dev and as such I've never used such idiom)
- falcolas 9y ago
  It's a code safety thing. If you create it and the compiler makes it immutable, then you can't screw it up later with an accidental mutation. Basically, something that takes coder discipline in Ruby/JS/Go is handled a compiler/runtime enforced restriction.
  - oelmekki 9y ago
    Oh, I see, thanks. I get now how it can be a problem when you're used to rely on it and it's not in the language.
japano1se 9y ago
Of course the problem he has is that it doesn't follow the hot new immutability fad, and of course he doesn't explain what he needs it for, just links to a stack exchange question which essentially says that it might be useful for some cases. It seems a lot of these articles, and programming language theory in general, is just complaining about features without any thought as to why they matter. What is this "problem" stopping him from doing? Why does it matter? And why should I abandon a language that has served me very well just because some edge-case feature is not supported?
- deleted 9y ago
  [deleted]
- dboreham 9y ago
  Spot on. As a card-carrying dinosaur I've found myself from time to time needing to read up on some "new" (usually turns out to have been invented in the 60's) coding thing. Once I figure out what it is, I ask myself what problem it solves (the literature typically doesn't say). The answer tends to be one of: 1. Saves some typing. 2. Saves some work when refactoring. 3. Avoids some class of bug. 4. Highly useful in a kind of programming I don't do (e.g. compilers). #1-2 in my experience are much more common than #3-4 and often #1-2 can be dealt with through tooling (IDEs for example).
  - japano1se 9y ago
    Absolutely. With respect to this article and immutability, the strongest arguments I've seen for it are for concurrent programming, like the very successful Erlang solutions used at Ericsson, which I generally don't have an interest in. So, it is reason #4 on your list. For the types of program and the types of problem I need to solve, it's a moot point - people have been getting along just fine without immutable state and continue to do so, and to learn how to do it differently would just be more trouble than it's worth, if not an outright regression. This is the major problem I have with this sort of article; people never talk about languages in the context of actual working programs, just engage in dry theorizing or armchair programming. If the author put the complaint from this article into context, I'd not have a problem with it. But because it's a toy example with no relevance to actual programs people might want to write and use, it's unhelpful and misleading.
tonetheman 9y ago
I asked this same question on reddit. And I am not trying to be snarky. I have programmed a long time and I cannot think of a single time where I thought, "this would be easier with generics." Where is the list of problems that are easier to solve with generics?
- andreasgonewild 9y ago
  You don't mention your level of experience with generic type systems, but I find it's mostly the case that I can't imagine any use for techniques I'm not yet familiar with. Here is a random example from my recent adventures, a channel implementation in C++ which uses generics to provide value-semantics for user-specified message types: https://github.com/andreas-gone-wild/snackis/blob/master/src/snackis/core/chan.hpp https://github.com/andreas-gone-wild/snackis/blob/master/src... And here is a column class that uses generics to inject both record type and value type into the implementation: https://github.com/andreas-gone-wild/snackis/blob/master/src/snackis/db/col.hpp https://github.com/andreas-gone-wild/snackis/blob/master/src... Doing any of these without generics would mean either erasing types or writing duplicate code. Go provides generic channels, slices and maps; but it doesn't extend that power to user-code since users are supposedly not smart enough to be trusted with power.
- nine_k 9y ago
  Channels, maps, and arrays are generic in Go. They solve a lot if key problems. The problem is that you can't create your own generic structure. Try building a statically type-safe red-black tree, or something like that, without copy-pastig the implementation for each new node data type. Higher-order functions are also basically impossible.
  - masklinn 9y ago
    > Channels, maps, and arrays are generic in Go. Pointers and slices as well, and of course the various builtin operators or functions used to work on them (make, range, len, close, …).
pebers 9y ago
> You know how much code I’d have to write if this were C++, C#, or Java? None. They all have reusable notions of an immutable, ordered map. Java doesn't do that well at all though; its immutable maps can be used in place of mutable maps, since there's no way of having a Map interface that extends ImmutableMap to add extra operations, so you can get nasty runtime surprises if you've got the wrong one. Conversely, if you want a mutable map keyed on a non-trivial structure, you have to do just as much boilerplate as the author complains about to set up private members, setters, builders, etc. Obviously C++ can do it quite readily, but nobody accused it of lacking features. This is really just another use case for generics, and the discussion there is well-trodden. Go probably isn't the language for you if you value generics more highly than fast compile times, native binaries, etc, but I'm not sure why that still seems to come as a surprise.
- nine_k 9y ago
  Lombok takes care of most of such boilerplate in Java. Code generating tools for Go also exist. The difference is that they produce source code, while things like Lombok, or any reasonable macro system, never surface intermediate code, unless explicitly asked.
  - pebers 9y ago
    That's still solving the problem by working around the language though. And surely it's the job of your build system to automate and hide the codegen process? Admittedly go build & go generate don't do that well, but they aren't the only options out there.
- vbezhenar 9y ago
  Java does it well, you can easily make good immutable map interface. The problem is with Java Collections which is just a poorly designed library, like most other standard Java libraries. I really hope that someone will use JVM with another built from the ground sane library. The only thing Java misses is covariance/contravariance for generics, but with some unsafe casting it'll work.
codegladiator 9y ago
> That’s an infuriating amount of code to write 24 lines, really ?
- WaltPurvis 9y ago
  It was down to 10 after a suggestion in the comments. Given the number of times you might actually need an immutable, ordered map (total count so far in my life = 0), having to write 10 lines of code does seem like an odd reason to be furious with an entire programming language.
marcus_holmes 9y ago
I keep getting drawn back to Go. I left it a while back, with a lot of the same frustrations. But then I tried a bunch of other things, and nothing seemed to work better. There seem to always be some frustrations with whatever language. And I found myself craving that simplicity again. I might get annoyed with it again, and try some other stuff. And that might stick. But I suspect Go is the worst language except for all the others [1]. [1] http://www.goodreads.com/quotes/267224-democracy-is-the-worst-form-of-government-except-for-all http://www.goodreads.com/quotes/267224-democracy-is-the-wors...
- andreasgonewild 9y ago
  I did the back-and-forth for several years with Go. What drew me in was promises and wishes, what made me leave every time was realizing I had fallen for the same stupid trick again. It only looks simple because of the features they skipped and the arbitrary limitations they decided on. Once a codebase reaches a certain level of complexity and the need for more powerful abstractions arises, the perceived simplicity is no more.
RobinsonCrusoe 9y ago
Go is seriously limited language by design. If the limitations are starting to bother a person, they're better off just using a different language.
jondubois 9y ago
It's so interesting how the hype cycle works. Only 1 year ago, people on HN were bashing Node.js hard and saying that you should use Go instead and everyone was praising Go. Now it seems everyone is bashing Go. Moral of the story; never buy into the hype whether it is positive or negative. I think that Go is just fine and so is Node.js. Maybe the author of the article makes a valid point, but no language is perfect and ultimately you have to understand it well in order to use it well.
- gipp 9y ago
  I've been reading HN for a couple years now and can't recall there ever being a consensus positive opinion about Go. All the discussions pretty much looked like this one.
Young_God 9y ago
In addition to what you describe, my other big complaint with Go is the attitude you find from the devs, in threads discussing these types of challenges. "Oh, you think you want an ordered map? No you don't. Your reasons are stupid. You're stupid. Now gtfo and start using Go to write things we deem to be respectable."
- andreasgonewild 9y ago
  Agreed, one of the most dogmatic communities I've had the misfortune of stepping into. But then that's pretty much a requirement given the amount of pretending they need to pull off to keep their bubble intact.
Navigator 9y ago
The sorted map alternative is really only viable for insert-only maps or really small maps. You'd have to remove keys from the list when they're removed from the map. Most sorted map implementations are based on trees.
brango 9y ago
Go's been great for creating a web scraper. But it's been an unmitigated disaster for being able to write the data to a database due to the immaturity of ORMs. Might as well not pretend something is an ORM if it can't do the fundamentals (like upserts), fully hydrating structs, etc.
- doublerebel 9y ago
  Similar to doublerebel/publictransport, I ran into some issues hydrating structs the way I expected from other languages. So I wrote bellows [0], a helper to flatten and expand nested maps and structs. Not quite the same but might help someone. [0]: https://github.com/doublerebel/bellows/blob/master/README.md https://github.com/doublerebel/bellows/blob/master/README.md
trumpownsyou 9y ago
go is for hipsters
Mikhus 9y ago
After a year of programming with Go I have noticed that I, an old C++ programmer, have the reflex to decompose a program in terms of interacting data structures (objects) which encapsulate their behavior. I programmed like that in Go in the beginning. But when I looked at other Go code and especially the std lib code which is easily accessible, I was always amazed at the simplicity of the code. Now I try to write simple programs and this is hard after years of C++ programming. I don't know if there is a term for Go like programming. I'm tempted to call it minimalism. It may be uncomfortable for people coming from classical programming, but the simplicity of the language and the code is a clear win in the long run.
deleted 9y ago
[deleted]
AReallyGoodName 9y ago
I don't know if you are the author of this post or not but try Crystal. It fixes all the things wrong with Go in my opinion.
justin66 9y ago
It's an interesting point of view that regards those four items as necessary requirements for a data structure, and then regards the 24 lines of code needed to implement it as a massive "explosion of code." It would be interesting to know what language is considered the ideal tool for someone who looks at things that way. Something functional?
evolighting 9y ago
Where Google is SO GREAT that everyone could only follow them, never doubt any thing, or it would turn out to be that you are stupid

166 points by WolfOliver 9y ago

Go contains many good ideas that may be carried over to more pragmatic languages. Using it for anything beyond simple, self-contained command-line tools and network servers never really worked out for me. And that makes sense, since it was explicitly designed to scale over groups of inexperienced developers at any cost; the opposite of my needs. Modern C++ runs circles around Go for more complex software, and it provides the tools to add as much convenience as needed on a case-by-case basis. I recently ported a 7kloc Go codebase to C++ and wrote down some of my impressions here: https://github.com/andreas-gone-wild/blog/blob/master/rewriting_good_idea.md https://github.com/andreas-gone-wild/blog/blob/master/rewrit...

dvfjsdhgfv 9y ago
Your blog entry you're referring to contains surprisingly little information to support the arguments mentioned in your posts. Maybe if you provided some specific example of why a given fragment of code works better in C++ rather than Go, we could have some interesting discussion.
- andreasgonewild 9y ago
  I can't take responsibility for your expectations, differences between languages and their consequences for the code we write is a tricky thing to quantify. I have no proof and I'm not here to argue, only to share my authentic experience in the hope that it helps someone else. Both codebases are clearly linked from the post for comparison. Feel free to ignore my advice if Go is working out for you.
user5994461 9y ago
So... Go is excellent to write the software it was designed to write and it's no good at other things.
- brango 9y ago
  Which is fine if you happen know what it was designed for prior to starting your project, and can also be 100% sure your project will never mutate into anything else...

JamesMcMinn 9y ago

Worth reading the comments where someone points out a much simpler and more elegant solution, although it's still not an ideal situation. As noted in the post, generics could solve this, so I'm looking forward to Go 2 if indeed generics is included. There's a few QOL issues I'd like to see addressed in 2 which would make Go a lot nicer to work with, and I say that as someone who spends most of their time working on Go codebases.

noir-york 9y ago
> Worth reading the comments where someone points out a much simpler and more elegant solution, although it's still not an ideal situation. I'm always wary of such "<language X> isn't great because..." posts as I find that the frustration is as much a function of the developer's competence, (lack of) imagination and familiarity with the language and its idioms, as it is with the language itself.
NateDad 9y ago
Generics don't solve immutability.
- JamesMcMinn 9y ago
  No, Generics make it possible to create a generic immutable data structure which can be used instead of re-writing the same boilerplate for every data type, which is the authors complaint.
  - xfer 9y ago
    You are still talking about immutable data structures, which has nothing to do with generics.
    - JamesMcMinn 9y ago
      No, YOU are still talking about immutable data structures, where as I am talking about the need to write boilerplate code in Go due to lack of Generics. The blog posts topic was not "immutable data structures", rather the need for boilerplate code in Go because of the lack of generics. The particular example was one of immutable data structures, however that was an example rather than the topic. The author themselves notes that "generics would solve all of the issues above".

forgottenacc57 9y ago

What is the perfect language?

josteink 9y ago
Let's just say it can't have a type-system limited to not understanding generics.

doublerebel 9y ago

So, once upon a time I wanted to associate information with http connections (as I am accustomed to in every other language I've ever written) just to enable proper http keepalive and debugging through a proxy written in Go. Ended up with this. [0] Turns out the Go authors don't think you should do this so I had to majorly alter and recompile the stdlib. I still appreciate many go tools and the cross platform single binaries that work great on Solaris/Illumos. But in many cases the strong opinions of Go authors really stand in the way of getting work done. [0]: https://github.com/doublerebel/publictransport https://github.com/doublerebel/publictransport

dvirsky 9y ago
These days you have http requests with context (I think starting from Go 1.8), see https://golang.org/pkg/net/http/#Request.Context https://golang.org/pkg/net/http/#Request.Context
lobster_johnson 9y ago
That's more a criticism of the standard HTTP server, which is a bit of a black box, apparently intentionally. There's nothing wrong with writing your own server to make up for it's limitations.
- meesterdude 9y ago
  except for the fact that you shouldn't have to write your own server?
  - pebers 9y ago
    Why not? Plenty of languages don't come with one built in at all, or not one widely used in production (e.g. Python's http.server, there are a heap of other Python web servers out there).
    - codegladiator 9y ago
      They count 24 lines of code as "infuriating amount of code to write". Why do you think they would interested in writing a web server ?

dvfjsdhgfv 9y ago

I personally tend to choose Go for newer projects as I'm looking for the efficiency of C and safety/elegance of more "modern" languages. However, I always keep an eye on D and Nim. It seems these are the only two languages that can compete with Go in both above aspects.

Ar-Curunir 9y ago
Go is not in the league of C for efficiency though? Very different kinds of languages...
- _ph_ 9y ago
  In my day to day work, I find Go very much in the league of efficiency of C, if, for robust and real programs, not beyond. Low level Go code compiles the same as C code does (yes, C compilers have better optimizers), you have sometimes to pay for some overhead (bounds checks, GC), but that often pales compared doing this by hand in C, when you need a reliable and robust application.
nhumrich 9y ago
Go is nowhere near the speed of C. But why not consider Rust?
- dvfjsdhgfv 9y ago
  The Rust team decided to promote Rust as a "systems programming" language. And even though it can obviously do much more, and the bindings for most popular libraries are available [1], this label somehow attracts programmers who are more systems oriented and I think the language will continue to develop in this way, whereas Go/D/Nim will tend to try to be more general. [1] Imagine how surprised I was the other day to find Rust bindings to Allegro, a venerable game programming library from the old days of DOS and DJGPP...
  - lobster_johnson 9y ago
    Rust is getting to be popular for graphics and games, precisely because it has the performance of, and easy interoperability with, C, without GC, and in a much more modern environment. Low memory requirements means portability to memory-constrained platforms. Interoperability with C presumably also implies easier access to low-level resources such as GPUs, and being able to take advantage of existing libraries for C, such as SDL. People are also experimenting with Go in the same space, but it seems much less promising. Go is notoriously slow at calling C (or being called from C) due to goroutine context save/restore. It also has GC and a runtime.

thinbeige 9y ago

OT: I recently learned that the newer ETH client Parity is written in Rust and much faster than the older Go-based Geth ETH client. Guess it is due to a different architecture and design which makes the client faster (e.g. chaindata is smaller) but does anyone know why they chose Rust instead of Go for the Parity client?

dvirsky 9y ago
I don't know specifically why that is for this specific project, but in general Go has GC and bounds checking that slow things down.
- masklinn 9y ago
  Rust bounds-checks indexes by default (there exist indexing methods which bypass that, they are unsafe).
  - dvirsky 9y ago
    Another thing I can think of - Go's interface mechanism overhead is usually significant, and I've also found that the networking stack is slow compared to raw C. When I brought this up on the user group a few years ago I was told that this is a fair price to pay for Go's safety and concurrency abstractions. I pretty much agree actually. I won't be necessarily writing a database in Go, but for robust and fast application services it's very very good.
    - kasey_junk 9y ago
      The channel primitives are also slow and it is really painful to write fast alternatives as you have to resort to code gen.
      - dvirsky 9y ago
        yes, and they are heavily used under the hood in the standard library, for things like http connection pooling.

latch 9y ago

I did Go for years, but stopped doing any serious work in it about a year ago. In general, I found it a chore to maintain Go-based systems. There's a lot to like about Go. But it doesn't seem pragmatic for the types of applications I see people using it for. For example, the entire error thing is absurd. Anders Hejlsberg got this right many years ago: 9 out of 10 errors are "handled" by a central error handler (log + "sorry, try again"). You can do this with error values, but at best it's verbose. Maybe error values makes sense for system programming, I could certainly believe it makes more sense. But, really, the main problem is the type system. I'm a huge fan of dynamic languages. I think they're so much more productive. This is especially true when your system is interacting with external data - like user input and a database. I did C# and Java for years. These interactions are, at best, painful with static languages. But they're downright infuriating in Go (poor reflection, no generics). I wrote a somewhat popular library to help deal with map[string]interface{} nonsense (2), but it's not enough. When it comes to web/tcp stuff, I think OpenResty for any middleware-ish system and Elixir for everything else are far more productive and enjoyable ecosystems. We've been doing Elixir for about a year now, and I've never seen such a consensus on productivity and quality (everything else always had some issue: Ruby is slow, Node is single threaded, Java is verbose). There's certainly more space than just that. Go might still be a good choice for CLI tools, and both OpenResty and Elixir have a distinct memory/threading model that precludes some use cases - but those are in the minority. (1) - Nothing against Erlang model, but I do think it's more restrictive. (2) - https://github.com/karlseguin/typed https://github.com/karlseguin/typed

43224gg252 9y ago
>I found it a chore to maintain Go-based systems My opinion is the opposite. Almost every go code base I've seen is extremely consistent compared to other languages. Going from one code base to another is almost always seamless because learning Go involves learning the Go tools which forces you to follow Go coding standards. I'd choose to work on a Go code base over Java or C++ any day of the week. I don't have much experience with elixir, but that's because I like to stay employed. >the entire error thing is absurd. Anders Hejlsberg got this right many years ago: 9 out of 10 errors are "handled" by a central error handler This is almost always unacceptable in production, especially when it comes to mission critical hard/software. You need to be able to handle errors in production that you may not even be able to catch in testing and that means you need to catch all the errors and think critically about what should be done when that error is encountered. "Central error checkers" are almost never robust enough for mission critical systems. Go basically forces people to write high-quality, resilient code bases, and I like it for that.

humanrebar 9y ago

> You know how much code I’d have to write if this were C++, C#, or Java? None. They all have reusable notions of an immutable, ordered map. Actually C++ doesn't have immutable data unless you count compile-time constants and literals. You can declare things 'const', but that only provides a read-only (1) view on mutable data. Also, to provide good 'const' support in containers, you usually have to provide extra read-only iterators that are largely identical to the writeable iterators. Go look at the C++ standard library. All the containers have both 'iterator' and 'const_iterator' (not just a 'const iterator'). Another approach is to just declare member variables 'const'. So you have a 'const map<int, int>' as a member variable. Except for that to work, you need to construct that member variable in the initializer list. The body of the constructor is too late. This likely means taking an already-initialized map as a constructor argument and copying it (probably exposing implementation details in the process) or writing a helper that returns the appropriate map type and copying it. Good optimizers will elide many or all of these copies, but relying on quality of optimizers isn't portable. Anyway, I'd say the complexity of the Go approach isn't significantly worse that the C++ alternatives, if it's worse at all. (1) Of course, with casting shenanigans or use of the 'mutable' keyword, anyone can circumvent 'const' without a lot of work.

user5994461 9y ago
And java doesn't have them either. You need to use an external library, likely the google containers library.
- Sharlin 9y ago
  Java does have unmodifiable wrappers but they implement the same basic mutable Map/List/etc. interfaces, just throwing at runtime if mutating methods are called. Not exactly optimal but better than nothing.
  - fauigerzigerk 9y ago
    Better than nothing but worse than the C++ solution of returning a const reference which can be checked at compile time. Both are just immutable views on top of mutable containers. But in both C++ and Java it is trivial to create a truly immutable container of T. Not so in Go.

43224gg252 9y ago

In any production grade application where order and persistence is truly important you need to supply a time stamp anyway and at that point you'd want to just store your animals in a database. This is pretty trivial imo. If you just want a very temporary ordered list you could probably use a channel.

jbg_ 9y ago

The link to the immutable, ordered map that "Java provides" seems to be a link to a third-party library created by Google. If that's enough for you to consider that a language provides a feature, just wrap the immutable ordered map implementation in your blog post in a library, publish it, and now Go provides that functionality too.

rvense 9y ago
Is it possible to write a reusable version of something like this in Go without using interface{}?
- masklinn 9y ago
  If "static codegen" is considered OK, then I guess yes, and I guess you can use The Thing[0] to even make them look like actual generics. Every user of the library will need to run codegen to post-process their source files and generate the relevant instantiations of the "generic" collection. [0] https://www.reddit.com/r/rust/comments/5penft/parallelizing_enjarify_in_go_and_rust/dcsq64p/?context=42 https://www.reddit.com/r/rust/comments/5penft/parallelizing_...
  - nine_k 9y ago
    Then I could take almost any reasonable language, and transpile it to Go source. This worked for years for Javascript 5, and for C before that, and for Fortran even before that. In either case, the reason was that the target language was considered not expressive enough, though ubiquitous.
  - TheCoelacanth 9y ago
    So you can do it in Go in the same sense that you can do it in assembly language.
    - masklinn 9y ago
      Exactly.

deleted 9y ago

[deleted]

alkonaut 9y ago

Having to encapsulate data to ensure read only semantics seems like par for the course from an OO perspective. In C# (which is 15ish years old at least) I don't think there has been an immutable map until very recently. Also (and this is probably a code style thing) I can't remember having reached for an immutable ordered map in a long career.

eterm 9y ago
ReadOnlyDictionary has been around for 5 years, and even before that you could implement this with generics in a way that is re-usable everywhere rather than having to constantly 're-write the wheel' as in Go as the author laments.
- alkonaut 9y ago
  Yeah lack of generics with the argument of "simplicity" is a special kind of crazy. I was thinking of the ImmutableDictionary that's more recent. Normally in C#/Java you should rarely expose collection types directly so you almost always encapsulate the list/dictionary and provide e.g GetReservation(string id) to the outside, which makes it less common to even need the readonly types at all. Immutable ones are a whole different thing since they enable proper sharing of whole collections.
kasey_junk 9y ago
> I can't remember having reached for an immutable ordered map in a long career. Me neither. But I have reached for a fast single producer, multi consumer queue, futures/promises, concurrent safe maps, non-blocking queues, and even plain async queues with batch semantics, many many times. So either the author, me and everyone else that is claiming this is a problem are doing it wrong or its actually a problem.

jmaa 9y ago

Go was explicitly designed to be a simple language, without a rich tapestry of data structures to suit every use case. Languages are like tools. If you need a saw, use a saw, instead of complaining about the knife you are using.

rebolek 9y ago
No, languages are like toolboxes, they provide you with set of tools.
- yupyup 9y ago
  No, languages are like Ogres, they have layers.
- tscs37 9y ago
  Then you should be using the toolbox for metalwork when trying to weld two steel plates instead of using the one for woodwork.

_ph_ 9y ago

I am not sure where the authors exact requirements fit in the greater picture of the desired application. But one important tool which works great in Go is functional representation. If you want e.g. an immutable map, make it a structure with private fields, and give access vial functions (methods). The first comment to the article describes a nice example of this approach. I often read criticism of Go which is based on a missing "feature". In my experience, implementing these features is surprisingly easy in Go, as the building blocks are all there. In this respect, Go has some resemblance on Lego :). My background contains a lot of Scheme/Lisp, so abstracting things with functions comes natural to me. It turns out that Go has basically the equivalent function concept (first class functions, closures, ..) so enables all the powerful abstractions coming from them.

kuschku 9y ago
But you still have to write the function a hundred times — once each for every immutable map you'll use. This is the opposite of DRY.
- 43224gg252 9y ago
  Go also supports libraries.
  - kuschku 9y ago
    Go doesn’t really support libraries of data structures and containers, though. You can’t build a library of different kinds of immutable and mutable maps, trees, etc that are reusable – precisely because generics are missing.
- _ph_ 9y ago
  Yes, if you needs lots of different immutable maps as your interface to a library, then the lack of generics is annoying. But the question is, is the immutable map such a common interface, or should your library and abstraction barrier be something else? I am a professional programmer and have prefer abstractions via objects/functions.
9y ago

rst 9y ago

The OP suggests "some form of codegen" as a way of getting around the Go dev team's, shall we say ... unusual hostility toward generics. But that way lies C++ templates, which were originally meant to be implemented as macro-generation -- and which lead to the messiness and complexity of C++ builds which were one of their major reasons for doing a new language in the first place.

VHRanger 9y ago
Templates don't help C++ build times, but the root problem is that it uses the C model for compilation (several sequential passes). D compiles faster than Go usually and with templated generics all over its std lib

jpz 9y ago

I think you have to work with the language you're in. I had similar frustrations when I first moved into doing some dev in Java and C# and it really bugged me that there was no compile-time guarantee that an Object reference passed as a method parameter would not be modified within that method (as I was so used to using const-refs with in C++) In retrospect however, I was frustrated with these languages because I was wanting it to be something it wasn't. To my mind, the loss of that feature meant that programs were less expressive - particularly in large codebases - I had to read methods to work out if something was being modified or not. To complain here about Go lacking immutability and constness features seems to be the same as complaining that it is missing in Python, Ruby or JavaScript. It's a fact that constness isn't a feature of these languages, if you want these features, use a different language.

blub 9y ago
Sometimes it doesn't cost much if anything to add a feature which improves (type) safety. Now that Python has some type annotation support, it could make sense to also add a const annotation. Go should have had it from the beginning IMO, immutability can help avoid some coding mistakes and also makes it easier to reason about code. It'a nice match for a language with static typing.
fauigerzigerk 9y ago
I don't see what's wrong with venting frustrations with particular technologies. It helps no one if people just move on silently. It deprives the creators of that technology of the opportunity to react to any complaints and it deprives everyone else of the opportunity to choose a different technology from the start.

oelmekki 9y ago

Out of curiosity, what is the use case for immutable structs? (asking as I'm a ruby/js/go dev and as such I've never used such idiom)

falcolas 9y ago
It's a code safety thing. If you create it and the compiler makes it immutable, then you can't screw it up later with an accidental mutation. Basically, something that takes coder discipline in Ruby/JS/Go is handled a compiler/runtime enforced restriction.
- oelmekki 9y ago
  Oh, I see, thanks. I get now how it can be a problem when you're used to rely on it and it's not in the language.

japano1se 9y ago

Of course the problem he has is that it doesn't follow the hot new immutability fad, and of course he doesn't explain what he needs it for, just links to a stack exchange question which essentially says that it might be useful for some cases. It seems a lot of these articles, and programming language theory in general, is just complaining about features without any thought as to why they matter. What is this "problem" stopping him from doing? Why does it matter? And why should I abandon a language that has served me very well just because some edge-case feature is not supported?

deleted 9y ago
[deleted]
dboreham 9y ago
Spot on. As a card-carrying dinosaur I've found myself from time to time needing to read up on some "new" (usually turns out to have been invented in the 60's) coding thing. Once I figure out what it is, I ask myself what problem it solves (the literature typically doesn't say). The answer tends to be one of: 1. Saves some typing. 2. Saves some work when refactoring. 3. Avoids some class of bug. 4. Highly useful in a kind of programming I don't do (e.g. compilers). #1-2 in my experience are much more common than #3-4 and often #1-2 can be dealt with through tooling (IDEs for example).
- japano1se 9y ago
  Absolutely. With respect to this article and immutability, the strongest arguments I've seen for it are for concurrent programming, like the very successful Erlang solutions used at Ericsson, which I generally don't have an interest in. So, it is reason #4 on your list. For the types of program and the types of problem I need to solve, it's a moot point - people have been getting along just fine without immutable state and continue to do so, and to learn how to do it differently would just be more trouble than it's worth, if not an outright regression. This is the major problem I have with this sort of article; people never talk about languages in the context of actual working programs, just engage in dry theorizing or armchair programming. If the author put the complaint from this article into context, I'd not have a problem with it. But because it's a toy example with no relevance to actual programs people might want to write and use, it's unhelpful and misleading.

tonetheman 9y ago

I asked this same question on reddit. And I am not trying to be snarky. I have programmed a long time and I cannot think of a single time where I thought, "this would be easier with generics." Where is the list of problems that are easier to solve with generics?

andreasgonewild 9y ago
You don't mention your level of experience with generic type systems, but I find it's mostly the case that I can't imagine any use for techniques I'm not yet familiar with. Here is a random example from my recent adventures, a channel implementation in C++ which uses generics to provide value-semantics for user-specified message types: https://github.com/andreas-gone-wild/snackis/blob/master/src/snackis/core/chan.hpp https://github.com/andreas-gone-wild/snackis/blob/master/src... And here is a column class that uses generics to inject both record type and value type into the implementation: https://github.com/andreas-gone-wild/snackis/blob/master/src/snackis/db/col.hpp https://github.com/andreas-gone-wild/snackis/blob/master/src... Doing any of these without generics would mean either erasing types or writing duplicate code. Go provides generic channels, slices and maps; but it doesn't extend that power to user-code since users are supposedly not smart enough to be trusted with power.
nine_k 9y ago
Channels, maps, and arrays are generic in Go. They solve a lot if key problems. The problem is that you can't create your own generic structure. Try building a statically type-safe red-black tree, or something like that, without copy-pastig the implementation for each new node data type. Higher-order functions are also basically impossible.
- masklinn 9y ago
  > Channels, maps, and arrays are generic in Go. Pointers and slices as well, and of course the various builtin operators or functions used to work on them (make, range, len, close, …).

pebers 9y ago

> You know how much code I’d have to write if this were C++, C#, or Java? None. They all have reusable notions of an immutable, ordered map. Java doesn't do that well at all though; its immutable maps can be used in place of mutable maps, since there's no way of having a Map interface that extends ImmutableMap to add extra operations, so you can get nasty runtime surprises if you've got the wrong one. Conversely, if you want a mutable map keyed on a non-trivial structure, you have to do just as much boilerplate as the author complains about to set up private members, setters, builders, etc. Obviously C++ can do it quite readily, but nobody accused it of lacking features. This is really just another use case for generics, and the discussion there is well-trodden. Go probably isn't the language for you if you value generics more highly than fast compile times, native binaries, etc, but I'm not sure why that still seems to come as a surprise.

nine_k 9y ago
Lombok takes care of most of such boilerplate in Java. Code generating tools for Go also exist. The difference is that they produce source code, while things like Lombok, or any reasonable macro system, never surface intermediate code, unless explicitly asked.
- pebers 9y ago
  That's still solving the problem by working around the language though. And surely it's the job of your build system to automate and hide the codegen process? Admittedly go build & go generate don't do that well, but they aren't the only options out there.
vbezhenar 9y ago
Java does it well, you can easily make good immutable map interface. The problem is with Java Collections which is just a poorly designed library, like most other standard Java libraries. I really hope that someone will use JVM with another built from the ground sane library. The only thing Java misses is covariance/contravariance for generics, but with some unsafe casting it'll work.

codegladiator 9y ago

> That’s an infuriating amount of code to write 24 lines, really ?

WaltPurvis 9y ago
It was down to 10 after a suggestion in the comments. Given the number of times you might actually need an immutable, ordered map (total count so far in my life = 0), having to write 10 lines of code does seem like an odd reason to be furious with an entire programming language.

marcus_holmes 9y ago

I keep getting drawn back to Go. I left it a while back, with a lot of the same frustrations. But then I tried a bunch of other things, and nothing seemed to work better. There seem to always be some frustrations with whatever language. And I found myself craving that simplicity again. I might get annoyed with it again, and try some other stuff. And that might stick. But I suspect Go is the worst language except for all the others [1]. [1] http://www.goodreads.com/quotes/267224-democracy-is-the-worst-form-of-government-except-for-all http://www.goodreads.com/quotes/267224-democracy-is-the-wors...

andreasgonewild 9y ago
I did the back-and-forth for several years with Go. What drew me in was promises and wishes, what made me leave every time was realizing I had fallen for the same stupid trick again. It only looks simple because of the features they skipped and the arbitrary limitations they decided on. Once a codebase reaches a certain level of complexity and the need for more powerful abstractions arises, the perceived simplicity is no more.

RobinsonCrusoe 9y ago

Go is seriously limited language by design. If the limitations are starting to bother a person, they're better off just using a different language.

jondubois 9y ago

It's so interesting how the hype cycle works. Only 1 year ago, people on HN were bashing Node.js hard and saying that you should use Go instead and everyone was praising Go. Now it seems everyone is bashing Go. Moral of the story; never buy into the hype whether it is positive or negative. I think that Go is just fine and so is Node.js. Maybe the author of the article makes a valid point, but no language is perfect and ultimately you have to understand it well in order to use it well.

gipp 9y ago
I've been reading HN for a couple years now and can't recall there ever being a consensus positive opinion about Go. All the discussions pretty much looked like this one.

Young_God 9y ago

In addition to what you describe, my other big complaint with Go is the attitude you find from the devs, in threads discussing these types of challenges. "Oh, you think you want an ordered map? No you don't. Your reasons are stupid. You're stupid. Now gtfo and start using Go to write things we deem to be respectable."

andreasgonewild 9y ago
Agreed, one of the most dogmatic communities I've had the misfortune of stepping into. But then that's pretty much a requirement given the amount of pretending they need to pull off to keep their bubble intact.

Navigator 9y ago

The sorted map alternative is really only viable for insert-only maps or really small maps. You'd have to remove keys from the list when they're removed from the map. Most sorted map implementations are based on trees.

brango 9y ago

Go's been great for creating a web scraper. But it's been an unmitigated disaster for being able to write the data to a database due to the immaturity of ORMs. Might as well not pretend something is an ORM if it can't do the fundamentals (like upserts), fully hydrating structs, etc.

doublerebel 9y ago
Similar to doublerebel/publictransport, I ran into some issues hydrating structs the way I expected from other languages. So I wrote bellows [0], a helper to flatten and expand nested maps and structs. Not quite the same but might help someone. [0]: https://github.com/doublerebel/bellows/blob/master/README.md https://github.com/doublerebel/bellows/blob/master/README.md

trumpownsyou 9y ago

go is for hipsters

Mikhus 9y ago

After a year of programming with Go I have noticed that I, an old C++ programmer, have the reflex to decompose a program in terms of interacting data structures (objects) which encapsulate their behavior. I programmed like that in Go in the beginning. But when I looked at other Go code and especially the std lib code which is easily accessible, I was always amazed at the simplicity of the code. Now I try to write simple programs and this is hard after years of C++ programming. I don't know if there is a term for Go like programming. I'm tempted to call it minimalism. It may be uncomfortable for people coming from classical programming, but the simplicity of the language and the code is a clear win in the long run.

deleted 9y ago

[deleted]

AReallyGoodName 9y ago

I don't know if you are the author of this post or not but try Crystal. It fixes all the things wrong with Go in my opinion.

justin66 9y ago

It's an interesting point of view that regards those four items as necessary requirements for a data structure, and then regards the 24 lines of code needed to implement it as a massive "explosion of code." It would be interesting to know what language is considered the ideal tool for someone who looks at things that way. Something functional?

evolighting 9y ago

Where Google is SO GREAT that everyone could only follow them, never doubt any thing, or it would turn out to be that you are stupid