37 ms·

Toward Go 2

• fusiongyro 9y ago
  The paragraph I was looking for is this: > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can't answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use cases, we could begin to answer a question like this by examining the significant ones. This is a much more nuanced position than the Go team has expressed in the past, which amounted to "fuck generics," but it puts the onus on the community to come up with a set of scenarios where generics could solve significant issues. I wonder if Go's historical antipathy towards this feature has driven away most of the people who would want it, or if there is still enough latent desire for generics that serious Go users will be able to produce the necessary mountain of real-world use cases to get something going here.
  • TheDong 9y ago
    The fact that go1.9 will include a "sync.Map" type which should be generic, but can't be due to the language's limitations should already answer that. See also all of the "container" portion of the stdlib: https://golang.org/pkg/container/ https://golang.org/pkg/container/ All of those should be generic, but aren't. Clearly there's already sufficient demand for generic collections just based on the stdlib and the fact sync.Map was seen as needed.
    • piinbinary 9y ago
      I'm not sure why this is being downvoted. These are perfect examples of where generics would make a genuine improvement.
    • xienze 9y ago
      > All of those should be generic, but aren't. They aren't because the prevailing attitude is "what do you need generics for? Just do a cast!" The issue is the Go developers are unwilling to consider generics until someone can come up with a problem that absolutely, positively cannot be solved without generics. And of course there isn't one.
      • bpicolo 9y ago
        I mean, having to cast after every single call to heap is a problem. Go is turing complete already, so all problems are already able to be solved. :)
    • jadbox 9y ago
      Agree- having map, filter, reduce with strong type guarantees will be a huge boon. Imagine being able to map over a collection and the code hints will understand the new output types in the chain. This is something you cannot have when your higher order ops are all typed to Interface {}.
      • djur 9y ago
        Unfortunately, Go is a language whose original creator is of the opinion that map/filter/reduce are just ways to make your program "fit on one line"[1], and that you should just use a for loop[2]. [1]: https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSCHS0 https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC... [2]: https://github.com/robpike/filter https://github.com/robpike/filter
    • maxekman 9y ago
      The sync.Map case for generics is a perfect example. Thanks for bringing it up.
    • jerf 9y ago
      "All of those should be generic, but aren't." I think even more damning then "these should be generic" is that there should be more of them. The real problem is the lack of generics inhibits the introduction of more data structures because they are hard to use. It is true that arrays and maps/hashes take you a long way, but there's a lot of other useful data structures in the world. And despite the fact they may look easy at first, data structure code tends to be notoriously difficult to write both correctly and with high performance.
  • crawshaw 9y ago
    Several members of the Go team have invested significant effort in studying generics and designing proposals, since before Go 1.0. For example, Ian Lance Taylor published several of his previous efforts, which had shortcomings he was dissatisfied with. I believe your impression of the Go team's position has been corrupted (likely unintentionally) by intermediaries.
    • kyrra 9y ago
      Link to top-level proposal: https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-... If you scroll to the bottom, you can see 4 large proposals written by Ian over the years.
    • pjmlp 9y ago
      Except they seem to focus only on Java, .NET and C++, forgetting that generics were initially implemented in CLU back in 1975, and there were several programming languages since those days that had some form of generics being designed into them.
      • masklinn 9y ago
        > Except they seem to focus only on Java, .NET and C++ C# isn't mentioned in any of the previous proposals, only Java, C++ and C.
        • _old_dude_ 9y ago
          C# does generics specialization at runtime, hard to do if you have no JIT :)
          • davidp 9y ago
            Thanks for the tip, you made me go google some things! [0] Do you need a full-on JIT, or just a runtime? [1] [0]: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/differences-between-cpp-templates-and-csharp-generics https://docs.microsoft.com/en-us/dotnet/csharp/programming-g... [1]: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/generics-in-the-run-time https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
  • callesgg 9y ago
    Not having generics makes it hard to do proper type safe functions and libraries. My specific problem when i realized it was an actual problem was when i tried to connect to a sql databse and working with a proper ORM.
    • weberc2 9y ago
      Why does an ORM need generics? I ask because I've built something very like an ORM in Go and I didn't have any problem without generics. ADTs on the other hand...
      • callesgg 9y ago
        In my specific case it was the fact that i could not have one insert function or one update function. I would need one for each and every struct(table). These days there is a tool that can generate all those struct methods: https://github.com/vattle/sqlboiler https://github.com/vattle/sqlboiler So from the ORM perspective we (as the community) have worked around it.
        • staofbur 9y ago
          This is incidentally where .Net was around the 1.1 release (2003ish) We had code generation frameworks kicking out swathes of boiler plate. Now Repository<T> and for us around 200,000 lines of code are gone and only one narrow set of tests to execute.
        • slantedview 9y ago
          The idea that we don't need generics because we can generate code is kind of ridiculous, and certainly doesn't pass the simplicity smell test.
          • weberc2 9y ago
            He wasn't making that argument...
  • zerr 9y ago
    They should look up the usage of empty interfaces [in the wild or in-house].
    • munificent 9y ago
      This is a great point. Other analysis one could do: 1. Look at uses of cast operators in a codebase. How many of those would be eliminated by making the surrounding operation generic? 2. Go through the language spec and see how many features could be moved out of the language and into the core library if generics were supported.
  • tomovo 9y ago
    Go 2, codename "Hell with generics". Just kidding of course. I am sure some useful form of generics will eventually find its way in.
    • tomovo 9y ago
      More importantly though, looking at C++ I think it may be hard to come up with a generics system that doesn't lend itself to abuse and ridiculous mega constructs. I would love to see something that provides power in ways that disallow craziness (Boost Spirit kind) but provide enough power to avoid all the cases that suffer without generics.
      • eropple 9y ago
        Both C# and Java have taken different approaches to constrained generics that are still really useful for about...I dunno, the 90% case (C# has reified generics and so it's more like 95%, but type erasure also has its pluses when you're off-roading around in a framework somewhere). Scala goes a little further and covers, like, the 99% case, and plenty of inadvisable ones too.
      • int_19h 9y ago
        C++ doesn't have generics, it has templates, which are effectively a syntax-constrained form of macros. That's why it lends itself to abuse (or creative use, depending on your take on macros).
        • tomovo 9y ago
          So C++ generates separate code for each template type and C# and Java do a typecheck at compile time and reuse the same codepath for all types at runtime?
          • pjmlp 9y ago
            .NET does a mixture of C++ and Java, meaning generic instatiations for value types get their own version of the code, instatiations for reference types get a shared version.
  • HarkMamilton 9y ago
    I think this is too little, too late. Anyone who saw an advantage to using generic programming is already using something else. They've already invested resources in something besides Go; why spend the effort to switch back for what will, at best, probably be very mediocre support for parametricity compared to whatever they're already using?
    • cat199 9y ago
      This presumes that: a) generic programming is a new thing b) any of those people you mention aren't using go for some things and other things where this feature is desired c) that the feature will 'at best' be at level X d) that level X won't be enough to satisfy some use cases and a whole host of other things, not least of which the fact that go itself was invented to suit some purpose after other languages existed, and has been successful for many users
    • matthewowen 9y ago
      Most of the projects which will use Go have not begun yet. Adding support means people may use Go for those future projects.
      • resf 9y ago
        The opposite side of that coin is that other programming languages do already exist. Any new language is already playing catch-up to reach the state of the art. Go is 10 years old and in those 10 years has made astonishingly little progress at implementing basic features such as error handling, because the designers cannot escape their bubble. The most sensible thing to do is to kill Go, not to improve it. The root problem is not the lack of this or that feature, but the bizarre beliefs of the people running the project.
        • johnwilkesbooth 9y ago
          > The most sensible thing to do is to kill Go, not to improve it. Care to expand this? It's pretty clear that you don't find Go suitable for your own use cases, but I've found it to be an extremely productive language, despite the fact that it may have a couple of warts.
  • wheaties 9y ago
    If they want to "learn" about generics perhaps they can read the literature of the past 30yrs and look at how other languages have adopted those learnings: Java, C#, Haskell, OCaml and Coq. Look, even allowing type aliases to become part of an interface declaration would be a HUGE win. You can't currently write portable arbitrary data structures without reimplementing them with a code generator. Ugh!
    • masklinn 9y ago
      > perhaps they can read the literature of the past 30yrs 40, nearing on 45: > Milner, R., Morris, L., Newey, M. "A Logic for Computable Functions with reflexive and polymorphic types", Proc. Conference on Proving and Improving Programs, Arc-et-Senans (1975)
      • endymi0n 9y ago
        Guess what: they did. https://news.ycombinator.com/item?id=8756683 https://news.ycombinator.com/item?id=8756683 They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them. Whether that's a good outcome, I'm not fully sure - but there's definitely a lot of research in that area.
        • masklinn 9y ago
          > Guess what: they did. Yeah as pointed out in that very thread by pjmlp: As usual, it lacks discussion about generics in: Eiffel Ada Modula-3 D MLton .NET Rust Haskell OCaml Sather BETA CLU Oh wait, they're pointing out that none of these is even remotely being discussed in the article hinting that they did not, in fact, and much prefer taking down strawmen they built from some sort of daguerreotypes of Java and C++. > They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them. Ah yes, the ever so convenient but never actually clarified "tradeoffs", which only ever happen for generics but oddly enough apparently don't happen for any other feature. > there's definitely a lot of research in that area. That there is, would be nice if Go's designers ever bothered actually using it.
  • solomatov 9y ago
    I would start using Go in my projects if it introduces generics. It's a show stopper for me.
    • Spiritus 9y ago
      The question is _why_ do you need generics, for what use case(s), etc? Saying “I need generics otherwise I won’t use Go” is exactly the type of feedback they don’t want. It seems like you’d have valuable feedback given that it’s a “showstopper” for you.
      • Touche 9y ago
        Do you not see how this is an insulting question? You know very well the use cases for generics. You do not need users to present new ones. You can literally Google "generics use cases" and get hundreds of thousands of results that directly answer that question.
        • Spiritus 9y ago
          Did you even read the blog post? Such feedback was explicitly asked for.
          • AaronFriel 9y ago
            I think the problem everyone has swallowing that ask is that the value of generics is that it's so widely taught, with so many use cases, and so much literature (academic and otherwise) that the suggestion that they need use cases is laughable. What use cases do they need other than the extremely large body of public knowledge on the matter, and why would one more example change anyone's mind? To me this represents the epitome of the insular and outwardly hostile attitude that the Go team has toward good ideas elsewhere in the CS world. Would it really make a difference to the team if I or anyone else were to hunt down specific examples and present them with problems solved with generics and stronger type systems? I doubt it.
            • 9y ago
  • xienze 9y ago
    > This is a much more nuanced position than the Go team has expressed in the past, which amounted to "fuck generics," but it puts the onus on the community to come up with a set of scenarios where generics could solve significant issues. Nah, this is pretty much the same answer they've been giving all along, lots of handwaving about how generics are so cutting edge that no one can figure out how to use them effectively yet ("we just can't wrap our heads around this crazy idea!") In other words, don't count on them in Go 2.
  • stormbrew 9y ago
    If I were in the "go community" I would be pretty annoyed by this quote. I would find it dismissive of the literal years of people pointing at areas of their code that are bloated and less safe due to not having generics. It doesn't seem to me that there's a shortage of people pointing out real-world use cases at all, and I'm looking from the outside in.
    • liveoneggs 9y ago
      the use of the monotonic click example is also interesting because of the similar tone of responses to that issue. I think it's just the rsc way. basically it goes like: > If google isn't screaming about it, it's not important. > If google has a workaround, then it's fixed.
      • grey-area 9y ago
        As a maintainer, you're bombarded with reasonable requests (I think around 10 a day on the Go project). Part of your job is to turn down hundreds of these and pick the few that benefit the most people from a diverse set of users, and also don't break anything or extend the api surface too much. Then whatever you choose people complain vociferously. Sometimes good requests get ignored in that noise. Choosing is hard, and while they could improve I think the Go maintners have done a pretty good job, and are willing to admit mistakes.
        • rattray 9y ago
          > and are willing to admit mistakes. Admitting a mistake on "generics" would probably go a long way towards credibility for the team. No matter how many excellent decisions they've made that have delicately balanced opinions and tradeoffs, this one hasn't gone over well, and it's very widely known.
  • saghm 9y ago
    I haven't programmed in Go, but from what I understand, Go's explicit error handling isn't enforced by the type system, as you can leave off an `if err { ... }` check and everything still compiles. I think adding a generic result/error type (like the Result type in Rust or the Either type in Haskell) would be a pretty useful feature, as currently the error handling sits in kind of a weird place between forced handling and traditional exceptions.
    • imsofuture 9y ago
      Go's errors are really nice (if a bit repetitive) in my opinion. Type signatures enforce that you accept and acknowledge an error returned from an invocation, but leave it up to you to handle, pass along, or silently swallow.
      • acdha 9y ago
        Does that mean it now throws an error if you use the common punt like `foo, _ := …` and never check `_`?
        • imsofuture 9y ago
          No, but that's what I mean as intentionally ignoring.
        • growse 9y ago
          No, because using `foo, _` you're explicitly saying that you don't care about the error.
      • hdhzy 9y ago
        So... Just like checked exceptions in Java?
        • imsofuture 9y ago
          Yes, it's somewhat similar in that the compiler checks if you have handled or chosen not to handle an error. You're not allowed to ignore it (through omission).
  • untog 9y ago
    It strikes me as a pretty odd statement, though. I'll admit that I'm not very familiar with Go, but surely you can look back at the benefits of generics in other languages? Go is hardly so specialised that you can't learn a single lesson from elsewhere.
    • Touche 9y ago
      I agree, I didn't find the statement refreshing at all, I found it insulting. You damn well know the use-cases for generics. If you still don't like it; fine, say that explicitly. Don't pussyfoot around it and play the "we just don't know that much about it yet" lie.
  • coldtea 9y ago
    >This is a much more nuanced position than the Go team has expressed in the past, which amounted to "fuck generics," but it puts the onus on the community to come up with a set of scenarios where generics could solve significant issues. It seems to me to be the same "Generics is some foreign concept we just heard of, and we're not sure how to implement them in Go yet, but we'll consider it if we chance upon some magical optimal way" that has been the official party line of Go since forever... Even the "we are asking you for proposals" part has been there since a decade or so...
  • pjmlp 9y ago
    I would already be happy if they supported generics like CLU did in 1975, no need for nothing too fancy.
  • anth1988 9y ago
    This is just another way of saying fuck generics. They really can't see any solvable problems after years of people asking for generics?
  • slantedview 9y ago
    The idea of needing to come up with use cases for generics is baffling. The existence of generics in numerous other languages already support of plethora of use cases. I really don't get that statement at all.
    • 43224gg252 9y ago
      Then why don't you come up with a legitimate use case?
      • treehau5 9y ago
        I think this is a fair question. We have a lot of pseudo-intellectuals here that think 90% of their job isn't writing business functions. Not having generics in Go has not hindered me at all in performing the objectives of my business. Everyone wants generics, no one knows why. When I had generics in my previous two roles where I used Java and C# respectively, I can count on two fingers the number of times I needed them, and once was because a library forced me to.
        • slantedview 9y ago
          > Everyone wants generics, no one knows why This is such a troll'ish statement, but I'll respond anyways because maybe you actually are just that uninformed. Without generics any number of libraries that utilize generic function blocks - Func [1] in C#, Callable [2] in Java, etc., and do things like return the function's type parameter as a method result, would not be possible. This is exceedingly common, at least in libraries. If you want to know how common, let me refer you to my friend http://google.com http://google.com. Just because something isn't valuable to you, personally, doesn't mean it's not valuable. As in all aspects of life, not everyone is you. 1. https://msdn.microsoft.com/en-us/library/bb549151(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/bb549151(v=vs.110).... 2. https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Callable.html https://docs.oracle.com/javase/7/docs/api/java/util/concurre...
          • deleted 9y ago
  • kernelbandwidth 9y ago
    The request for use cases in Go seems a bit like begging the question to me. Since Go doesn't have generics, anything designed in Go will necessarily take this into account and design around this lack. So it's relatively easy to show that Go doesn't have a compelling use case for generics, since the designs implemented in Go wouldn't (usually) benefit from generics! Rust has generics and traits/typeclasses, and the result is my Rust code uses those features extensively and the presence of those features greatly influences the designs. Similarly, when I write Java, I design with inheritance in mind. I would have trouble showing real world use cases for inheritance in my Rust code, because Rust doesn't have inheritance and so the designs don't use inheritance-based patterns. Essentially, how does one provide real world evidence for the utility of something that's only hypothetical? You can't write working programs in hypothetical Go 2-with-generics, so examples are always going to be hypothetical or drawn from other languages where those tools do exist.
    • erikpukinskis 9y ago
      This suggests that both generics and inheritance are unnecessary.
      • kccqzy 9y ago
        It only suggests you can't easily give an example because the language is forcing a design where such things aren't needed. Sort of like linguistic relativity.
        • XorNot 9y ago
          Which still proves the parent's point: it's not necessary. The question is what absolutely can't be done without them (probably nothing) so a better question is how much design/engineering/test time could be saved with them? On the latter part I'm fairly cynical these days, since I'm presently on a team where the lead embraced a Scala-DSL heavy, functional design and the net result has been a total loss of project velocity because when we need to prototype a new requirement, the push back has been paraphrasing "oh, could you not do that in <core product> and handle it somewhere else?" - so we end up with a bunch of shell scripts cobbled together to do so.
  • vec 9y ago
    I'm not even a Go developer, I just played with it a bit a couple of years ago and used it for a small one-off internal API thing, and I can think of a dozen real-world use cases for generics off the top of my head. * type-safe containers (linked lists, trees, etc.) * higher order functions (map, reduce, filter, etc.) * database adapters (i.e. something like `sql.NullColumn<T>` instead of half a dozen variations on `sql.NullWhatever`) * 99% of functions that accept or return `interface{}` I appreciate that they seem open to the idea for v2, but "the use case isn't clear" is absurdly out of touch with the community. Using `interface{}` to temporarily escape the type system and copy/pasting functions just to adjust the signature a bit were among the first go idioms I learned, and they both exist solely to work around the lack of generics.
    • zemo 9y ago
      > I'm not even a Go developer > Using `interface{}` to temporarily escape the type system tbh if you program Go correctly, you use interface{} pretty rarely.
      • camus2 9y ago
        > tbh if you program Go correctly, you use interface{} pretty rarely. It's a bit like saying "if you program C correctly, you use (void *) pretty rarely.". that's not the case, Go maintainers themselves keep on adding API with interface {} everywhere. Are you saying they are not programming Go correctly?
    • spyspy 9y ago
      It's generally the opinion of the Go community that map, reduce and filter are bad ideas due to how easily they are abused. A for loop gets the job done easily enough. If you've ever worked with data scientists working with Python, you'll quite often see them all chained together, probably with some other list comprehensions thrown in until it becomes one incomprehensible line.
      • rbehrends 9y ago
        The same argument applies, mutatis mutandis, to imperative iteration constructs such as range.
  • hota_mazi 9y ago
    That's a charitable way to look at the comment. My more cynical reaction is that someone who doesn't understand the benefit of generics or can't even come up with examples where generics are superior to their alternative should not be allowed anywhere near a language design discussion.
  • kccqzy 9y ago
    Generics in Go: https://twitter.com/snoyberg/status/882255351382462464 https://twitter.com/snoyberg/status/882255351382462464
    • kccqzy 9y ago
      It really reminds me of early C macros where people use the ## operator to synthesize monomorphized versions.
      • fanf2 9y ago
        The ## operator is an ANSI C feature, so not really "early". In pre-ANSI preprocessors you had to abuse the lexer to paste tokens, e.g. by relying on // being deleted - nowadays comments are replaced by space.
    • stefantalpalaru 9y ago
      > Generics in Go: https://twitter.com/snoyberg/status/882255351382462464 https://twitter.com/snoyberg/status/882255351382462464 Generics and Go: https://github.com/stefantalpalaru/golib-nim https://github.com/stefantalpalaru/golib-nim
    • zyxzkz 9y ago
      That's an awesome trick, using angle brackets that aren't angle brackets!
