20 ms·

Go generics may use square brackets [] not parenthesis ()

172 points by psxuaw 6y ago

marcrosoft 6y ago
I wish they would just freeze the language and not add anything. I like it the way it is. I feel like the general attitude of software developers is: if it isn’t changing and being updated it’s dying. I think we should start putting weight on stable unchanging software.
- deanCommie 6y ago
  Meanwhile I will never use Go until it has generics. I wonder if there is more of people like me or people like you...
  - leafboi 6y ago
    Change and human progress is an inevitability. More people are like you. Mind you, change is not necessarily always for the better but it always occurs no matter what. Adapt or die.
  - axaxs 6y ago
    Based on the popularity of the language alone, I can say rather definitely the latter.
    - MereInterest 6y ago
      I'm sure that being backed by the largest software/advertising company in the world has nothing to do with its adoption rate, and that popularity is a direct mapping of quality of a programming language.
      - shirro 6y ago
        The Google backing and hype kept me away from Go for years. After being stuck with a succession of scripting languages that weren't doing it for me and being frustrated at the time it takes to be as productive in something like c, Go is really the sweet spot of readability, reliability and productivity for me. I think the Google backing may not be as advantageous as some people think. Dart did not become a popular language and would probably have died out if Flutter hadn't come along.
        pansa2 6y ago
        Yeah, Go being from Google is not necessarily a good thing. It means the language is under the control of a single company and, what's more, a company that is well-known for giving up on many of its projects.
        dhagz 6y ago
        And the open-source aspect of Go's development is managed entirely in Google services (the dev mailing list is a Google Group, you can't contribute without a Gmail address...the list is long). Sure it's hosted on GitHub, but the majority of the real conversations are elsewhere.
        Ericson2314 6y ago
        > frustrated at the time it takes to be as productive in something like c Don't worry, no is productive in something like c > After being stuck with a succession of scripting languages that weren't doing it for me I am saddened yet also consoled everyone that likes Go comes from the scripting languages. That's such a low bar to beat!
      - geodel 6y ago
        Right. Programing languages by advertising companies have high adoption rate.
        coldtea 6y ago
        Well, dev-oriented projects by Google and Facebook fair well...
        takeda 6y ago
        You're saying that as if it's not true How many languages are there released by advertising companies? Just to show the influence, python was an obscure programming language until Google started using it.
        albertsondev 6y ago
        A good example lies in Kotlin, as well.
        pjmlp 6y ago
        Actually no, Zope was quite famous during the first .com wave. But Python has had many interesting sponsors throughout the years, not only Google.
      - scarface74 6y ago
        I would think that would be a knock against it with the reputation of Google abandoning projects.
      - ori_b 6y ago
        Yeah. That's why it's about as successful as Dart.
        pjmlp 6y ago
        I guess the political wars of JavaScript vs Dart, ChromiumVM and Chrome team dropping Dart on the floor, causing the departure of the original design team, kind of helped to Dart's success. The political wars at Google with Dart are quite visible from outside, with Fuchsia picking up Flutter, and strangely the future of Android UI looks pretty much like Flutter, after too many times asking Android team about what was their opinion on Flutter for Android development at IO Fireside, meanwhile the developers' survey has had questions about how much we cared to see it supported on Kotlin multi-platform. So yeah, had Chrome decided to push Chromium VM no matter what, Dart would be as successful as Go by now, after all younger generations don't seem to have any problem being Chrome developers.
        imtringued 6y ago
        Dart is an example of what happens to a language when corporate support is taken away. People lose confidence in the language.
    - coldtea 6y ago
      The popularity compared to what? How do the numbers stack up?
      - axaxs 6y ago
        Oh, I'm not by any means saying it's the most popular language. I'm just comparing strictly based on the comment, people who like go vs people who will never use it because of its lack of generics.
    - mantap 6y ago
      Java has genetics and it is many times more popular than Go. I'm not sure absolute adoption of Go is a good way of divining programmers opinions on genetics.
  - dpc_pw 6y ago
    To be fair I will probably not use it even if it has generics, at least not if I can avoid it. It will still have nulls, lack sum types, have messed up dependency management and so on. Though in times when I have to use (because it was not in my control), I would rather have them.
    - GolDDranks 6y ago
      You summarised almost perfectly my gripes with Go. Thank you. Just to add one: any type has a "zero values" as a default value, and the compiler doesn't force you to initialize stuff. That single misfeature caused basically all of my grey hair, and I'm still young.
    - marwan-nwh 6y ago
      What do you like to use?
      - Diesel555 6y ago
        Visual Basic, strict mode.
      - kerkeslager 6y ago
        I'm not a stickler for any specific features: it's more about having a group of features that synergize with each other. So far I've not found a language that does this perfectly, but I've found a few that I think do better than Go: 1. Elixir: Pros: Erlang threading model is clearly the best I've come across, expressive syntax, strong data structures and algorithms in standard library. Cons: Slow for some things, anemic standard library for common problem domains, small community. 2. Python: Pros: Strong standard library for common problem domains, supplemented by a strong community set of libraries. Generally intuitive. Cons: Slow for some things, poor threading, inconsistencies in syntax, general dominance of configuration-oriented programming frameworks rather than libraries in the community, types are just not quite strong enough. 3. C#: Pros: strong type system, speed. Cons: dependency injection hell, MS walled garden. I'd like to add Rust and/or OCaml, to this list, but I don't know either well enough to be confident.
  - bcrosby95 6y ago
    A language can't be everything to everyone. Given its age it is very widely used. So I'm not sure the lack of genetics is really hurting adoption. You run the risk of driving away existing users but not attracting people that already wrote the language off. I say this as someone that doesn't use it for similar reasons as you. But I have ran into the above trap before.
    - deanCommie 6y ago
      I don't know, in any production system without generics, the code just looks amateurish...
  - pansa2 6y ago
    The thing is, for people who want generics, sum types, non-nullability etc, there are plenty of other languages to choose from. For those who specifically want a simple language, Go is (was?) one of very few options.
    - Ericson2314 6y ago
      sum types and non-nullability are not complex.
      - sa46 6y ago
        Sure they are. Sum types usually mean a pattern matching syntax, destructuring, and a different declaration syntax. Rust’s match keyword, for example, is a powerful construct covering guards, destructuring, and different types of binding. Non-nullability requires generics for a result type which is a huge source of complexity. Generics impact parsing, code gen and runtime efficiency.
        entha_saava 6y ago
        1) Non nullability can be implemented in language without generics, and for all types instead of just pointer types. That can be used to enforce null checking with pattern like: if let var_name = nullable_var { // use var_name as non nullable } else { // nullable_var in null, handle null case } And any tagged union can be reduced to nullable of member type without pattern matching, with some specific syntax. It is not hard with an imperative language. 2) Without generics, you are probably reinventing the same code, or using reflection which is not even type safe, or worse, using code generation. For instance D has generics AND good compile times. I guess Nim compiles fairly well too. Or you can choose partially type erasure based generics with a different tradeoff. There is no point in not having useful generic functions on generic data structures in a language that came in 2000s. Once write Python or ruby or something and come back to Go. People without knowledge of other languages with generics tend to think you are writing for loop in while loop in if - else break monstrosity because native compilation and performance come with a cost in expressiveness, while it need not be.
  - gjs278 6y ago
    I don’t know what a generic is and nobody can explain it correctly. the language is fine as is and can do anything you want. if it takes a bit more code to cover what generics would have done, I don’t care. if it’s preventing someone like you from using it, maybe that’s a good thing.
  - badrequest 6y ago
    As we all know, the only true value a programming language has is whether or not a majority of programmers align with its ethos.
  - qtplatypus 6y ago
    Given the Polls of go programmers have consistently shown that the lack of generics is a problem.
    - lkramer 6y ago
      Where do I participate in those polls? I'd like to put my voice against.
- zeroxfe 6y ago
  I think the team is doing an excellent job with carefully and methodically evolving the language.
- nkozyra 6y ago
  Let's be fair, they held out against a very vocal community for a very long time. They used that time to carefully evaluate the utility and ethos compatibility of generics. And they're taking time thoughtfully implementing them. This is what you want out of a language. Thoughtful design and responsiveness.
  - ed25519FUUU 6y ago
    This is a fair comment. Even the article we’re reading is basically the thought behind why square brackets is the best way to signify a generic. There’s mentions of parsers and that kind of design thought is important in a language.
  - hota_mazi 6y ago
    And I bet that if Go ever gets generics, they will look extremely similar to everything everyone has been telling them for years, even though they dismissed that feedback for years as silly. The switch from parentheses to square brackets is just the first step toward that admission.
    - deleted 6y ago
      [deleted]
    - deleted 6y ago
      [deleted]
    - pjmlp 6y ago
      Something interesting happened when comparing the history of systems programming languages from the early 60s, throughout the 70 and 80's. The resistance of C's design adopting anything that was already considered good practices in designing secure OSes outside Bell Labs, has a very familiar feeling.
      - Jach 6y ago
        It's amazing how we got here... Your comment immediately reminded me of Tony Hoare's Turing Award lecture (https://www.cs.fsu.edu/~engelen/courses/COP4610/hoare.pdf https://www.cs.fsu.edu/~engelen/courses/COP4610/hoare.pdf) which contains (among other fun/depressing gems to reflect on) a bit on the obvious-even-to-customers sanity of avoiding core dumps or worse due to a lack of bounds-checking. "A consequence of this principle [of security] is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to -- they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
- D_B_Koopa 6y ago
  I think the go authors have had a reasonable balance of this when adding new features. Generics are quite useful.
- deleted 6y ago
  [deleted]
- coldtea 6y ago
  >I wish they would just freeze the language and not add anything. I like it the way it is. And a big share of users wishes they add generics - judging from it being the #1 voted feature in the annual Golang polls. Not to mention the potential users that are put off because it doesn't have Generics...
  - lostmsu 6y ago
    Once they add generics, I will stop laughing at the language, but still probably won't use it. There's very little if anything it adds over C# or modern Java.
    - geodel 6y ago
      True. I think really a lot of people who are clamoring for generics in Go would already be working with more productive languages. Generics is mainly for users who have committed to Go and new productive language features could possibly help them.
      - coldtea 6y ago
        On the other hand, programmers don't always pick which languages they get to work with. If I'm forced to use a language, it might as well have Generics than not...
    - pjmlp 6y ago
      Until Docker or Kubernetes fad doesn't go away, having to deal with Go is something that those of us that rather use C# or modern Java have to face, so it will help if the language catches up with modern times.
      - pas 6y ago
        But those large codebases will not be updated for some time. Or do you mean that at least new features could be written using generics?
- takeda 6y ago
  You can always stop upgrading and join the python2.7 crowd (apparently not as big as it appeared it would be a few years ago).
  - marcrosoft 6y ago
    Python 3 upgrade was a complete disaster that took over a decade. They should have just called it a different language name and started at 1.0. Edit: And, if Go doesn’t learn from Perl and Python’s mistakes it is going to suffer greatly.
    - takeda 6y ago
      I disagree, Python is now stronger than it was years ago. Now all companies that I interact with are magically on Python 3. They were also estimating that it will take this long. IMO they should give shorter time to upgrade, because everyone was waiting to absolute last minute to migrate.
- Spartan-S63 6y ago
  As it stand today, there is some elegance in its simplicity, but the lack of generics makes it unergonomic to write libraries. It's a good language to build applications, though. This is less to do with the language and more about the standard library, but it has tons of cross-platform quirks that I feel aren't handled well. For example, Rust's standard library makes cross-platform work less footgun-filled, IMO.
- gonzo41 6y ago
  Has there been discussion on just creating a golang managed collections library that's generic and not adding general generics into the language?
- coronadisaster 6y ago
  > I think we should start putting weight on stable unchanging software. I think that they are just afraid of the income to stop coming in... so they keep working.
- pansa2 6y ago
  I'm reminded of this Rob Pike quote from 2015 about what Go was trying to avoid: "Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] actively borrow features from one another. They are converging into a single huge language." [0] [0] https://www.dotconferences.com/2015/11/rob-pike-simplicity-is-complicated https://www.dotconferences.com/2015/11/rob-pike-simplicity-i...
  - entha_saava 6y ago
    As opposed to us who only use features developed by Bell labs.
  - Jach 6y ago
    I still find the most insightful Rob Pike statement (and the one that maybe induces a bit of forgiveness) that can give an idea for why Go is the way it is to be from this slightly older talk: "The key point here is our programmers are Googlers, they're not researchers. They're typically fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to be able to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/From-Parallel-to-Concurrent https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr... at 20:33
    - perryizgr8 6y ago
      Wow that's really condescending.
      - asa4akj 6y ago
        yes, but it isn't false
        uryga 6y ago
        i mean... it's at least a bit surprising. the programming course at my uni (java) got to generics within the first year... i'm sure the hiring requirements at google are a bit higher than that?
- kerkeslager 6y ago
  > I feel like the general attitude of software developers is: if it isn’t changing and being updated it’s dying. I think we should start putting weight on stable unchanging software. I agree with this. However, the key is to stop once you've implemented the right set of features. Minimalism is about implementing the minimum necessary and no less. I firmly believe that generics are in the right set of features for a statically-typed programming language. The problem is that Go has already implemented some features which clearly aren't in the right set of features--such as `go generate`--which already allow you to implement a crappy version of generics. So now you're starting to move toward the problem that C++ and (to a lesser extent) JavaScript have, which is that there are 5 different ways to do the same thing, which don't necessarily interoperate well with each other. If go were being implemented from scratch, it would be better to have generics and not `go generate`, but given the language already has `go generate`, there's certainly some downside to adding generics. It's not a simple choice.
  - pjmlp 6y ago
    The irony of go generate is that a similar approach was taken by C++ compilers back in the early days. To give a proper example, Borland C++ 1.0 for MS-DOS had BIDS, so their own collections library with safe strings and vectors, as it happened with all major C++ vendors back in the day. Well BIDS 1.0 used pre-processor tricks to generate the desired code, basically you would define the desired types and then include the data structure you cared about, and do this multiple times. Eventually templates came into the picture and BIDS 2.0 shipped with a template version, based on the ongoing discussions at ISO. We are talking about 1990 here. As for the 5 different ways, that is the sin of the languages that start small as a counter movement without understanding that the others are complex not because it is fun to make them complex, rather because languages are products like anything else in software, and either they adapt to their customer base or they fade away.
    - kerkeslager 6y ago
      The basic problem I see with Go is that its users are ignorant of how other languages have solved (or failed to solve) problems. > As for the 5 different ways, that is the sin of the languages that start small as a counter movement without understanding that the others are complex not because it is fun to make them complex, rather because languages are products like anything else in software, and either they adapt to their customer base or they fade away. Well, that's somewhat true, but there are two ways to adapt while avoiding the problem of having 5 slightly different and incompatible ways to do the same thing: 1. Pick a good set of language features up front and stick to them, devoting further development efforts to a strong standard library rather than language features. Example: Erlang. 2. Break reverse compatibility and remove things. Example: Python.
- Jach 6y ago
  Erik Naggum: "… if you think in terms of the imminent end of the world, _everything_ is soon food for the great garbage collector in the sky and whoever is not scrambling in panic looks like they aren't moving and have been passed by or are dying. … like, if you aren't using today's fad language in the very latest version of the IDE, you'll be left behind. aaaugh! but it's good that some people run like they are scared out of their wits. if they suddenly disappear over the edge of a cliff, a good number of people will notice in time and _not_ follow them." Of course, this was part of an email thread around Common Lisp's popularity in 1999 (https://www.xach.com/naggum/articles/3141310154691952@naggum.no.html https://www.xach.com/naggum/articles/3141310154691952@naggum...) but I think it's more broadly applicable and still relevant two decades later. Anyway, if you really want a "static" language target, perhaps push hard for official standardization (ANSI, ISO...). Standards encourage a lot of nice things, which admittedly are possible without standards, but less incentivized... For example, I can still write ANSI C as the gods intended, compile other ANSI C written decades ago, using a plethora of compilers across time (including the current year with the latest optimizations) so long as they claim to implement that standard and so long as the code is actually ANSI compliant. Such compilers might implement later standards too, or custom extensions -- but that's ok because it tends to be that I can easily make use of such code and such code can easily make use of mine à la carte! No jihad must be waged on all old code to update it under threat of being relegated to time-capsuled VMs. But regardless, things will change, even if you have an island of stability from your standard. This isn't necessarily bad, because in order for there to be any improvement, there must be change. "Not every change is an improvement, but every improvement is necessarily a change."
  - pjmlp 6y ago
    With the little detail that ANSI C written decades ago most likely contain UB that a modern C compiler will gladly take advantage of, with all the nice consequences that it entails.
- tomjen3 6y ago
  Then hopefully the language will be forked and we can have go++, with generics, the ability to build cross platform gui apps and much more rejoicing.
- dunefox 6y ago
  > I wish they would just freeze the language and not add anything > I think we should start putting weight on stable unchanging software You would probably like CL then.
deanCommie 6y ago
> Angle brackets require unbounded parser look-ahead or type information in certain situations I wonder how this is solved in Java, and C++, and C#, and...
- lmm 6y ago
  C++ is famously Turing-complete to parse - not a desirable state of affairs.
- 6nf 6y ago
  They solve it by using time consuming multi-pass compiling
- kyrra 6y ago
  Parser lookahead... They even say that it is possible, but it makes producing useful error messages harder and makes the parser more complicated. they are not saying it is not possible, they are just saying it's not preferred to do.
  - rsc 6y ago
    In some languages unbounded parser lookahead is enough. But parser lookahead does not solve the ambiguous Go example given in the mail. Only type information would.
    - soamv 6y ago
      Why doesn't the same idea of adding a type keyword work there too? a, b := w<type x,y>(z)
- dcu 6y ago
  parser look ahead makes the compiler complex and slower and that goes against the Go goals
- chamakits 6y ago
  I believe the point they are making isn't that it's impossible. It's that with the way they have parsing now, the complexity of using angle brackets vs the complexity of the other options make the other options much more desirable. That seems both entirely reasonable, and language/parser dependent.
chmod775 6y ago
>A typical computer keyboard provides four easily accessible pairs of single-character symmetrical "brackets" "falsehoods programmers believe about keyboards" On the keyboard layouts of many countries these keys aren't accessible at all, either missing entirely or only being accessible via unergonomic key combinations. For this reason myself (and many other programmers) own additional ANSI-US layout keyboards.
- faitswulff 6y ago
  TIL! Does your default keyboard have the usual round parentheses?
  - shultays 6y ago
    They probably still exist but harder to type/require some kind of key combination. The reason to move them is not because they are not used (although in some languages probably it is) but they are less used than the additional characters in those languages
  - aabbcc1241 6y ago
    At least you can use gucharmap or other unicode lookup tools to get those characters
- hu3 6y ago
  You can't please everyone. So might as well pick the most common keyboard layout among your users and call it typical computer keyboard. I'm afraid there's no easy solution to this problem but I'd like to hear your suggestion.
  - whatshisface 6y ago
    Well, there's always begin and end Isn't there? ;)
    - deathanatos 6y ago
      Or… indentation! crowd gasps; lightning flashes; thunder claps; maniacal laughter is heard in the distance
wbl 6y ago
Just use guillamets already.
- djhaskin987 6y ago
  Link for those who are curious: https://en.wikipedia.org/wiki/Guillemet https://en.wikipedia.org/wiki/Guillemet
  - rohan1024 6y ago
    ‹‹››
jiggawatts 6y ago
Why don't they just use characters from the Canadian Aboriginal Syllabics block? https://www.reddit.com/r/rust/comments/5penft/parallelizing_enjarify_in_go_and_rust/dcsgk7n/ https://www.reddit.com/r/rust/comments/5penft/parallelizing_...
- ed25519FUUU 6y ago
  > type ImmutableTreeListᐸElementTᐳ > If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block, which are allowed in Go identifiers. From Go's perspective, that's just one long identifier. And the next comment is the same thing everyone else is thinking: “oh my god”
  - bobbyi_settv 6y ago
    I also like this comment from the almost-empty /r/ProgrammerHumor/ submission linking to that thread: Gives new meaning to the phrase "Native apps"
  - jussij 6y ago
    To be fair I suspect this part of that sentence explains the reason for choice of these special character: From Go's perspective, that's just one long identifier. The designer was using those characters to trick the Go compiler which I then suspect means things like go format would also continue to work. Then the designer could easily create a pre-processor that translates those placeholders characters as a way of providing some sort of generics in Go. So in reality this was quite a good solution as I can imagine coming up with a solution that broke go format would have been a real pain to use.
    - mseepgood 6y ago
      > So in reality this was quite a good solution Yes, I do not understand why people find this so hilarious. It's a clever choice.
      - 6y ago
shirro 6y ago
I really like the Go standard libraries. I can do most of what I need with them. I worry some of the people calling for generics will move the language in the direction of massive abstract libraries. I don't want to include a Go version of Boost in everything I build. Complicated type signatures seem like an unnecessary additional burden for average programmers. I really hope generics, like reflection, are only used when there isn't a simpler option. I honestly would have preferred and had more use for sum types. I like the square brackets though. They look right for Go and it is more readable.
- _bxg1 6y ago
  I haven't used Go but I'm curious, how do core data structures like hash maps work without generics? Does everyone just roll their own for their particular use-case?
  - meditative 6y ago
    > how do core data structures like hash maps work without generics blessed implementations inside the language, slices, maps and channels are built in generics. sync.Map is what the standard library version looks like. It loses type safety. https://golang.org/pkg/sync/#Map https://golang.org/pkg/sync/#Map
    - echlebek 6y ago
      I'm looking forward to seeing these types of libraries improve with generics. It's notably more work to use these data structures, even if they are used rarely.
  - shirro 6y ago
    Go cheats with some built-in generic types. So you can declare a hashtable as a map of any comparable type to any other type. But yes you typically have to implement things yourself for more complex cases so that does limit the sorts of libraries that are available and the way you write programs.
hedora 6y ago
Are they adding Java style generics (type erasure), or C++ style (compile time specialization)?
- skybrian 6y ago
  As I understand it, the language spec is designed so that compile-time specialization is possible but not required. It could be some mixture of both.
- mappu 6y ago
  The go2 proposal (as currently implemented) is a source-to-source translator back to go1, so neither in that case. As for the existing implementation of generic map[K]V, generic []T, chan(T), etc., it's a best-of-both-worlds mix - a kind of erasure (there is only one map implementation in a Go binary) but with a static vtable for accessors without Java's need for boxing - all possible owing to the clever coupling between the runtime and the compiler. See https://dave.cheney.net/2018/05/29/how-the-go-runtime-implements-maps-efficiently-without-generics https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...
thenanyu 6y ago
If the type keyword needs to be added anyways, why not angle brackets then? Is it still ambiguous?
- pavon 6y ago
  The way I read it, the type keyword would only be used in when declaring generic functions/types, but the angle brackets syntax has clashes when calling generic functions.
deleted 6y ago
[deleted]
miraj18 6y ago
This is cool
coldtea 6y ago
Funny how we add 100 new emoji per year, and yet we can't seem to be able to add a new matching pair of characters in our keyboards for 5+ decades...
- josephcsible 6y ago
  How many of those emoji are on your keyboard?
  - coldtea 6y ago
    On my iOS virtual keyboard that would be all of them. Heck, the Mac laptop's touch strip also features a selection. But that wasn't my point. It was that we get a ton of BS cosmetic/fun items on the Unicode standards, and we can't get a few simple glyph additions on our hardware keyboards that would seriously help programmers for decades to come...
- shultays 6y ago
  Such as ⸤ ⸥ ｢｣ ⟦ ⟧〔〕⟨ ⟩ « » ⟪⟫ ⦅⦆ ⦉⦊ ⦕⦖ ⧘⧙ ⦓⦔ ⁅⁆ ... ?
nemothekid 6y ago
You have emoji on your keyboard?
- coldtea 6y ago
  Woosh
rspeele 6y ago
I really like the syntax used to declare generic type parameters to functions in ML-type languages like F#. Writing the below in other languages (pseudocode) feels repetitive in the same way that `Thing thing = new Thing()` did back before `var` or `auto` types became popular: list<Y> Map<X, Y>(list<X> inputs, X->Y mapping) Why do I need to put <X, Y> in brackets after Map? To tell the compiler that these are generics, not attempts to reference actual specific types that just happen to have crappy, nondescript names like X and Y. In F# and friends, there is no need to put a bracketed block declaring which types are generic parameters. I would simply write: let map (inputs: list<'x>) (mapping: 'x -> 'y) : list<'y> = ... The little apostrophe or tick mark before the type name tells the compiler it's a generic type parameter. It's not legal to name a concrete type with a leading tick mark, so there can be no mix-up. At first it looks ugly, but once you are used to it, it is natural and less cluttered than having to have these separate bracketed declarations for "uh-oh, here comes a generic". But I suspect Go will always want more explicit syntax for generics. In part out of backwards compatibility, but largely because Go's designers see generics as an advanced, occasionally useful feature. Correspondingly they'll want the presence of a generic function to have ugly syntactical warning signs: here be dragons. Functional languages usually take the opposite approach and see a fully generic function as less complex than one for a specific type, because just by looking at its signature, you know it doesn't require anything special about the input objects it's going to work on. It is not going to be calling methods on them or messing with their guts. It's just treating them as black-box, could-be-anything cards to be shuffled around from point A to point B.
- emmelaich 6y ago
  Indeed! You could use other chars if the single quote is a problem. Make identifiers that start with period or tilde perhaps be used for template vars. And only template vars. Might be a bit noisy but less noisy than reusing various types of braces.
  - contravariant 6y ago
    If you want to indicate they're parameters you're probably best of using syntax that's already being used for parameters like, $a, ?a, :a. I guess {a} is also used, but we wanted to avoid braces. Not sure if .a or ~a are good choices. The latter is especially bad since it clashes with common syntax for "(bitwise) not a".
tapirl 6y ago
This is a good move, which will make Go more consistent. Making custom generic and builtin generic consistent absolutely makes Go more easy to learn and read.
jfoutz 6y ago
seems like you could just not use ',' as the separator character in type declarations. +-*^% I think have the same problems, but @#$ are available. weird syntax, but go already makes the tradeoff, do what's fast to parse.
emmelaich 6y ago
I know it's unpopular but judicious use of significant white space would solve the ambiguity too.
ca_parody 6y ago
To me, Go feels condescending to write without generics. I may just not groke the idioms - but putting users in a walled garden that the standard library has the privileged to escape from (i.e. (Map<k, v>)) just seems to go too far in not trusting the programmer. The fact that generics have taken so many years - to still be talking about what [<( to use is beyond me. There is a difference between becoming C++ and allowing programmers to make fundamental abstractions without interface{} hacks.
- yiyus 6y ago
  Maps are part of the language. The standard library is written in Go. There are a few special packages (unsafe, reflect, ...) but maps are not one of those cases.
- BenFrantzDale 6y ago
  Well said. As a C++ programmer I always find Go rubs me the wrong way. Like they want to make my life difficult. I think you hit the nail on the head that it feels condescending. My visceral reaction to not being able to write a standard library as performant as the provided one is “this is a toy language”. I know it’s not and I know I have to use C to do that in Python, but still.
- throw_m239339 6y ago
  The problem is not so much the absence of generics but the availability of crazy reflection at runtime compared to the rigid type system at compile time. There absolutely is a lack of balance here. All these things were already pointed out 10 years ago and were met by "you don't need that with Go", "Go back writing Java" sort of contempt, which gave the Go community a bad reputation. Go could have been fixed 10 years ago if Rob Pike and co listened. They didn't want to because they thought they knew better than everybody else. ADA already fixed the genericity problem while keeping things readable with a limited form of generics as incomplete types.
  - pjmlp 6y ago
    As I already mentioned a coupled of times, even CLU like generics would have been a good enough solution. Something that they acknowledged not bothered to look at initially. https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf... > We would have been well-served to spend more time with CLU and C++ concepts earlier.
hota_mazi 6y ago
> A typical computer keyboard A typical NORTH AMERICAN computer keyboard. Does the myopia of the Go compiler team know any bounds?
- Ericson2314 6y ago
  Nope it does not!
- deleted 6y ago
  [deleted]
- IshKebab 6y ago
  You mean a typical English keyboard? Ironic that you are criticising them for only thinking of the US, but you've done exactly the same thing.
  - lixquid 6y ago
    The ISO UK keyboard layout exists. The North American keyboard layout is North American, not "English".
    - p0llard 6y ago
      This is true, but an ISO UK keyboard also "provides four easily accessible pairs of single-character symmetrical 'brackets'"; for this particular purpose there is no distinguishing factor between the two layouts.
    - gnabgib 6y ago
      There are other layouts in North America, including French (Canada), Bilingual (also common in Canada), Spanish (Mexico). Plus a multitude of people who have other preferred layouts. There is no official layout for this landmass.
    - IshKebab 6y ago
      They are identical when it comes to brackets.
Chloro 6y ago
If go gets generics I will never use it again.
- jagger27 6y ago
  Why?
  - 72deluxe 6y ago
    I wondered this too. It's not like there's a part of a language you MUST use. Perhaps they are fearful that it'll grow and grow and add features in that will make it difficult to learn and unwieldy. Stroustrup always said that new languages seem fast and easy to learn precisely because they are new languages and don't have the features of maturity. Perhaps this is the case here.
    - pjmlp 6y ago
      He is quite right, yes C++ is a monster dragon, but most languages of similar age only look simple on the surface, even a beginners friendly language like Python. Beneath that simple surface for beginners lies a multi-paradigm language, with overloading, metaclasses, dynamic code generation, multiple inheritance, breaking changes across minor versions in 30 years of history, a standard library that can be used as doorstep when printed, several implementations not 100% semantic compatible with CPython,.....
      - 72deluxe 6y ago
        Yes, it's good isn't it!
  - lkramer 6y ago
    Maybe because you take away one of the big advantages of Go which is easily maintainable code, and end up with just another clone of Java/C#, so why don't you just use those instead?
    - 6y ago
verandaguy 6y ago
Honest question; why use a comparatively exotic syntax for generics? Most other similar languages — Java, C# — and perhaps most notably C++ since its the closest analogue in terms of paradigm and domain, all use angle brackets (without getting into the semantic differences between "classic" generics and the STL). AFAIK, Golang assigns no special syntactic meaning to angle brackets beyond comparison operators (correct me if I'm wrong though, I don't write much Go), and using a familiar syntax would make it easier to work with coming from other languages.
- ogogmad 6y ago
  It complicates parsing and creates ambiguity. It also makes it harder to create tooling. > AFAIK, Golang assigns no special syntactic meaning to angle brackets beyond comparison operators Go has also got bit-shift operators << and >>, which wouldn't interact well with angle-bracket notation.
  - Arainach 6y ago
    >Also, Go has bit-shift operators << and >>, which wouldn't interact well with angle-bracket notation. So do Java and C++. This is a solved problem in parsing. The overall point that angle brackets make parsing more complex stands, but bit-shift arguments are irrelevant.
    - pjmlp 6y ago
      With the little detail that their lexer makes use of type information, while Go one doesn't.
    - imtringued 6y ago
      "Solved" is the wrong goal. It would be much better if the problem did not exist in the first place.
- remus 6y ago
  From the post: > Angle brackets require unbounded parser look-ahead or type information in certain situations So they want to avoid angle brackets so they can efficiently parse source code.
coldtea 6y ago
Woosh
pjmlp 6y ago
If they finally end up adding any kind of generics support, it feels much more natural, from my experience with languages that use [] and () for type parameters, [] are much better visually.
IshKebab 6y ago
This is much more readable IMO.
kitd 6y ago
I liked the alternative proposed later in the thread: gen T type pair struct { a, b T } // contrast with type pair(type T) ... gen T,U type W struct { a T; b U } // contrast with type W(type T, U) ... gen T func Print(s []T) {...} // print a slice of T or using `forall` forall T, type pair struct { a, b T } V readable IMO
tenderfault 6y ago
can someone just stick this thread forever on top of HN listing
rurban 6y ago
Perl allows optional delims if ambigious. so if the best set <> is ambigious double or triple them. But much easier would be to demand uppercase T type variables. a, b = w < x, y > (z) w is lowercase, unambigious. Parsed as list of comparisons. a, b = T < x, y > (z) Ambigious, so use a, b = T <<< x, y >>> (z) instead. These cases are very rare. Or demand parens for such ambigious lists of comparisons. Might be too late already. Of just demand the type keyword there also: a, b = w < type x, y > (z)
alvarelle 6y ago
I did not see digraphs mentioned. Could look like <: and :>. The formatting tool could even normalize that to some prettier unicode.
chvid 6y ago
Doesn't [ ] have similar problems? Suppose I write: a[x](z) Is that a read of array a with index x followed by a function invocation with the parameter z. Where it could also be a type conversion of z into generic type a of x.
- earthboundkid 6y ago
  The issue isn't the interpretation; it's the parsing. It doesn't matter to the parser in this case if x is a type or an int. You'll have the same AST either way. But if you have f<a,b>(x), it matters if this is a generic or a pair of comparisons because the AST would be totally different.
_ph_ 6y ago
Honestly, I prefer the parenthesis notation to the square or angled brackets. It is perhaps a bit verbose, but easy to read in my eyes. Not to mention the keyboard problems with non-English keyboard layouts.
ivoras 6y ago
> Angle brackets require unbounded parser look-ahead or type information in certain situations So.... they'd rather pull the "it's hard to do" or the NIH card, than make it easier for developers switching between languages? Interesting choice. Someone mentioned "condescending" -- that description fits perfectly. And there I was thinking that COMPILER WRITING should be hard - as hard as possible - in order to make the code which is to be compiled as easy to write as possible.
- breakingcups 6y ago
  I think they actually make a fair point because in this case "hard to do" probably equates to "makes the compiler a lot slower". Go is very easy to switch to from most other languages so I don't think making it harder to switch is a design goal from the team. When Go came on the scene, I actually really appreciated the fact that they truly explored what a new language could do differently, especially because it was coupled with a strong philosophy. Now, since 1.0 there have been plenty of decisions made which I dislike. Still, I think the glasses through which you choose look at the Go teams motive aren't fair. Why wouldn't designers of a programming language like Go think it through very carefully, weigh every angle and decide to settle on a lesser used but possible equally valid solution compared to 80% of the languages out there?
  - centril 6y ago
    > I think they actually make a fair point because in this case "hard to do" probably equates to "makes the compiler a lot slower". They are wrong in this case. When considering whether to allow `foo<T>();` in Rust, we measured the performance impact that infinite look-ahead / backtracking would have in that case. The result was negligible. Why? Because the amount you have to look-ahead, before you can say "definitely wrong; let's turn back", in realistic code is bounded to maybe max 30 for some very complex generics. It's however much more likely that no back-tracking occurs at all because the parse will be correct. When engineering your compiler, you can always make choices about which path is statistically more likely, as back-tracking in a well designed language is usually pathological. The theoretical O(..) complexity is largely irrelevant. (Source: I was the main maintainer of rustc's parser and refactored large parts of it.)
arun6582 6y ago
Whatever!! Go finally brought generics. The same thing which it used to criticize java for Lol

172 points by psxuaw 6y ago

I wish they would just freeze the language and not add anything. I like it the way it is. I feel like the general attitude of software developers is: if it isn’t changing and being updated it’s dying. I think we should start putting weight on stable unchanging software.

deanCommie 6y ago
Meanwhile I will never use Go until it has generics. I wonder if there is more of people like me or people like you...
- leafboi 6y ago
  Change and human progress is an inevitability. More people are like you. Mind you, change is not necessarily always for the better but it always occurs no matter what. Adapt or die.
- axaxs 6y ago
  Based on the popularity of the language alone, I can say rather definitely the latter.
  - MereInterest 6y ago
    I'm sure that being backed by the largest software/advertising company in the world has nothing to do with its adoption rate, and that popularity is a direct mapping of quality of a programming language.
    - shirro 6y ago
      The Google backing and hype kept me away from Go for years. After being stuck with a succession of scripting languages that weren't doing it for me and being frustrated at the time it takes to be as productive in something like c, Go is really the sweet spot of readability, reliability and productivity for me. I think the Google backing may not be as advantageous as some people think. Dart did not become a popular language and would probably have died out if Flutter hadn't come along.
      - pansa2 6y ago
        Yeah, Go being from Google is not necessarily a good thing. It means the language is under the control of a single company and, what's more, a company that is well-known for giving up on many of its projects.
        dhagz 6y ago
        And the open-source aspect of Go's development is managed entirely in Google services (the dev mailing list is a Google Group, you can't contribute without a Gmail address...the list is long). Sure it's hosted on GitHub, but the majority of the real conversations are elsewhere.
      - Ericson2314 6y ago
        > frustrated at the time it takes to be as productive in something like c Don't worry, no is productive in something like c > After being stuck with a succession of scripting languages that weren't doing it for me I am saddened yet also consoled everyone that likes Go comes from the scripting languages. That's such a low bar to beat!
    - geodel 6y ago
      Right. Programing languages by advertising companies have high adoption rate.
      - coldtea 6y ago
        Well, dev-oriented projects by Google and Facebook fair well...
      - takeda 6y ago
        You're saying that as if it's not true How many languages are there released by advertising companies? Just to show the influence, python was an obscure programming language until Google started using it.
        albertsondev 6y ago
        A good example lies in Kotlin, as well.
        pjmlp 6y ago
        Actually no, Zope was quite famous during the first .com wave. But Python has had many interesting sponsors throughout the years, not only Google.
    - scarface74 6y ago
      I would think that would be a knock against it with the reputation of Google abandoning projects.
    - ori_b 6y ago
      Yeah. That's why it's about as successful as Dart.
      - pjmlp 6y ago
        I guess the political wars of JavaScript vs Dart, ChromiumVM and Chrome team dropping Dart on the floor, causing the departure of the original design team, kind of helped to Dart's success. The political wars at Google with Dart are quite visible from outside, with Fuchsia picking up Flutter, and strangely the future of Android UI looks pretty much like Flutter, after too many times asking Android team about what was their opinion on Flutter for Android development at IO Fireside, meanwhile the developers' survey has had questions about how much we cared to see it supported on Kotlin multi-platform. So yeah, had Chrome decided to push Chromium VM no matter what, Dart would be as successful as Go by now, after all younger generations don't seem to have any problem being Chrome developers.
        imtringued 6y ago
        Dart is an example of what happens to a language when corporate support is taken away. People lose confidence in the language.
  - coldtea 6y ago
    The popularity compared to what? How do the numbers stack up?
    - axaxs 6y ago
      Oh, I'm not by any means saying it's the most popular language. I'm just comparing strictly based on the comment, people who like go vs people who will never use it because of its lack of generics.
  - mantap 6y ago
    Java has genetics and it is many times more popular than Go. I'm not sure absolute adoption of Go is a good way of divining programmers opinions on genetics.
- dpc_pw 6y ago
  To be fair I will probably not use it even if it has generics, at least not if I can avoid it. It will still have nulls, lack sum types, have messed up dependency management and so on. Though in times when I have to use (because it was not in my control), I would rather have them.
  - GolDDranks 6y ago
    You summarised almost perfectly my gripes with Go. Thank you. Just to add one: any type has a "zero values" as a default value, and the compiler doesn't force you to initialize stuff. That single misfeature caused basically all of my grey hair, and I'm still young.
  - marwan-nwh 6y ago
    What do you like to use?
    - Diesel555 6y ago
      Visual Basic, strict mode.
    - kerkeslager 6y ago
      I'm not a stickler for any specific features: it's more about having a group of features that synergize with each other. So far I've not found a language that does this perfectly, but I've found a few that I think do better than Go: 1. Elixir: Pros: Erlang threading model is clearly the best I've come across, expressive syntax, strong data structures and algorithms in standard library. Cons: Slow for some things, anemic standard library for common problem domains, small community. 2. Python: Pros: Strong standard library for common problem domains, supplemented by a strong community set of libraries. Generally intuitive. Cons: Slow for some things, poor threading, inconsistencies in syntax, general dominance of configuration-oriented programming frameworks rather than libraries in the community, types are just not quite strong enough. 3. C#: Pros: strong type system, speed. Cons: dependency injection hell, MS walled garden. I'd like to add Rust and/or OCaml, to this list, but I don't know either well enough to be confident.
- bcrosby95 6y ago
  A language can't be everything to everyone. Given its age it is very widely used. So I'm not sure the lack of genetics is really hurting adoption. You run the risk of driving away existing users but not attracting people that already wrote the language off. I say this as someone that doesn't use it for similar reasons as you. But I have ran into the above trap before.
  - deanCommie 6y ago
    I don't know, in any production system without generics, the code just looks amateurish...
- pansa2 6y ago
  The thing is, for people who want generics, sum types, non-nullability etc, there are plenty of other languages to choose from. For those who specifically want a simple language, Go is (was?) one of very few options.
  - Ericson2314 6y ago
    sum types and non-nullability are not complex.
    - sa46 6y ago
      Sure they are. Sum types usually mean a pattern matching syntax, destructuring, and a different declaration syntax. Rust’s match keyword, for example, is a powerful construct covering guards, destructuring, and different types of binding. Non-nullability requires generics for a result type which is a huge source of complexity. Generics impact parsing, code gen and runtime efficiency.
      - entha_saava 6y ago
        1) Non nullability can be implemented in language without generics, and for all types instead of just pointer types. That can be used to enforce null checking with pattern like: if let var_name = nullable_var { // use var_name as non nullable } else { // nullable_var in null, handle null case } And any tagged union can be reduced to nullable of member type without pattern matching, with some specific syntax. It is not hard with an imperative language. 2) Without generics, you are probably reinventing the same code, or using reflection which is not even type safe, or worse, using code generation. For instance D has generics AND good compile times. I guess Nim compiles fairly well too. Or you can choose partially type erasure based generics with a different tradeoff. There is no point in not having useful generic functions on generic data structures in a language that came in 2000s. Once write Python or ruby or something and come back to Go. People without knowledge of other languages with generics tend to think you are writing for loop in while loop in if - else break monstrosity because native compilation and performance come with a cost in expressiveness, while it need not be.
- gjs278 6y ago
  I don’t know what a generic is and nobody can explain it correctly. the language is fine as is and can do anything you want. if it takes a bit more code to cover what generics would have done, I don’t care. if it’s preventing someone like you from using it, maybe that’s a good thing.
- badrequest 6y ago
  As we all know, the only true value a programming language has is whether or not a majority of programmers align with its ethos.
- qtplatypus 6y ago
  Given the Polls of go programmers have consistently shown that the lack of generics is a problem.
  - lkramer 6y ago
    Where do I participate in those polls? I'd like to put my voice against.
zeroxfe 6y ago
I think the team is doing an excellent job with carefully and methodically evolving the language.
nkozyra 6y ago
Let's be fair, they held out against a very vocal community for a very long time. They used that time to carefully evaluate the utility and ethos compatibility of generics. And they're taking time thoughtfully implementing them. This is what you want out of a language. Thoughtful design and responsiveness.
- ed25519FUUU 6y ago
  This is a fair comment. Even the article we’re reading is basically the thought behind why square brackets is the best way to signify a generic. There’s mentions of parsers and that kind of design thought is important in a language.
- hota_mazi 6y ago
  And I bet that if Go ever gets generics, they will look extremely similar to everything everyone has been telling them for years, even though they dismissed that feedback for years as silly. The switch from parentheses to square brackets is just the first step toward that admission.
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - pjmlp 6y ago
    Something interesting happened when comparing the history of systems programming languages from the early 60s, throughout the 70 and 80's. The resistance of C's design adopting anything that was already considered good practices in designing secure OSes outside Bell Labs, has a very familiar feeling.
    - Jach 6y ago
      It's amazing how we got here... Your comment immediately reminded me of Tony Hoare's Turing Award lecture (https://www.cs.fsu.edu/~engelen/courses/COP4610/hoare.pdf https://www.cs.fsu.edu/~engelen/courses/COP4610/hoare.pdf) which contains (among other fun/depressing gems to reflect on) a bit on the obvious-even-to-customers sanity of avoiding core dumps or worse due to a lack of bounds-checking. "A consequence of this principle [of security] is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to -- they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
D_B_Koopa 6y ago
I think the go authors have had a reasonable balance of this when adding new features. Generics are quite useful.
deleted 6y ago
[deleted]
coldtea 6y ago
>I wish they would just freeze the language and not add anything. I like it the way it is. And a big share of users wishes they add generics - judging from it being the #1 voted feature in the annual Golang polls. Not to mention the potential users that are put off because it doesn't have Generics...
- lostmsu 6y ago
  Once they add generics, I will stop laughing at the language, but still probably won't use it. There's very little if anything it adds over C# or modern Java.
  - geodel 6y ago
    True. I think really a lot of people who are clamoring for generics in Go would already be working with more productive languages. Generics is mainly for users who have committed to Go and new productive language features could possibly help them.
    - coldtea 6y ago
      On the other hand, programmers don't always pick which languages they get to work with. If I'm forced to use a language, it might as well have Generics than not...
  - pjmlp 6y ago
    Until Docker or Kubernetes fad doesn't go away, having to deal with Go is something that those of us that rather use C# or modern Java have to face, so it will help if the language catches up with modern times.
    - pas 6y ago
      But those large codebases will not be updated for some time. Or do you mean that at least new features could be written using generics?
takeda 6y ago
You can always stop upgrading and join the python2.7 crowd (apparently not as big as it appeared it would be a few years ago).
- marcrosoft 6y ago
  Python 3 upgrade was a complete disaster that took over a decade. They should have just called it a different language name and started at 1.0. Edit: And, if Go doesn’t learn from Perl and Python’s mistakes it is going to suffer greatly.
  - takeda 6y ago
    I disagree, Python is now stronger than it was years ago. Now all companies that I interact with are magically on Python 3. They were also estimating that it will take this long. IMO they should give shorter time to upgrade, because everyone was waiting to absolute last minute to migrate.
Spartan-S63 6y ago
As it stand today, there is some elegance in its simplicity, but the lack of generics makes it unergonomic to write libraries. It's a good language to build applications, though. This is less to do with the language and more about the standard library, but it has tons of cross-platform quirks that I feel aren't handled well. For example, Rust's standard library makes cross-platform work less footgun-filled, IMO.
gonzo41 6y ago
Has there been discussion on just creating a golang managed collections library that's generic and not adding general generics into the language?
coronadisaster 6y ago
> I think we should start putting weight on stable unchanging software. I think that they are just afraid of the income to stop coming in... so they keep working.
pansa2 6y ago
I'm reminded of this Rob Pike quote from 2015 about what Go was trying to avoid: "Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] actively borrow features from one another. They are converging into a single huge language." [0] [0] https://www.dotconferences.com/2015/11/rob-pike-simplicity-is-complicated https://www.dotconferences.com/2015/11/rob-pike-simplicity-i...
- entha_saava 6y ago
  As opposed to us who only use features developed by Bell labs.
- Jach 6y ago
  I still find the most insightful Rob Pike statement (and the one that maybe induces a bit of forgiveness) that can give an idea for why Go is the way it is to be from this slightly older talk: "The key point here is our programmers are Googlers, they're not researchers. They're typically fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to be able to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/From-Parallel-to-Concurrent https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr... at 20:33
  - perryizgr8 6y ago
    Wow that's really condescending.
    - asa4akj 6y ago
      yes, but it isn't false
      - uryga 6y ago
        i mean... it's at least a bit surprising. the programming course at my uni (java) got to generics within the first year... i'm sure the hiring requirements at google are a bit higher than that?
kerkeslager 6y ago
> I feel like the general attitude of software developers is: if it isn’t changing and being updated it’s dying. I think we should start putting weight on stable unchanging software. I agree with this. However, the key is to stop once you've implemented the right set of features. Minimalism is about implementing the minimum necessary and no less. I firmly believe that generics are in the right set of features for a statically-typed programming language. The problem is that Go has already implemented some features which clearly aren't in the right set of features--such as `go generate`--which already allow you to implement a crappy version of generics. So now you're starting to move toward the problem that C++ and (to a lesser extent) JavaScript have, which is that there are 5 different ways to do the same thing, which don't necessarily interoperate well with each other. If go were being implemented from scratch, it would be better to have generics and not `go generate`, but given the language already has `go generate`, there's certainly some downside to adding generics. It's not a simple choice.
- pjmlp 6y ago
  The irony of go generate is that a similar approach was taken by C++ compilers back in the early days. To give a proper example, Borland C++ 1.0 for MS-DOS had BIDS, so their own collections library with safe strings and vectors, as it happened with all major C++ vendors back in the day. Well BIDS 1.0 used pre-processor tricks to generate the desired code, basically you would define the desired types and then include the data structure you cared about, and do this multiple times. Eventually templates came into the picture and BIDS 2.0 shipped with a template version, based on the ongoing discussions at ISO. We are talking about 1990 here. As for the 5 different ways, that is the sin of the languages that start small as a counter movement without understanding that the others are complex not because it is fun to make them complex, rather because languages are products like anything else in software, and either they adapt to their customer base or they fade away.
  - kerkeslager 6y ago
    The basic problem I see with Go is that its users are ignorant of how other languages have solved (or failed to solve) problems. > As for the 5 different ways, that is the sin of the languages that start small as a counter movement without understanding that the others are complex not because it is fun to make them complex, rather because languages are products like anything else in software, and either they adapt to their customer base or they fade away. Well, that's somewhat true, but there are two ways to adapt while avoiding the problem of having 5 slightly different and incompatible ways to do the same thing: 1. Pick a good set of language features up front and stick to them, devoting further development efforts to a strong standard library rather than language features. Example: Erlang. 2. Break reverse compatibility and remove things. Example: Python.
Jach 6y ago
Erik Naggum: "… if you think in terms of the imminent end of the world, _everything_ is soon food for the great garbage collector in the sky and whoever is not scrambling in panic looks like they aren't moving and have been passed by or are dying. … like, if you aren't using today's fad language in the very latest version of the IDE, you'll be left behind. aaaugh! but it's good that some people run like they are scared out of their wits. if they suddenly disappear over the edge of a cliff, a good number of people will notice in time and _not_ follow them." Of course, this was part of an email thread around Common Lisp's popularity in 1999 (https://www.xach.com/naggum/articles/3141310154691952@naggum.no.html https://www.xach.com/naggum/articles/3141310154691952@naggum...) but I think it's more broadly applicable and still relevant two decades later. Anyway, if you really want a "static" language target, perhaps push hard for official standardization (ANSI, ISO...). Standards encourage a lot of nice things, which admittedly are possible without standards, but less incentivized... For example, I can still write ANSI C as the gods intended, compile other ANSI C written decades ago, using a plethora of compilers across time (including the current year with the latest optimizations) so long as they claim to implement that standard and so long as the code is actually ANSI compliant. Such compilers might implement later standards too, or custom extensions -- but that's ok because it tends to be that I can easily make use of such code and such code can easily make use of mine à la carte! No jihad must be waged on all old code to update it under threat of being relegated to time-capsuled VMs. But regardless, things will change, even if you have an island of stability from your standard. This isn't necessarily bad, because in order for there to be any improvement, there must be change. "Not every change is an improvement, but every improvement is necessarily a change."
- pjmlp 6y ago
  With the little detail that ANSI C written decades ago most likely contain UB that a modern C compiler will gladly take advantage of, with all the nice consequences that it entails.
tomjen3 6y ago
Then hopefully the language will be forked and we can have go++, with generics, the ability to build cross platform gui apps and much more rejoicing.
dunefox 6y ago
> I wish they would just freeze the language and not add anything > I think we should start putting weight on stable unchanging software You would probably like CL then.

deanCommie 6y ago

> Angle brackets require unbounded parser look-ahead or type information in certain situations I wonder how this is solved in Java, and C++, and C#, and...

lmm 6y ago
C++ is famously Turing-complete to parse - not a desirable state of affairs.
6nf 6y ago
They solve it by using time consuming multi-pass compiling
kyrra 6y ago
Parser lookahead... They even say that it is possible, but it makes producing useful error messages harder and makes the parser more complicated. they are not saying it is not possible, they are just saying it's not preferred to do.
- rsc 6y ago
  In some languages unbounded parser lookahead is enough. But parser lookahead does not solve the ambiguous Go example given in the mail. Only type information would.
  - soamv 6y ago
    Why doesn't the same idea of adding a type keyword work there too? a, b := w<type x,y>(z)
dcu 6y ago
parser look ahead makes the compiler complex and slower and that goes against the Go goals
chamakits 6y ago
I believe the point they are making isn't that it's impossible. It's that with the way they have parsing now, the complexity of using angle brackets vs the complexity of the other options make the other options much more desirable. That seems both entirely reasonable, and language/parser dependent.

chmod775 6y ago

>A typical computer keyboard provides four easily accessible pairs of single-character symmetrical "brackets" "falsehoods programmers believe about keyboards" On the keyboard layouts of many countries these keys aren't accessible at all, either missing entirely or only being accessible via unergonomic key combinations. For this reason myself (and many other programmers) own additional ANSI-US layout keyboards.

faitswulff 6y ago
TIL! Does your default keyboard have the usual round parentheses?
- shultays 6y ago
  They probably still exist but harder to type/require some kind of key combination. The reason to move them is not because they are not used (although in some languages probably it is) but they are less used than the additional characters in those languages
- aabbcc1241 6y ago
  At least you can use gucharmap or other unicode lookup tools to get those characters
hu3 6y ago
You can't please everyone. So might as well pick the most common keyboard layout among your users and call it typical computer keyboard. I'm afraid there's no easy solution to this problem but I'd like to hear your suggestion.
- whatshisface 6y ago
  Well, there's always begin and end Isn't there? ;)
  - deathanatos 6y ago
    Or… indentation! crowd gasps; lightning flashes; thunder claps; maniacal laughter is heard in the distance

wbl 6y ago

Just use guillamets already.

djhaskin987 6y ago
Link for those who are curious: https://en.wikipedia.org/wiki/Guillemet https://en.wikipedia.org/wiki/Guillemet
- rohan1024 6y ago
  ‹‹››

jiggawatts 6y ago

Why don't they just use characters from the Canadian Aboriginal Syllabics block? https://www.reddit.com/r/rust/comments/5penft/parallelizing_enjarify_in_go_and_rust/dcsgk7n/ https://www.reddit.com/r/rust/comments/5penft/parallelizing_...

ed25519FUUU 6y ago
> type ImmutableTreeListᐸElementTᐳ > If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block, which are allowed in Go identifiers. From Go's perspective, that's just one long identifier. And the next comment is the same thing everyone else is thinking: “oh my god”
- bobbyi_settv 6y ago
  I also like this comment from the almost-empty /r/ProgrammerHumor/ submission linking to that thread: Gives new meaning to the phrase "Native apps"
- jussij 6y ago
  To be fair I suspect this part of that sentence explains the reason for choice of these special character: From Go's perspective, that's just one long identifier. The designer was using those characters to trick the Go compiler which I then suspect means things like go format would also continue to work. Then the designer could easily create a pre-processor that translates those placeholders characters as a way of providing some sort of generics in Go. So in reality this was quite a good solution as I can imagine coming up with a solution that broke go format would have been a real pain to use.
  - mseepgood 6y ago
    > So in reality this was quite a good solution Yes, I do not understand why people find this so hilarious. It's a clever choice.
    - 6y ago

shirro 6y ago

I really like the Go standard libraries. I can do most of what I need with them. I worry some of the people calling for generics will move the language in the direction of massive abstract libraries. I don't want to include a Go version of Boost in everything I build. Complicated type signatures seem like an unnecessary additional burden for average programmers. I really hope generics, like reflection, are only used when there isn't a simpler option. I honestly would have preferred and had more use for sum types. I like the square brackets though. They look right for Go and it is more readable.

_bxg1 6y ago
I haven't used Go but I'm curious, how do core data structures like hash maps work without generics? Does everyone just roll their own for their particular use-case?
- meditative 6y ago
  > how do core data structures like hash maps work without generics blessed implementations inside the language, slices, maps and channels are built in generics. sync.Map is what the standard library version looks like. It loses type safety. https://golang.org/pkg/sync/#Map https://golang.org/pkg/sync/#Map
  - echlebek 6y ago
    I'm looking forward to seeing these types of libraries improve with generics. It's notably more work to use these data structures, even if they are used rarely.
- shirro 6y ago
  Go cheats with some built-in generic types. So you can declare a hashtable as a map of any comparable type to any other type. But yes you typically have to implement things yourself for more complex cases so that does limit the sorts of libraries that are available and the way you write programs.

hedora 6y ago

Are they adding Java style generics (type erasure), or C++ style (compile time specialization)?

skybrian 6y ago
As I understand it, the language spec is designed so that compile-time specialization is possible but not required. It could be some mixture of both.
mappu 6y ago
The go2 proposal (as currently implemented) is a source-to-source translator back to go1, so neither in that case. As for the existing implementation of generic map[K]V, generic []T, chan(T), etc., it's a best-of-both-worlds mix - a kind of erasure (there is only one map implementation in a Go binary) but with a static vtable for accessors without Java's need for boxing - all possible owing to the clever coupling between the runtime and the compiler. See https://dave.cheney.net/2018/05/29/how-the-go-runtime-implements-maps-efficiently-without-generics https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...

thenanyu 6y ago

If the type keyword needs to be added anyways, why not angle brackets then? Is it still ambiguous?

pavon 6y ago
The way I read it, the type keyword would only be used in when declaring generic functions/types, but the angle brackets syntax has clashes when calling generic functions.

deleted 6y ago

[deleted]

miraj18 6y ago

This is cool

coldtea 6y ago

Funny how we add 100 new emoji per year, and yet we can't seem to be able to add a new matching pair of characters in our keyboards for 5+ decades...

josephcsible 6y ago
How many of those emoji are on your keyboard?
- coldtea 6y ago
  On my iOS virtual keyboard that would be all of them. Heck, the Mac laptop's touch strip also features a selection. But that wasn't my point. It was that we get a ton of BS cosmetic/fun items on the Unicode standards, and we can't get a few simple glyph additions on our hardware keyboards that would seriously help programmers for decades to come...
shultays 6y ago
Such as ⸤ ⸥ ｢｣ ⟦ ⟧〔〕⟨ ⟩ « » ⟪⟫ ⦅⦆ ⦉⦊ ⦕⦖ ⧘⧙ ⦓⦔ ⁅⁆ ... ?

nemothekid 6y ago

You have emoji on your keyboard?

coldtea 6y ago
Woosh

rspeele 6y ago

I really like the syntax used to declare generic type parameters to functions in ML-type languages like F#. Writing the below in other languages (pseudocode) feels repetitive in the same way that `Thing thing = new Thing()` did back before `var` or `auto` types became popular: list<Y> Map<X, Y>(list<X> inputs, X->Y mapping) Why do I need to put <X, Y> in brackets after Map? To tell the compiler that these are generics, not attempts to reference actual specific types that just happen to have crappy, nondescript names like X and Y. In F# and friends, there is no need to put a bracketed block declaring which types are generic parameters. I would simply write: let map (inputs: list<'x>) (mapping: 'x -> 'y) : list<'y> = ... The little apostrophe or tick mark before the type name tells the compiler it's a generic type parameter. It's not legal to name a concrete type with a leading tick mark, so there can be no mix-up. At first it looks ugly, but once you are used to it, it is natural and less cluttered than having to have these separate bracketed declarations for "uh-oh, here comes a generic". But I suspect Go will always want more explicit syntax for generics. In part out of backwards compatibility, but largely because Go's designers see generics as an advanced, occasionally useful feature. Correspondingly they'll want the presence of a generic function to have ugly syntactical warning signs: here be dragons. Functional languages usually take the opposite approach and see a fully generic function as less complex than one for a specific type, because just by looking at its signature, you know it doesn't require anything special about the input objects it's going to work on. It is not going to be calling methods on them or messing with their guts. It's just treating them as black-box, could-be-anything cards to be shuffled around from point A to point B.

emmelaich 6y ago
Indeed! You could use other chars if the single quote is a problem. Make identifiers that start with period or tilde perhaps be used for template vars. And only template vars. Might be a bit noisy but less noisy than reusing various types of braces.
- contravariant 6y ago
  If you want to indicate they're parameters you're probably best of using syntax that's already being used for parameters like, $a, ?a, :a. I guess {a} is also used, but we wanted to avoid braces. Not sure if .a or ~a are good choices. The latter is especially bad since it clashes with common syntax for "(bitwise) not a".

tapirl 6y ago

This is a good move, which will make Go more consistent. Making custom generic and builtin generic consistent absolutely makes Go more easy to learn and read.

jfoutz 6y ago

seems like you could just not use ',' as the separator character in type declarations. +-*^% I think have the same problems, but @#$ are available. weird syntax, but go already makes the tradeoff, do what's fast to parse.

emmelaich 6y ago

I know it's unpopular but judicious use of significant white space would solve the ambiguity too.

ca_parody 6y ago

To me, Go feels condescending to write without generics. I may just not groke the idioms - but putting users in a walled garden that the standard library has the privileged to escape from (i.e. (Map<k, v>)) just seems to go too far in not trusting the programmer. The fact that generics have taken so many years - to still be talking about what [<( to use is beyond me. There is a difference between becoming C++ and allowing programmers to make fundamental abstractions without interface{} hacks.

yiyus 6y ago
Maps are part of the language. The standard library is written in Go. There are a few special packages (unsafe, reflect, ...) but maps are not one of those cases.
BenFrantzDale 6y ago
Well said. As a C++ programmer I always find Go rubs me the wrong way. Like they want to make my life difficult. I think you hit the nail on the head that it feels condescending. My visceral reaction to not being able to write a standard library as performant as the provided one is “this is a toy language”. I know it’s not and I know I have to use C to do that in Python, but still.
throw_m239339 6y ago
The problem is not so much the absence of generics but the availability of crazy reflection at runtime compared to the rigid type system at compile time. There absolutely is a lack of balance here. All these things were already pointed out 10 years ago and were met by "you don't need that with Go", "Go back writing Java" sort of contempt, which gave the Go community a bad reputation. Go could have been fixed 10 years ago if Rob Pike and co listened. They didn't want to because they thought they knew better than everybody else. ADA already fixed the genericity problem while keeping things readable with a limited form of generics as incomplete types.
- pjmlp 6y ago
  As I already mentioned a coupled of times, even CLU like generics would have been a good enough solution. Something that they acknowledged not bothered to look at initially. https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf... > We would have been well-served to spend more time with CLU and C++ concepts earlier.

hota_mazi 6y ago

> A typical computer keyboard A typical NORTH AMERICAN computer keyboard. Does the myopia of the Go compiler team know any bounds?

Ericson2314 6y ago
Nope it does not!
deleted 6y ago
[deleted]
IshKebab 6y ago
You mean a typical English keyboard? Ironic that you are criticising them for only thinking of the US, but you've done exactly the same thing.
- lixquid 6y ago
  The ISO UK keyboard layout exists. The North American keyboard layout is North American, not "English".
  - p0llard 6y ago
    This is true, but an ISO UK keyboard also "provides four easily accessible pairs of single-character symmetrical 'brackets'"; for this particular purpose there is no distinguishing factor between the two layouts.
  - gnabgib 6y ago
    There are other layouts in North America, including French (Canada), Bilingual (also common in Canada), Spanish (Mexico). Plus a multitude of people who have other preferred layouts. There is no official layout for this landmass.
  - IshKebab 6y ago
    They are identical when it comes to brackets.

Chloro 6y ago

If go gets generics I will never use it again.

jagger27 6y ago
Why?
- 72deluxe 6y ago
  I wondered this too. It's not like there's a part of a language you MUST use. Perhaps they are fearful that it'll grow and grow and add features in that will make it difficult to learn and unwieldy. Stroustrup always said that new languages seem fast and easy to learn precisely because they are new languages and don't have the features of maturity. Perhaps this is the case here.
  - pjmlp 6y ago
    He is quite right, yes C++ is a monster dragon, but most languages of similar age only look simple on the surface, even a beginners friendly language like Python. Beneath that simple surface for beginners lies a multi-paradigm language, with overloading, metaclasses, dynamic code generation, multiple inheritance, breaking changes across minor versions in 30 years of history, a standard library that can be used as doorstep when printed, several implementations not 100% semantic compatible with CPython,.....
    - 72deluxe 6y ago
      Yes, it's good isn't it!
- lkramer 6y ago
  Maybe because you take away one of the big advantages of Go which is easily maintainable code, and end up with just another clone of Java/C#, so why don't you just use those instead?
  - 6y ago

verandaguy 6y ago

Honest question; why use a comparatively exotic syntax for generics? Most other similar languages — Java, C# — and perhaps most notably C++ since its the closest analogue in terms of paradigm and domain, all use angle brackets (without getting into the semantic differences between "classic" generics and the STL). AFAIK, Golang assigns no special syntactic meaning to angle brackets beyond comparison operators (correct me if I'm wrong though, I don't write much Go), and using a familiar syntax would make it easier to work with coming from other languages.

ogogmad 6y ago
It complicates parsing and creates ambiguity. It also makes it harder to create tooling. > AFAIK, Golang assigns no special syntactic meaning to angle brackets beyond comparison operators Go has also got bit-shift operators << and >>, which wouldn't interact well with angle-bracket notation.
- Arainach 6y ago
  >Also, Go has bit-shift operators << and >>, which wouldn't interact well with angle-bracket notation. So do Java and C++. This is a solved problem in parsing. The overall point that angle brackets make parsing more complex stands, but bit-shift arguments are irrelevant.
  - pjmlp 6y ago
    With the little detail that their lexer makes use of type information, while Go one doesn't.
  - imtringued 6y ago
    "Solved" is the wrong goal. It would be much better if the problem did not exist in the first place.
remus 6y ago
From the post: > Angle brackets require unbounded parser look-ahead or type information in certain situations So they want to avoid angle brackets so they can efficiently parse source code.

coldtea 6y ago

Woosh

pjmlp 6y ago

If they finally end up adding any kind of generics support, it feels much more natural, from my experience with languages that use [] and () for type parameters, [] are much better visually.

IshKebab 6y ago

This is much more readable IMO.

kitd 6y ago

I liked the alternative proposed later in the thread: gen T type pair struct { a, b T } // contrast with type pair(type T) ... gen T,U type W struct { a T; b U } // contrast with type W(type T, U) ... gen T func Print(s []T) {...} // print a slice of T or using `forall` forall T, type pair struct { a, b T } V readable IMO

tenderfault 6y ago

can someone just stick this thread forever on top of HN listing

rurban 6y ago

Perl allows optional delims if ambigious. so if the best set <> is ambigious double or triple them. But much easier would be to demand uppercase T type variables. a, b = w < x, y > (z) w is lowercase, unambigious. Parsed as list of comparisons. a, b = T < x, y > (z) Ambigious, so use a, b = T <<< x, y >>> (z) instead. These cases are very rare. Or demand parens for such ambigious lists of comparisons. Might be too late already. Of just demand the type keyword there also: a, b = w < type x, y > (z)

alvarelle 6y ago

I did not see digraphs mentioned. Could look like <: and :>. The formatting tool could even normalize that to some prettier unicode.

chvid 6y ago

Doesn't [ ] have similar problems? Suppose I write: a[x](z) Is that a read of array a with index x followed by a function invocation with the parameter z. Where it could also be a type conversion of z into generic type a of x.

earthboundkid 6y ago
The issue isn't the interpretation; it's the parsing. It doesn't matter to the parser in this case if x is a type or an int. You'll have the same AST either way. But if you have f<a,b>(x), it matters if this is a generic or a pair of comparisons because the AST would be totally different.

_ph_ 6y ago

Honestly, I prefer the parenthesis notation to the square or angled brackets. It is perhaps a bit verbose, but easy to read in my eyes. Not to mention the keyboard problems with non-English keyboard layouts.

ivoras 6y ago

> Angle brackets require unbounded parser look-ahead or type information in certain situations So.... they'd rather pull the "it's hard to do" or the NIH card, than make it easier for developers switching between languages? Interesting choice. Someone mentioned "condescending" -- that description fits perfectly. And there I was thinking that COMPILER WRITING should be hard - as hard as possible - in order to make the code which is to be compiled as easy to write as possible.

breakingcups 6y ago
I think they actually make a fair point because in this case "hard to do" probably equates to "makes the compiler a lot slower". Go is very easy to switch to from most other languages so I don't think making it harder to switch is a design goal from the team. When Go came on the scene, I actually really appreciated the fact that they truly explored what a new language could do differently, especially because it was coupled with a strong philosophy. Now, since 1.0 there have been plenty of decisions made which I dislike. Still, I think the glasses through which you choose look at the Go teams motive aren't fair. Why wouldn't designers of a programming language like Go think it through very carefully, weigh every angle and decide to settle on a lesser used but possible equally valid solution compared to 80% of the languages out there?
- centril 6y ago
  > I think they actually make a fair point because in this case "hard to do" probably equates to "makes the compiler a lot slower". They are wrong in this case. When considering whether to allow `foo<T>();` in Rust, we measured the performance impact that infinite look-ahead / backtracking would have in that case. The result was negligible. Why? Because the amount you have to look-ahead, before you can say "definitely wrong; let's turn back", in realistic code is bounded to maybe max 30 for some very complex generics. It's however much more likely that no back-tracking occurs at all because the parse will be correct. When engineering your compiler, you can always make choices about which path is statistically more likely, as back-tracking in a well designed language is usually pathological. The theoretical O(..) complexity is largely irrelevant. (Source: I was the main maintainer of rustc's parser and refactored large parts of it.)

arun6582 6y ago

Whatever!! Go finally brought generics. The same thing which it used to criticize java for Lol