1. 21
  1.  

  2. 29

    tl;dr: wants generics

    1. 11

      Maybe we should add a new tag, “go-generics”… :-)

      1. 5

        That’s not really true. He wants some way to avoid writing the same code multiple times. Generics is a solution to that, but not the only possible solution.

        1. 10

          it’s half the truth, i’ll give you that :)

          i’m just a bit annoyed by the go complaints, it’s the ever repeating same. with go you sometimes have to copy some code, but that can be minimized if done good. go sometimes is verbose, but that’s imho the tradeoff for the small syntax and orthogonality.

          last but not least: maybe just use another tool if go doesn’t work for you ;)

          1. 7

            i’m just a bit annoyed by the go complaints, it’s the ever repeating same. with go you sometimes have to copy some code

            Copy code, copy complaints. The price you pay for a simple language.

            last but not least: maybe just use another tool if go doesn’t work for you ;)

            I can’t speak for the author’s situation but sometimes these posts are born more from other’s imposing solutions. There are plenty of good projects that if you want to contribute to, you have no choice but to use what the chose. And, more often in the case of Java, your employer might force a technology. These blog posts are sometimes a desperate plea for help.

            1. 2

              And, more often in the case of Java, your employer might force a technology. These blog posts are sometimes a desperate plea for help.

              i’m aware of that, but then, there are so many posts with say “generics are the solution”, that i wonder why the author did have to include that point. the language isn’t going to change for the foreseeable future, and it’s better to just show others how to solve these problems in the current boundaries of the language (imho). it’s just more productive and helpful.

              having to use a tool you are not familiar with (and not having the time to proper study the docs) sucks, maybe this is the problem for the author of the article. i guess i’d be lost when i’d have to use c# and would complain, too :)

            2. 3

              i’m just a bit annoyed by the go complaints, it’s the ever repeating same.

              It’s not unique to Go. People’s complaints about C++, Java, Ruby, &c. have all been more or less the same in the last ten years as far as I can tell. C++ is confusing, Java is cumbersome, Ruby crashes and uses too much memory.

              As long as the languages don’t change, the complaints won’t, either.

              1. 0

                Only one of the languages you’ve mentioned has been wilfully ignorant of the history of language design, to the point of being proud of its ignorance.

                1. 3

                  I keep seeing this meme repeated without sources, which bothers me - sourcing claims like this makes the difference between a cogent argument and an ad hominem attack.

                  1. 1

                    It would be good to have a more “sourced” and supported debate about Go in general. That would change the “pro” camp’s approach as well, though. No more “Go was supposed to be X so X is how it is supposed to be. If you don’t like it, don’t argue about it – use another language.”.

                    1. 1

                      Absolutely.

                      A good example of sourcing, for the ‘go generics’ debate:

                      Four proposals for generics with unacceptable tradeoffs (skip to the end of each for the summary of why they don’t work out).

                      1. 1

                        These make me wonder. Many languages have parameterized types; and in usable forms, to boot. The “unacceptable tradeoffs” must be acceptable in those languages – how is that? To say that those languages are bad, or do not achieve Go’s goals, is just assuming the conclusion.

                        Only two of these proposals (2010-06 and 2013-10) have sections set aside for comparisons to the literature, and they are thin. The first one mentions only C++, the second mentions C (?), C++ and Java. There’s a lot of other systems out there, though; many are decades old, like ML’s, and work quite differently from those of C, C++ and Java. More recent languages – like Haskell and Scala – provide further examples to work from.

                        These proposals by themselves – which of course does not make a conclusive case – do seem to indicate that Go is being developed with little reference to much of the work done in language design, and in a way that’s deliberately narrow. First, they don’t mention that work; and second, many of the reasons given for rejecting this or that parameterized types proposal – like some of the syntax complaints – seem quite finicky and particular (and eminently solvable).

                  2. 1

                    But let’s say it weren’t – people would still complain about it, and that wouldn’t be any kind of special discrimination against that language. People who are annoyed by complaints about their favourite language would do well to consider how other languages are treated before bringing a case before us.

          2. 11

            I say this as a huge Clojure fan who loves immutable data:

            Why do you find yourself needing this so often?

            Can you provide a concrete example, rather than a synthetic one?

            I write a lot of Go, and this need has never come up.

            1. 2

              What is the “this” in your comment? The post has two points: needing some data structure like a map but slightly different semantics and immutability.

              1. 2

                Either.

                1. 1

                  It didn’t seem like he was looking for persistence so much as const references so that values can’t change out from underneath him.

              2. 2

                All of these languages are Turing complete; you don’t “need” anything. The only question is how much the language can help boost your productivity by minimizing the amount of work you have to do.

                1. 1

                  The reasons that people find mutability beneficial are widely documented on the internet, including by the author of Clojure. Are you looking for something or more specific?

                  1. 2

                    I assume that you meant “immutability”. I’m not questioning the utility of immutability.

                    The specific example given is synthetic. I want a concrete example from a real program. I’m skeptical that this or similar complaints would hold up under specific scrutiny.

                    1. 1

                      It’s beneficial, as far as avoiding bugs and certain kinds of tricky logic, but I don’t think there’s anything you can fundamentally do with immutable data that you can’t do with mutable data. Which means that you never actually “need” immutable data, you just want it. If you want to write code with immutable data badly enough to hack together a way to get it in a language that doesn’t support it, maybe you should just switch to a language that has the features that you want instead.

                  2. 3

                    Why do folks have such a hard time looking for 3rd party packages? An immutable, sorted map doesn’t come up all that often (I don’t think I’ve ever “needed” the immutability bit), but there are packages out there that can do it. For example: https://github.com/Workiva/go-datastructures#dtrie. *

                    It’s not type safe, but it fits the requirements he wanted.

                    • caution: I’ve never actually used this package
                    1. 4

                      One of the chief dangers of excessively verbose and inflexible code is not just that its implementer has to do a lot of typing; it’s that all that typing provides a high surface area for bugs and generally difficult-to-reason-about implementations. This sort of issue affects whoever has to use the library, not just whoever has to do the implementing.

                      It’s also, by the way, generally true that code which somebody else wrote is going to be more general and, you know, not written by you, and therefore magnify the verbosity and difficult-to-reason-about issues.

                      1. 5

                        Why do folks have such a hard time looking for 3rd party packages?

                        Sometimes people don’t want to add external dependencies for things that, in some cases, are (relatively speaking) straightforward to implement.

                      2. 2

                        Perhaps something like a simple form of codegen for common data structures and algorithms?

                        Isn’t go generate exactly this feature?

                        1. 4

                          Superficially, yes. Realistically, it has usability issues that disqualify it as “simple”. It’s not an integrated part of the build process, so here’s hoping you have a script that you can drop it into, and you’re not in the habit of actually using go build (which falls short of the 40-year-old make when it comes to rebuilding generated files as needed when something changes). If it’s a library you’re using that requires codegen to fit your app, it’s that much worse, since now the library is imposing on your build process. Plus go generate‘s only mode of operation is processing one file with magical comments and generating a different disk file for the build to find later, which you’ll probably be forced to check in whether you like it or not. Compare to macros (any sort), which are processed logically by the compiler without having to plop the generated source down on disk and manage it separately. Or the kind of codegen commonly employed in libraries in dynamic languages, which, hey, it might be string eval, but at least it goes off cleanly without user interaction. And when you consider that 99% of the use of go generate is for stuff that in a sane world wouldn’t require codegen at all…

                          I write Go for work, and most of the time I even like it, but sometimes I swear the Go devs are passing off laziness and failure of imagination as wisdom and timeless minimalism.

                          1. 1

                            I write Go for work, and most of the time I even like it, but sometimes I swear the Go devs are passing off laziness and failure of imagination as wisdom and timeless minimalism.

                            This is a great quote and I hope to use it some day.