• jgrahamc 9y ago
  I didn't expect to get namechecked in that. Shows the value of constantly being transparent and supporting open source projects.
  • rsc 9y ago
    It absolutely does, and thank you. (I thought you might be here so I could thank you in person.)
    • jgrahamc 9y ago
      You're most welcome. We love Go and use it extensively.
• Analemma_ 9y ago
  > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. This is sampling bias at work. The people who need generics have long since given up on Go and no longer even bother participating in Go-related discussions, because they've believe it will never happen. Meanwhile, if you're still using Go, you must have use cases where the lack of generics is not a problem and the existing language features are good enough. Sampling Go users to try and find compelling use cases for adding generics is not going to yield any useful data almost by definition.
  • eropple 9y ago
    > no longer even bother participating in Go-related discussions, because they've believe it will never happen /raises hand I like when tools are good, but I've basically written off Go as a tool for generating unsustainable code right now (and a big part of it is the odious options, either type-unsafety or code generation, for things that are trivially handled by parametricity). If things change, I'll be happy to revisit it, but the described thought process just ignores my existence. And that's fine from my perspective, because I don't need Go, but I'd still like it to be better in case I do need to use it.
    • kardianos 9y ago
      I think the Go team would still like to understand your production uses that caused you to write off Go. What is your problem domain? How would you accomplish that in Go? How did you actually solve your problem with a different language? For me, user provided data structures are the only thing that comes to mind (sync.Map for example) in my production use of Go. But even then, my pain (time spent, errors made) due to a lack of generics is low. You may have written off Go. But if you're willing, I bet the Go team would still like to read your production code use-cases that caused you to do so.
      • eropple 9y ago
        My "problem domain" is "good, correct code". I write code in many different spaces, from web software to mobile apps to (a lot of) devops tools to (less these days) games. My criticism of Go isn't "it's not good at code for my problem domain," it's "it's not good at code for your problem domain, either, and your workarounds shouldn't need to exist." User-provided data structures are a big one. (A language where I have to copypaste to have typesafe trees is a bad language.) But, beyond that, I build stuff to be compiler-verified. Here's a trivial example that I did yesterday that I straight-up can't do in Go, but did in C# as part of a object graph rehydration routine (where object A required pointers to object B from a different data set, and since it's 2017 we aren't using singletons so the JSON deserializer takes in converters that look up objects based on keys in object A's JSON representation): public interface IKeyed<T> { T Key { get; } } Just being able to do that on an object is powerful. C# has reified types; I know what T is at runtime. (I can't specialize on the type in C#, but I can fake it.) But I also know what it is at compile-time, and so I can't accidentally pass `IKeyed<String>` and `IDictionary<Int32, DependentObject>` to the same function because type constraints, yo. I don't really care about fast code, because computers are all future-computers-from-beyond-the-moon. If I'm using a statically-typed language, I care about correct. Duplicated code is code that will--not may--lead to bugs. State I have to maintain in my head (like "this is an int map, talking to an int-keyed object set") is state that will--not may--lead to bugs. If you're a statically-typed language that isn't helping me avoid bugs, you might as well not exist. You don't have to be whomping around stuff like Scala's Shapeless--I would argue that you shouldn't--but you have to provide at least a basic level of sanity and the difficulty of expressing stuff outside of parameterized types (even when there are workarounds) makes it not worth the hassle. I'll cape up for damned near everything in at least some context, from dynamic languages like Ruby and ES6 to Java (well, Kotlin) or C# to Modern C++ to Scheme or a Lisp. My no-buenos on programming languages are limited pretty exclusively to C and Go because both languages encourage me, encourage all of us who use them, to write bad code.
• JepZ 9y ago
  I know there is a lot of discussion about generics, but I am not sure if that is missing the point. I mean 'generics' sounds like a complex concept from the java development and I am uncertain if that's really what we need in go. From my experience I think we should talk about container formats because they make 80% of what we would like to have generics for. Actually, go feels as if it has only two container data structures: Slices and Maps. And both feel as if they are pretty hard coded into the language. Yes, I am sure there are more container formats and it is possible to build your own, but I think it is not easy enough.
  • masklinn 9y ago
    > I mean 'generics' sounds like a complex concept from the java development and I am uncertain if that's really what we need in go. That's inane and insane. Java generics do almost nothing, they don't even exist at runtime in a language with (much like Go) heavy runtime semantics. Here's what Java's generics do: get typechecked, and insert implicit casts. > Yes, I am sure there are more container formats First, you forgot Channels and arrays (which are distinct from slices) as well as "range" to iterate over them generically, second there are more containers than that in Go's own standard library: https://golang.org/pkg/container/ https://golang.org/pkg/container/, https://github.com/golang/go/issues/18177 https://github.com/golang/go/issues/18177 > it is possible to build your own, but I think it is not easy enough What does that mean? It is not easy enough what? To write containers? To have generics?
    • JepZ 9y ago
      So if generics in java don't do anything beyond 'get typechecked, and insert implicit casts.' the empty interface is enough for all use-cases in go?
      • masklinn 9y ago
        1. the empty interface does not do the first one, and thus does not allow writing typesafe structures and code 2. and it requires significant expense of explicit casts which are not just sanity checks (which is what they are in java, due to type system weaknesses)
• drfuchs 9y ago
  "Go 2 considered harmful" - Edsger Dijkstra, 1968
  • zeptomu 9y ago
    Underrated comment. :) Haha, thanks. If there's a Go2 there will be a lot of these headlines for blog posts/rants. It doesn't matter if it is true or not, but that phrase is wonderful.
  • masterponomo 9y ago
    Beat you to it:-) https://news.ycombinator.com/item?id=3085082 https://news.ycombinator.com/item?id=3085082
• alexandernst 9y ago
  How about fixing all the GOPATH crap?
  • frik 9y ago
    ++ Now we have at least vendor. But this alien-style fixed paths is really annoying - no other language forces such GOPATH crap. Please remove this limitation from Go 2!
    • artursapek 9y ago
      What exactly is wrong with GOPATH? I find it much easier to reason about than imports in say Ruby or Python, which are global names with no hierarchy and are resolved in much less obvious ways.
      • brango 9y ago
        There's no obvious way to separate personal work, from work work, from exploratory work, from any other way you want to categorise your source directories. You just have to chuck them all in the same root and hope you can remember what each project is for.
        • artursapek 9y ago
          What? Manage it the way you'd manage any other environment variables, like AWS_SECRET_ACCESS_KEY. That's exactly what a bash environment is for.
          • vacri 9y ago
            You want to manage GOPATH as if it were a secret key!? Not ever storing it in repos, having weird dotfiles storing them locally, having to set up a keystore cluster like consul in production? Yuck.
            • artursapek 9y ago
• munificent 9y ago
  > I can't answer a design question like whether to support > generic methods, which is to say methods that are > parameterized separately from the receiver. I work on the Dart language. Dart was initially designed with generic classes but not generic methods. Even at the time, some people on the team felt Dart should have had both. We proceeded that way for several years. It was annoying, but tolerable because of Dart's optional type system -- you can sneak around the type checker really easily anyway, so in most cases you can just use "dynamic" instead of a generic method and get your code to run. Of course, it won't be type safe, but it will at least mostly do what you want. When we later moved to a sound static type system, generic methods were a key part of that. Even though end users don't define their own generic methods very often, they use them all the time. Critical common core library methods like Iterable.map() are generic methods and need to be in order to be safely, precisely typed. This is partially because functional-styled code is fairly idiomatic on Dart. You see lots of higher-order methods for things like manipulating sequences. Go has lambdas, but stylistically tends to be more imperative, so I'm not sure if they'll feel the same pressure. I do think if you add generic types without generic methods, you will run into their lack. Methods are how you abstract over and reuse behavior. If you have generic methods without generic classes, you lose the ability to abstract over operations that happen to use generic classes. A simple example is a constructor function. If you define a generic class that needs some kind of initialization (discouraged in Go, but it still happens), you really need that constructor to be generic too.
  • masklinn 9y ago
    > You see lots of higher-order methods for things like manipulating sequences. Go has lambdas, but stylistically tends to be more imperative, so I'm not sure if they'll feel the same pressure. `range` is generic, and by virtue of that is a builtin which only works with a subset of the also builtin magically generic types. The reason why Go "does not feel the same pressure" has nothing to do with its imperative style[0] it is because they special-cased a few generic structures as builtin very early on, unlike, say, Java (which only had arrays as a typed datastucture). [0] Java and C# are could hardly be more imperative, hell Java is only just adding anonymous functions
• cdnsteve 9y ago
  "We estimate that there are at least half a million Go developers worldwide, which means there are millions of Go source files and at least a billion of lines of Go code"
  • ovao 9y ago
    Perhaps fewer than a billion lines of Go code if there were generics.
• deleted 9y ago
  [deleted]
• deleted 9y ago
  [deleted]
• EddieRingle 9y ago
  > To minimize disruption, each change will require > careful thought, planning, and tooling, which in > turn limits the number of changes we can make. > Maybe we can do two or three, certainly not more than five. > ... I'm focusing today on possible major changes, > such as additional support for error handling, or > introducing immutable or read-only values, or adding > some form of generics, or other important topics > not yet suggested. We can do only a few of those > major changes. We will have to choose carefully. This makes very little sense to me. If you _finally_ have the opportunity to break backwards-compatibility, just do it. Especially if, as he mentions earlier, they want to build tools to ease the transition from 1 to 2. > Once all the backwards-compatible work is done, > say in Go 1.20, then we can make the backwards- > incompatible changes in Go 2.0. If there turn out > to be no backwards-incompatible changes, maybe we > just declare that Go 1.20 is Go 2.0. Either way, > at that point we will transition from working on > the Go 1.X release sequence to working on the > Go 2.X sequence, perhaps with an extended support > window for the final Go 1.X release. If there aren't any backwards-incompatible changes, why call it Go 2? Why confuse anyone? --- Additionally, I'm of the opinion that more projects should adopt faster release cycles. The Linux kernel has a new release roughly every ~7-8 weeks. GitLab releases monthly. This allows a tight, quick iterate-and-feedback loop. Set a timetable, and cut a release with whatever is ready at the time. If there are concerns of stability, you could do separate LTS releases. Two releases per year is far too short, I feel. Besides, isn't the whole idea of Go to go fast?
  • artursapek 9y ago
    They're trying to avoid creating the new Python 3
  • masklinn 9y ago
    Adding generics isn't even backwards-incompatible. AFAIK Java 1.5 was just fine with Java 1.4 code, and so was C# 2.0. The latter using reified generics (and not cheating with builtins) lead to the duplication of System.Collections but given builtins aside as of Go 1.9 it has under half a dozen non-generic collections (versus 25 types in System.Collections, though some of them didn't even make sense as generics and don't have a System.Collections.Generic version) that's unlikely to be an issue.
• bad_user 9y ago
  Java`s generics have had issues due to use site variance, plus the language isn't expressive enough, leading its users into a corner where they start wishing for reified generics (although arguably it's a case of missing the forest from the trees). But even so, even with all the shortcomings, once Java 5 was released people migrated to usage of generics, even if generics in Java are totally optional by design. My guess to why that happens is that the extra type safety and expressivity is definitely worth it in a language and without generics that type system ends up staying in your way. I personally can tolerate many things, but not a language without generics. You might as well use a dynamic language. Not Python of course, but something like Erlang would definitely fit the bill for Google's notion of "systems programming". The Go designers are right to not want to introduce generics though, because if you don't plan for generics from the get go, you inevitably end up with a broken implementation due to backwards compatibility concerns, just like Java before it. But just like Java before it, Go will have half-assed generics. It's inevitable. Personally I'm sad because Google had an opportunity to introduce a better language, given their marketing muscle. New mainstream languages are in fact a rare event. They had an opportunity here to really improve the status quo. And we got Go, yay!
  • jcadam 9y ago
    After some initial enthusiasm due to its gentle learning curve (actually, the Golang learning curve is nearly non-existent for an experienced programmer), I got sick of Go programming pretty quickly. Writing anything non-trivial will have you fighting against the limitations of the language (e.g., lack of generics which is particularly aggravating when trying to write a library). I've mostly moved on to Clojure for programming backend services. I still use Go for the occasional small utility program due to its speed and ease of deployment, though.
    • 43224gg252 9y ago
      I've programmed scores of libraries in Go and found it pleasant, in fact it's more pleasant writing a library in Go than in any other language I've used. I've never once even considered the fact that I might need generics because I've never run into an unsolvable problem or an extremely inelegant engineering solution. I see a lot of people claiming that the lack of generics is a big problem but no one is actually showing a concrete case where generics are necessary. C doesn't have generics but we never have this discussion when we talk about C.
• deleted 9y ago
  [deleted]
• nickbauman 9y ago
  Will there be gotos in Go 2? Asking for a friend.
  • Siecje 9y ago
    They are in Go 1 and Go 2 will be backward compatible, so yes.
  • rsc 9y ago
    Have you actually used Go 1's goto? There's not a lot it can actually do. It's there for generated code state machines, and that's almost all it's good for. But yes, goto will stay in the absence of a very compelling benefit to take it out, a benefit that would far outweigh the cost of breaking all the programs that use it.
• oelmekki 9y ago
  As a ruby and go dev, I'm a bit sad to see backward-compatibility going. Thinking I could write code with minimum dependencies and that would just work as is years later was really refreshing compared to the high level of maintenance needed in a ruby app. But well, I trust the core team to make the best choices.
• tschellenbach 9y ago
  The beauty of Go is that you get developer productivity pretty close to Ruby/Python levels with performance that is similar to Java/C++ Improvements to package management is probably the highest item on my wishlist for Go 2.
  • zbobet2012 9y ago
    That's going to happen before go 2. Go 1.9 / 1.10 time frame.
  • owaislone 9y ago
    > Improvements to package management is probably the highest item on my wishlist for Go 2. The work is in progress and will most likely be available for general purpose use way before Go2. Check it out: https://github.com/golang/dep https://github.com/golang/dep
  • the_duke 9y ago
    There is so much boilerplate you have to write that productivity drops considerably, both because you have to re-re-re-re-implement things (or use code generation) and because you need to scan lot's of redundant code before making sense of it. The alternative is often to just use interface{}, which hurts performance and type safety.
    • tschellenbach 9y ago
      This has so far been a theoretical concern for me only. If you want to write reusable data structures you obviously need generics. But none of the code I've written involves reusable data structures, so I can't say I really miss generics.
    • mmargerum 9y ago
      This is countered by having a much smaller footprint for the language / SDK in your brain. I easily write code twice as fast in Go as I do in Swift.
  • michaelcampbell 9y ago
• johansch 9y ago
  My main wish: Please don't refuse to compile just because there are unused imports. Please do warn, and loudly say it's NON-CONFORMANT or whatever will embarass me enough from sharing my piece of Go code with someone else.. but.. can I please just run my code, in private, when experimenting?
  • fixermark 9y ago
    I'd be even more excited if the compiler were willing to execute complete heresy on my behalf and (with user consent) edit my source code automatically to remove unused imports. ;)
    • johansch 9y ago
      You mean have the compiler modify the source code files destructively? Then I'll have to disagree, that just doesn't make sense.
      • dmit 9y ago
        There was a precedent in Haskell land: https://twitter.com/bos31337/status/116372971509121025 https://twitter.com/bos31337/status/116372971509121025 A more modern implementation: https://github.com/munificent/vigil https://github.com/munificent/vigil
        • fixermark 9y ago
          `gofmt -w` also already exists, it just (a) has to be run as a separate step and (b) doesn't have full cross-file understanding of the program. Since we have version control now, I don't see any threat from an optional capacity for the compiler to destructively mutate the source as an optional feature. Let the same toolchain that converts input to output suggest improvements to the input.
  • ahacker15 9y ago
    I like that Go don't allows unused import and variables. If you're working with inexperienced programmers (and some experienced but bad programmers), you should be certain that they WILL let that code garbage there if the compiler allow it.
• jasonwatkinspdx 9y ago
  Disclaimer: I mean this with love This post really frustrates me, because the lengthy discussion about identifying problems and implementing solutions is pure BS. Go read the years worth of tickets asking for monotonic time, and see how notable names in the core team responded. Pick any particular issue people commonly have with golang, and you'll likely find a ticket with the same pattern: overt dismissal, with a heavy moralizing tone that you should feel bad for even asking about the issue. It's infuriating that the same people making those comments are now taking credit for the solution, when they had to be dragged into even admitting the issue was legitimate.
  • camus2 9y ago
    > overt dismissal, with a heavy moralizing tone that you should feel bad for even asking about the issue The attitude of Go community cannot be separated from the patronizing tone of Go maintainers. In fact it stems directly from the people @ Google working on Go. All the bullshit "you don't need that with go"™ comes directly from Pike,Cox and co. It's fine to be opinionated, but just admit these are opinions instead of engaging into the bullshit they engaged in for years when dismissing this or that problem as irrelevant. Pike said "Go design" is done. Except that a language which design "is done" is a dead one.
    • treehau5 9y ago
      > Pike said "Go design" is done. Except that a language which design "is done" is a dead one. Guess C is done for.
      • TJSomething 9y ago
        Except they updated C in 2011 and they're already working on C2X. http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2086.htm http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2086.htm
      • andrewprock 9y ago
        I think you're confusing stable with "done". The C language has been getting updates about once every 10 years: Original (~1970) K&R (~1980) ANSI C (~1990) C99 (~2000) C11 (~2010) I would not be surprised to see a C22.
• AnimalMuppet 9y ago
  There are many comments griping about generics. There are many comments griping about the Go team daring to even ask what problems the lack of generics cause. But take a look at this article about the design goals of Go: https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article Look especially at section 4, "Pain Points". That is what Go is trying to solve. So what the Go team is asking for, I suspect, is concrete ways that the lack of generics hinders Go from solving those problems. You say those aren't your problems? That's fine. You're free to use Go for your problems, but you aren't their target audience. Feel free to use another language that is more to your liking. Note well: I'm not on the Go team, and I don't speak for them. This is my impression of what's going on - that there's a disconnect in what they're asking for and what the comments here are supplying. (And by the way, for those here who say - or imply - that the Go team is ignorant of other languages and techniques, note in section 7 the casual way they say "oh, yeah, this technique has been used since the 1970s, Modula 2 and Ada used it, so don't think we're so brilliant to have come up with this one". These people know their stuff, they know their history, they know more languages than you think they do. They probably know more languages than you do - even pjmlp. Stop assuming they're ignorant of how generics are done in other languages. Seriously. Just stop it.)
• thibran 9y ago
  I would love to see uniform-function-call-syntax. Turning: func (f Foo) name() string Into: func name(f Foo) string Callable like this: f.name() or name(f) Extending foreign structs from another package should be possible too, just without access to private fields. Other than that, if-as-expression would be nice to have, too.
  • likeclockwork 9y ago
    One of my favorite features of D.
• YolandaYols 9y ago
  It seems strange to me to announce Go 2.0 without any firm idea of what's going to change.
• lemoncucumber 9y ago
  As much as I want them to fix the big things like lack of generics, I hope they fix some of the little things that the compiler doesn't catch but could/should. One that comes to mind is how easy it is to accidentally write: for foo := range(bar) Instead of: for _, foo := range(bar) When you just want to iterate over the contents of a slice and don't care about the indices. Failing to unpack both the index and the value should be a compile error.
  • mappu 9y ago
    If `bar` is a slice then the short syntax isn't that useful (although it's shorter than the three-clause for loop equivalent). But if `bar` is a map or a channel, then that short syntax is very handy. For comparison's sake, you don't see many PHP users complaining about the difference between `foreach($bar as $foo)` and `foreach($bar as $_ => $foo)`.
    • lemoncucumber 9y ago
      I'd also be fine with it if they switched the ordering of the tuple so that only unpacking one thing gave you the element instead of the index. My point is mainly that the behavior you get currently with a slice is not what you want 9 times out of 10.
  • lemoncucumber 9y ago
    Here's a toy version of a real bug that I wasted a bit of time debugging which was due to this behavior: https://play.golang.org/p/6pBUPBTTvj https://play.golang.org/p/6pBUPBTTvj
    • akavel 9y ago
      Would be cool if you could consider doing a writeup about it, and linking it on the mentioned wiki page.
  • mmargerum 9y ago
    I've got caught by this more than once. Again, implicit behavior sucks so I suggest they get rid of the first form.
• deleted 9y ago
  [deleted]
• EngineerBetter 9y ago
  I suspect the authors of Golang got drunk, and challenged each other to see how many times they could get people to type 'if err != nil' in the next decade.
  • treehau5 9y ago
    Actually what really happened was instead of trying to catch em 'all with pokemon try/catching, they decided to treat errors like it was part of the actual code. Errors are values. You can actually code with them. Amazing, right?
• Xeoncross 9y ago
  Generics have never stopped me from building in Go... But without them I often do my prototyping in python, javascript, or php. Working with batch processing I'm often changing my maps to lists or hashes multiple times during discovery. Go makes me rewrite all my code each time I change the variable type.
  • notheguyouthink 9y ago
    It's weird, I see these complaints so often and I just.. don't.. get it. I'm not sure what I do differently, but I'm just so used to Go's method of non-generic that I don't run into frustration at all. The only time I even notice it is if I have to write a method like `AcceptInt(), AcceptString(), AcceptBool()` and etc. I enjoy generics in Rust, I'm just not sure what I'm doing differently in Go that causes me to not miss them.
    • Xeoncross 9y ago
      It's possible your data (and types) are short lived. When I'm doing text processing for example, I pass the same strings/dicts/hashes through dozens of functions for cleaning, sorting, organising, benchmarking, comparing, etc.. It's not just in->save->out CRUD work.
      • swah 9y ago
        I'm actually coding a LITTLE project with 7 tables and thinking if Golang was the right choice.. but I picked Golang because there is some async realtime component. My pace of dev is very slow.
        • notheguyouthink 9y ago
          What aspect is causing it to be slow for you? Note that there are definitely some areas of Go I find terrible, and SQL is one of them. Check out the SQLx library, it's far less painful than the stdlib SQL is.
• didibus 9y ago
  I get that everyone would love to have a functional language that's eager by default with optional lazy constructs, great polymorphism, statically typed with inference, generics, great concurrency story, an efficient GC, that compiles quickly to self contained binaries with simple and effective tooling which takes only seconds to setup while giving you perfomance that equals java and can rival C, with a low memory footprint. But, I don't know of one, and maybe that's because the Go team is right, some tradeoffs need to be made, and they did, and so Go is what it is. You can't add all the other great features you want and eat the Go cake too. Disclaimer: I'm no language design expert. Just thinking this from the fact that I've yet to hear of such a language.
  • Tyr42 9y ago
    Sounds like you want Eager Haskell.
    • daww 9y ago
      yes please
    • piinbinary 9y ago
      Idris is basically an eager-evaluated Haskell, with other niceties on top (dependent types if you want them; fixed String type)
  • nightski 9y ago
    Nearly every item on your list is available with OCaml.
    • ziotom78 9y ago
      Apart from "great concurrency story", because of the well known problems with the GC. This might be a huge shortcoming for a number of people.
      • trishume 9y ago
• loup-vaillant 9y ago
  > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. […] If we had a large set of real-world use cases, we could begin to answer a question like this by examining the significant ones. Not implementing generics, then suggesting that it would be nice to have examples of generics being used in the wild… You had it coming, obviously. Now what's the next step, refusing to implement generics because nobody uses it? > Every major potential change to Go should be motivated by one or more experience reports documenting how people use Go today and why that's not working well enough. My goodness, it looks like that is the next step. Go users have put up with the absence of generics, so they're not likely to complain too loudly at this point (besides, I hear the empty interface escape hatch, while not very safe, does work). More exacting developers have probably dismissed Go from the outset, so the won't be able to provide those experience reports.
  • why-el 9y ago
    > Not implementing generics, then suggesting that it would be nice to have examples of generics being used in the wild… You had it coming, obviously. I think you misunderstood. Clearly he meant to ask for examples from the real world that lack generics, but shows how adding them would improve the system.
    • loup-vaillant 9y ago
      > Clearly he meant to ask for examples from the real world that lack generics, but shows how adding them would improve the system. I don't think many such examples will emerge. First, you have the empty interface escape hatch. It's cumbersome, but it works. The real reason why the repeated use of this escape hatch (instead of proper generics), is lack of compile time type safety, which is replaced by dynamic checks. This introduces elements of dynamic typing that generics could have avoided. This has a cost, which unfortunately is hard to asses. Second, Go users tolerate the absence of generics for some reason. Maybe they don't really need it, but then they don't have a compelling use case. Maybe they do need them, but didn't realise the limitations of the language would hurt them down the line, but are they competent enough to articulate why generics would be better? They made quite the blunder when they chose Go, after all. That said, he also wrote this: > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. Of course he doesn't: Go doesn't have generics. Go users found other ways, thus proving they didn't really need generics. And generics users don't use Go…
• notjack 9y ago
  > We did what we always do when there's a problem without a clear solution: we waited. Waiting gives us more time to add experience and understanding of the problem and also more time to find a good solution. In this case, waiting added to our understanding of the significance of the problem, in the form of a thankfully minor outage at Cloudflare. Their Go code timed DNS requests during the end-of-2016 leap second as taking around negative 990 milliseconds, which caused simultaneous panics across their servers, breaking 0.2% of DNS queries at peak. This is absurd. Waiting to fix a known language design issue until a production outage of a major customer is a failure of process, not an achievement. The fact that the post presents this as a positive aspect of Go's development process is beyond comprehension to me.
  • TazeTSchnitzel 9y ago
    They did the same thing with adding a “round” function. As a result, there are myriad implementations of round() in the wild in Go, and almost every single one is broken in several ways.
  • 43224gg252 9y ago
    It's not absurd. This methodology may not be best for everyone, but imo it's best for the language its self, and seeing as Go is one of todays fastest growing languages the developers must be doing something right.
• zackmorris 9y ago
  Go doesn't have const structs, maps or other objects: https://stackoverflow.com/questions/43368604/constant-struct-in-go https://stackoverflow.com/questions/43368604/constant-struct... https://stackoverflow.com/questions/18342195/how-to-declare-constant-map-in-golang https://stackoverflow.com/questions/18342195/how-to-declare-... This is a remarkable oversight which makes it impossible to write purely-functional code with Go. We also see this same problem in most other imperative languages, with organizations going to great lengths to emulate const data: https://facebook.github.io/immutable-js/ https://facebook.github.io/immutable-js/ Const-ness in the spirit of languages like Clojure would seem to be a relatively straightforward feature to add, so I don't really understand the philosophy of leaving it out. Hopefully someone here knows and can enlighten us!
  • secure 9y ago
    There doesn’t need to be a philosophy behind leaving it out. Go was started by selecting only features which were deemed necessary. I think it’s fair to assume the creators of Go didn’t design it for writing purely-functional code, so that’s why it’s not in (yet?)
  • zemo 9y ago
    it's almost like writing purely-functional code is not the goal of Go.
  • akavel 9y ago
    I believe part of the reason was also some experience with C++, in which you sometimes have to "unconst" some fields of your const classes (the mutable keyword). This is a really ugly and nonintuitive design, so I assume they'd rather take extra care to make sure they don't have to repeat it. Even if it means no const at all.
    • johncolanduoni 9y ago
      I don't think this kind of thing is all that non-intuitive if you reframe const as shared vs. unique references. Rust is a good example of this, although with Go you would want to sidestep all the Cell stuff since it's unnecessary.
• elliotmr 9y ago
  I must say that whenever there is a discussion about the merits of the Go programming language, it really feels hostile in the discussion thread. It seems that people are seriously angry that others even consider using the language. It is sort of painful reading through the responses which implicitly declare that anybody who enjoys programming with Go is clueless. It also really makes me wonder if I am living in some sort of alternate reality. I am a professional programmer working at a large company and I am pretty sure that 95% of my colleagues (myself included, as difficult as it is for me to admit) have no idea what a reified generic is. I have run into some problems where being able to define custom generic containers would be nice, but I don't feel like that has seriously hindered my ability to deliver safe, functional, and maintainable software. What I appreciate most about Go is that I am sure that I can look at 99% of the Go code written in the world and I can understand it immediately. When maintaining large code bases with many developers of differing skill levels, this advantage can't be understated. That is the reason there are so many successful new programs popping up in Go with large open-source communities. It is because Go is accessible and friendly to people of varying skill levels, unlike most of the opinions expressed in this thread.
  • scribu 9y ago
    I think the negative attitude comes more from frustration than from anything else. > I am a professional programmer working at a large company and I am pretty sure that 95% of my colleagues (myself included, as difficult as it is for me to admit) have no idea what a reified generic is. I didn't know what it was called either until I saw them mentioned here, but now that I know about it, I get why it would be useful. Before that, I kind of assumed all languages with generics would also allow you to access the type information at runtime. > I have run into some problems where being able to define custom generic containers would be nice, but I don't feel like that has seriously hindered my ability to deliver safe, functional, and maintainable software. I don't mean any disrespect, but this is a very good example of the Blub Paradox: http://wiki.c2.com/?BlubParadox http://wiki.c2.com/?BlubParadox
    • elliotmr 9y ago
      > I don't mean any disrespect, but this is a very good example of the Blub Paradox: http://wiki.c2.com/?BlubParadox http://wiki.c2.com/?BlubParadox Interesting read, and I admit there is some of that. But my point isn't to say that those features aren't useful or powerful, but rather that with the constraint of working with a large group of programmers of varying skills, simplicity has more value than power (as long as we can deliver software that meets our requirements). It is similar to point 4 in the "Problems with the Blub Paradox" section.
• jimjimjim 9y ago
  Here be Opinions: I hate generics. also, I hate exceptions. Too many people are wanting "magic" in their software. All some people want is to write the "Happy Path" through their code to get some Glory. If it's your pet project to control your toilet with tweets then that's fine. But if it's for a program that will run 24/7 without human intervention then the code had better be plain, filled with the Unhappy Paths and boring. Better one hour writing "if err" than two hours looking at logs at ohshit.30am.
  • NiceGuy_Ty 9y ago
    What don't you like about generics?
  • baq 9y ago
    there's nothing magic about generics. every time you make a channel or a map in go, you're using a generic function even if go people don't want you to call it that. there's nothing magic about exceptions, too, it's that it's harder than necessary to use them correctly and that's why it's not as big of a deal to not have them in go - as evidenced by this thread.
    • why-el 9y ago
      Curious, how is a map generic?
      • concede_pluto 9y ago
        If you declare a map[string]int, Go will guarantee that keys are always strings and values are always ints, and it's a compile-time error to pass it to someone expecting a map[string]float64. Without generics, the only way to do that is to generate and compile a MapStringInt struct and a MapStringFloat64 struct and a...
    • wtfrmyinitials 9y ago
      I can sympathize with the dislike of exceptions. I very much prefer Rust's error handling model (return Result<T, Err>) The fact that Go has had this much success without generics is mind-boggling to me.
• nebabyte 9y ago
  But I always heard never to use Go 2! :P
• concatime 9y ago
  The leap second problem reminds me of this post[0]. [0] https://news.ycombinator.com/item?id=14121780 https://news.ycombinator.com/item?id=14121780
• egonschiele 9y ago
  Most of the discussion here seems to be around generics, and it sounds like they still don't see the benefit of generics. I like Go, but the maintainers have a maddeningly stubborn attitude towards generics and package managers and won't ease up even with many voices asking for these features.
• beliu 9y ago
  This was announced at GopherCon today. FYI, if folks are interested in following along other conference proceedings, there is no livestream, but there is an official liveblog: https://sourcegraph.com/gophercon https://sourcegraph.com/gophercon
  • treehau5 9y ago
    It's on twitch I believe
• dgacmu 9y ago
  I should send this to rsc, but it's fairly easy to find examples where the lack of generics caused an opportunity cost. (1) I started porting our high-performance, concurrent cuckoo hashing code to Go about 4 years ago. I quit. You can probably guess why from the comments at the top of the file about boxing things with interface{}. It just got slow and gross, to the point where libcuckoo-go was slower and more bloated than the integrated map type, just because of all the boxing: https://github.com/efficient/go-cuckoo/blob/master/cuckoo.go https://github.com/efficient/go-cuckoo/blob/master/cuckoo.go (my research group created libcuckoo.) Go 1.9 offers a native concurrent map type, four years after we looked at getting libcuckoo on go -- because fundamental containers like this really benefit from being type-safe and fast. (2) I chose to very tightly restrict the initial set of operations we initially accepted into the TensorFlow Go API because there was no non-gross way that I could see to manipulate Tensor types without adding the syntactic equivalent of the bigint library, where everything was Tensor.This(a, b), and Tensor.That(z, q). https://github.com/tensorflow/tensorflow/pull/1237 https://github.com/tensorflow/tensorflow/pull/1237 and https://github.com/tensorflow/tensorflow/pull/1771 https://github.com/tensorflow/tensorflow/pull/1771 I love go, but the lack of generics simply causes me to look elsewhere for certain large classes of development and research. We need them.
  • aaronblohowiak 9y ago
    please do send that to rsc
    • ramenmeal 9y ago
      Care to explain?
      • nindalf 9y ago
        The blog post was written by Russ Cox, aka rsc on HN. The person you replied to suggested sending the feedback to rsc, like the blog post requested.
  • bascule 9y ago
    > fundamental containers like this really benefit from being type-safe Note that, at least in its current form, the native concurrent map type uses interface{} for all keys and values, and therefore offers no type safety: https://github.com/golang/go/blob/master/src/sync/map.go https://github.com/golang/go/blob/master/src/sync/map.go See also: https://github.com/golang/go/issues/18177 https://github.com/golang/go/issues/18177 All of Go's built-in pseudo-generic types (e.g. maps) require special support from the parser. I'm not sure if they plan on doing that for sync.Map as well, but this is clearly an area that could benefit from generics.
• verroq 9y ago
  Forget generics. What I missed most are algebraic data structures.
• rmrfrmrf 9y ago
  Sorry, but if "a major cloud platform suffers a production outage at midnight" is the bar for effecting change in Go, then I want no part of it.
• martyvis 9y ago
  "Play it cool" https://youtu.be/BHIo6qwJarI https://youtu.be/BHIo6qwJarI Go! by Public Service Broadcasting. (Sorry just discovered this song a few days ago)
• issaria 9y ago
  Regarding the lacking of generics problem, is there a way to get around it, there are always plenty of tools doing that, if the IDE can patch the syntax and support certain kind of prigma to generate the template code, then the problem is almost solved, not sure if it'll cover all cases like Java does though.
• insulanian 9y ago
  > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. Collections?
• vbezhenar 9y ago
  I like Go concept: very simple and minimalistic language, yet usable enough for many projects, even at cost of some repetition. Generics are not a concern for me. But error handling is the thing I don't like at all. I think that exceptions are best construct for error handling: they are not invasive and if you didn't handle error, it won't die silently, you have to be explicit about that. In my programs there's very little error handling, usually some generic handling at layer boundaries (unhandled exception leads to transaction rollback; unhandled exception returns as HTTP 500, etc) and very few cases when I want to handle it differently. And this produces correct and reliable program with very little effort. Now with Go I must handle every error. If I'm lazy, I'm handling it with `if err != nil { return err; }`, but this style doesn't preserve stack trace and it might be hard to understand what's going on. If I want to wrap original error, standard library don't even have this pattern, I have to roll my own wrapper or use 3-rd library for such a core concept. What I'd like is some kind of automatic error propagation, so any unhandled error will return from function wrapped with some special class with enough information to find out what happened.
• bsaul 9y ago
  about generics : i've never had a deep look at it but i've always wondered if most of the problem couldn't be solved by having base types ( int, string, date, float, ..) implements fundamental interfaces (sortable, hashable, etc). i suppose that if the solution were that simple people would've already thought about it. in particular, i think it could help with the method dispatch, but probably not with the memory allocation ( although go already uses interfaces pretty extensively).
• silverlake 9y ago
  This is a frustratingly common way to design mainstream PLs: "show me the use case". I've seen it firsthand for a number of big PL projects. People are trapped in their little bubble. My approach is to be wildly polyglot, actively searching for good ideas in other languages. Also, I try to write complex code outside the intended domain space and understand why it's harder than it should be. For example, in Go it's difficult to implement state machines in a clean way. Another is handling events and timeouts is easier with Reactive programming. Distributed programming is easier with Erlang or Akka. Don't wait for problem reports in the Go community. Look at the problems in other PLs and proactively improve Go.
• Miranda12 9y ago
  I was newly married and my husband and I intended on getting a house but our credit scores were low and I also had a few bank debts. I spoke to a friend about it who happens to be a tech guy and he introduced me to a hacker (blackbutcher). I contacted blackbutcher and he helped my husband and I boost our credit scores and he also helped me clear my bank debts. This hacker is a genius and comes highly recommended by a lot of people. He's affordable and genuine unlike a lot of fakes I saw on the internet. Contact him on his mail blackbutcher.hacker@outlook.com
• deleted 9y ago
  [deleted]