12 ms·

Changes I would make to Go

113 points by jaxondu 10y ago

geodel 10y ago
These are the changes that if made Go wouldn't be language it is. Go is simple, straightforward if little verbose. To me Go fits perfectly for business apps that I write currently in Java.
- nemothekid 10y ago
  I'm not sure - I've been writing Go for 4 years in a production setting, when we switched our API service from Python to Go at the release of Go 1.1. Since then our default language is Go, and I write Go everyday. Things like Generics I haven't been really bothered by. But where I thought he brought up really good points are 1. nil. He's right compared to more recent languages, nil is awkward. I've been bit multiple times by the 'nil checks sometimes fail.' concept. Option/Sum types are so much cleaner, and having non-nullable types make a lot of things easier to reason about. 2. error checking. My main gripe is when you are writing a process that involves calling multiple functions that could return errors. You then need more boiler plate in order to stay sane and DRY - and I've admittedly bitten myself with the 'err' shadowing that happens sometimes. I don't think a Maybe type would have made Go more complex, and I think it would have fit in nicely with the 'Zero Value' concept.
  - richardwhiuk 10y ago
    Maybe/Option/Result types don't work without generics, because you significantly reduce the type checking.
    - stouset 10y ago
      And this is why people have been begging the golang developers to add generics practically since it was conceived. Yes, generics make compiler-writers' lives more difficult. But they can dramatically simplify the lives of everyone else.
    - saghm 10y ago
      I'm not a Go programmer, but from what I understand, things like Go's map implementation in the standard library are usable as if they're generic. Couldn't they add a few more types like this (e.g. Option and Result) in the same way without exposing generics as a language feature?
      - jimsmart 10y ago
        I program some Go - I believe you are talking about the 'empty interface', e.g. map[string]interface{} The problem with that is that you instantly lose compile-time type checking, and have to check/assert the types yourself at runtime after accessing the map. In a strongly-typed language this kinda goes against the grain, and is a PITA. (Although it still can be useful at times). My 2p.
        sbov 10y ago
        The point is that a map can be type safe because it's built into the language, and that the designers could do exactly the same with a maybe/option/result feature.
      - kasey_junk 10y ago
        You are absolutely correct. Go has generics. It just doesn't have user defined ones. If the language designers thought an Option/Result/Try was valuable they could add it. Just like they could add Futures/Promises and concurrent safe maps if they wanted to.
  - gue5t 10y ago
    Sum types aren't a "more recent" idea than Go; they've been around for about half a century. Go is just designed by/for programmers who have brain damage from writing C (in any language) for many years.
  - stcredzero 10y ago
    2. error checking... I've admittedly bitten myself with the 'err' shadowing that happens sometimes. This is indeed a problem. It's the same problem with people writing a catch-all exception in Java, then forgetting to write the correct handler later. Considering the Go team's priorities, it's one they should fix!
    - kevhito 10y ago
      Go has "defer", which is great. Perhaps it should have a similar "whenever" construct. val, err := foo() if err != nil return err vee, err := bar() if err != nil return err Would become: var err error whenever err != nil return err val, err := foo() vee, err := bar() Static analysis would insert the appropriate check any time err is assigned in the function. Aliasing might be a gotcha, but I'd bet that is a rare case and static escape analysis could maybe catch it and either error, or just insert extra checks.
      - deleted 10y ago
        [deleted]
  - Gibbon1 10y ago
    > 2. error checking What I want? I want to a) have an option where an unchecked return error causes the program to log and exit. error SomeFn(int blah, int haw) { if(blah < 0 || haw < 0) error(1); return(bah*haw); } // program will die here SomeFn(-20, 23); // program will not die here if(SomeFn(-20, 23) != 0) { // something } b) be able to pass a label to a function to handle errors. Example int SomeFn(int blah, int haw, error oops) { if(blah < 0 || haw < 0) oops(1); return(bah*haw); } int res = SomeFn(-20, 23, crap); printf("res =%i\n", res); // SomeFn returns here crap: print("parameters can't be negative");
- AnimalMuppet 10y ago
  Let Go be Go, let Rust be Rust, and let Haskell be Haskell. There's no need to try to make Go into Rust; we already have one of those.
  - Zikes 10y ago
    One of the primary design principles behind Go is that it be designed to incorporate the best available features of other languages, as much as it is able while remaining simple and easy to learn and use. If there is a way to incorporate the best features of Haskell and Rust while maintaining Go's current simplicity and ease of use, then it should be incorporated. To that end, the Go core developers have expressed an intent to implement Generics, however they want to do so in a way that does not (significantly) negatively effect the language's simplicity or compile times. https://github.com/golang/go/issues/15292 https://github.com/golang/go/issues/15292
    - kasey_junk 10y ago
      > One of the primary design principles behind Go is that it be designed to incorporate the best available features of other languages Is that documented somewhere?
      - Zikes 10y ago
        I expected I would find it in https://golang.org/doc/faq https://golang.org/doc/faq but I'm not seeing it there, so I have no reliable sources for that statement at this time. It's something I hear often, though. That Go is intended to be a "modern" language, with the definition of "modern" being that the opportunity that a blank slate provides allows for the application of the best features and learnings of the languages of the past.
        AnimalMuppet 10y ago
        > ... with the definition of "modern" being that the opportunity that a blank slate provides allows for the application of the best features and learnings of the languages of the past. Application of the best features and learnings to a particular problem domain. The (intended) domain is Google-scale code bases that live for decades. The ideas that are important there may not be applicable anywhere else. If they are, it's more by happenstance than design.
- kasey_junk 10y ago
  I think go would actually be a pretty bad match for software that is modeling some sort of business domain. The type system is just not robust enough for it. What it is good for is software that is about moving bytes around from place to place. Network daemons, web servers, cli tools that interact with JSON/Xml in simple ways.
alphabettsy 10y ago
This article should be called, "Things I'd like to see in Go from Rust".
- partycoder 10y ago
  Not only Rust but many languages that are moving in the same direction.
- bluejekyll 10y ago
  Rust is really a language that pulled a lot of concepts that were done elsewhere, into a really solid nice package. Go is unusual in the new language space in that in eschewed many of these modern techniques. Swift comes to mind as a comparison, which has many of the features that the author misses. Personally I like the examples offset by a single other language as it's less context switching.
  - stouset 10y ago
    That's the feeling I get when using Rust: all of the bits of the language appear to work well together. People clearly thought about how all of the features in Rust would interoperate; it was designed. Go, on the other hand, continually feels like a language that wasn't designed as much as it accumulated. None of the parts seem to work in concert. Nil by itself was a bad idea, but when combined with actually-nil-but-not-really interfaces, it leads to subtly broken code. Tuples feel bolted on as second-class citizens, and tuple-based error patterns combined with sometimes-nonsensical zero values for types makes it uncomfortably easy to accidentally use invalid values when you have a typo in error-handling. Implicitly implementing interfaces makes sense until you type-switch on interfaces at runtime, and then through edits elsewhere one interface becomes a distinct subset of the other interface — depending on how they're ordered, you may never hit the other code. Some of the decisions made in golang make sense in isolation, but in concert they lead to confusion, subtle bugs, and copy-pasted code everywhere.
    - nortiero 10y ago
      I feel the exact opposite... Go is a bold design, if not an elegant one, yet powerful. Rust is a design-by-committee language, built from accretion and removal. Its origins as a managed language, pivoted and is now a second system C++ replacement -- the only one, to be fair.
kmicklas 10y ago
Go is what happens when you give people who have no idea about languages Google-level resources.
- sidlls 10y ago
  That's just not justifiable. Agree or not with the design decisions behind Go, its creators are at the far opposite end of "no idea about languages."
  - twic 10y ago
    Then how did they come up with Go? Alternatively, if they are knowledgeable about language design, what other good language designs have they come up with? I am perpetually baffled by this particular defence of Go. Go has a number of real strengths, but it also has several howling, inexcusable, flaws. How can you possibly say that that this is the work of people who are expert in language design?
    - AnimalMuppet 10y ago
      Look up Pike's resume. Look up Thompson's. Look at your own. Those guys have far more experience at designing (and even using) languages than you do. You may not like the choices they made. Fine. But stop assuming that it was from ignorance or incompetence. It wasn't.
    - stcredzero 10y ago
      Why is it that some languages which are lauded for their programming language design aren't used? Alternatively, if "language design" as you think of it was all that truly mattered, why isn't the programming world as you wish it would be? (Such things were asked in the Smalltalk community for years.)
      - ajmurmann 10y ago
        I think Smalltalk is a bad example for this. I've been told by Smalltalk programmers that everything in that eco system used to be insanely expensive. A better example is probably Haskell or Lisp. As you are probably trying to imply the learning curve seriously matters. Go is a true winner here.
astdb 10y ago
Here we Go
- stcredzero 10y ago
  Here we Go We're rewarding these posts with attention. I guess on some level, these language wars are gratifying.
CalChris 10y ago
> First, functional programming is particularly difficult in Go. In fact the language discourages functional programming. Well, if I were the king of the forest, I'd move functional programming from Rust to Go. With Rust, there's a lot of this higher level stuff in a supposably lower level language that would be more at home and useful over in the two letter language.
- stouset 10y ago
  In what way are these tools not also useful in Rust? Why can't we have both?
- tps5 10y ago
  > there's a lot of this higher level stuff in a supposably lower level language I feel like you're suggesting that "high level stuff" is bad because it's "high level stuff." In my opinion, the goal of low level languages is to operate under certain constraints. If you can operate under those constraints and still include "high level stuff," then you should.
- throwaway91111 10y ago
  You seem to be conflating capability and abstraction. Rust has low-level access to hardware and execution but provides a high level of abstraction.
alvil 10y ago
I can't believe you can look at that ugly colorscheme whole day working in even uglier language which rust really is.
hhsnopek 10y ago
> First, functional programming is particularly difficult in Go. In fact the language discourages functional programming. Then it seems that Go isn't the language for you. With that Go nor any language, unless intended, is suppose to be a one-all solution for every problem. We can accomplish a majority, if not all, problems in a language, but this shouldn't assumed that a language is intended to do so.
- stouset 10y ago
  His point is that golang makes it unnecessarily hard to accomplish what really ought to be simple tasks inherited from functional programming ideas. Other languages, like Rust and Ruby, have adopted some of the really simple and powerful functional idioms like Map, Sum, Select, Reduce, etc., whereas golang makes it impossible to abstract away any sort of iteration logic. He even shows how this lack of abstraction power has knock-on effects in the form of dramatically-increased difficulty of parallelism and concurrency.
- burke 10y ago
  While I understand the argument for simplicity and agree with the premise in most cases, I find it pretty hard to argue for this code: ys := []byte{} for _, x in xs { ys = append(ys, f(x)) } over something like this code, which is more obvious, less error-prone, and, though it relies on an additional concept, it's an extremely broadly-known concept: ys := collections.map(xs, f) I don't think a proper collections library would require very invasive runtime changes -- though, once you start down this path, you and up at "but what if `f` returns `(myType, error)`, and then you're wishing for Option/Maybe types (which is another feature that I believe Go should have implemented, but is more obviously outside of the apparent mandate). EDIT: It would make static analysis significantly more complex too.
  - jakewins 10y ago
    Go can't do this, because you can't define `map` as returning "a collection of whatever `f` returns". If they build a collections API like this now, without generics, and they then add generic types later, they will be in the same position Java found itself in - lots of painful API migrations. While the generics debate is legendary in go, it does still seem very much like the intention is to eventually include it. Given that, I think it makes perfect sense to wait to introduce more special cases (like `append`). In the meantime: func Map(in []interface{}, f func(interface{}) interface{}) []interface{} { out := make([]interface{}, len(in)) for i, v := range in { out[i] = f(v) } return out } :)
hhsnopek 10y ago
> First, functional programming is particularly difficult in Go. In fact the language discourages functional programming. Then it seems that Go isn't the language for you. With that Go nor any language, unless intended, is suppose to be a one-all solution for every problem. We can accomplish a majority, if not all, problems in a language, but this shouldn't assumed that a language is intended to do so.
spraak 10y ago
I really want to love Rust, but it's so visually unappealing :/ I love how clean Go looks. I know it's vain..
- kbenson 10y ago
  That must be very subjective, as I have the exact opposite reaction. I mean, there are portions of rust that are dense and cluttered, such as function definitions with the ownership rules, but the content of those functions I find very clear and concise.
  - dhfhduk 10y ago
    To me, Go and Rust are about equally appealing. Rust is more complex to me because it's a lower-level language; Go looks like a higher-level cousin. I learned from Rust that I dislike curly braces. The language itself seems great conceptually, but I prefer the appearance of languages like Python that drop curly braces. If Rust was developed without curly braces I'd probably be [more] obsessed with it. Strangely enough, parentheses and square brackets are also appealing. I also dislike writing code where whitespace is meaningful, even though I prefer to read it. It's just the appearance of curly braces that bothers me.
    - kbenson 10y ago
      > It's just the appearance of curly braces that bothers me. That sounds easily fixable with a different font. Or make your own. :)
- beefsack 10y ago
  Like all things superficial, the more time you spend looking at something, the more the visual appeal (or lack thereof) normalises to average. I think one tangibly good thing about Go though is how readable it is and how easy it is to grok, even with all the error handling boilerplate. I'd argue that Rust is also very readable though, and if the features of the language appeal to you I'd suggest giving it some time to get over the visual hurdle. From a personal standpoint having spent years working in both languages, it's rare I'll choose Go over Rust nowadays purely for practical reasons. I'm roughly equally productive in both, but the end result tends to be much more performant, maintainable and robust on the Rust side.
Risord 10y ago
For Go people: How (learning) Go made you better programmer? I haven't written any of these two languages but I have read Rust doc few times in depth and I constantly miss many of it's features in my daily .net work since then. Example: -Optional over null -Union types -Trait implementation is independent from source and target models
- danaliv 10y ago
  > How (learning) Go made you better programmer? It didn't. Go offers nothing that a dozen other languages haven't already offered, and fails to include important features that are standard in every other modern language. It is simplistic to a fault.
  - kasey_junk 10y ago
    You know, that is my immediate reaction as well. But if I'm more introspective it did teach (or reinforce) a few lessons that are worth knowing. Dependencies have a cost (even if they are easy to manage). Abstractions have a cost (even if they are easy to write). Consistency is often better than best case performance. Code style doesn't matter. Scriptable tools are invaluable. Make ain't that bad. Enjoying your team is more important than enjoying your language. All told, I don't think Go will ever be my first choice, everything else being equal, for anything beyond what I like to call "bash++". But it also won't be a reason I don't take a job, or move to a team and if my team wants to use it, I won't object too strongly.
- mtalantikite 10y ago
  Go made me appreciate static typing and a compiler. Before picking up Go around the 1.0 release, the last time I spent any significant time with those tools was 10 years prior as an undergrad using Java. Java really made me hate those things. I spent the years in between with languages like Ruby, JavaScript, and Python. Now I actually prefer using compiled, statically typed languages, Rust being the most recent one for me (and I still dislike Java).
  - Risord 10y ago
CalmStorm 10y ago
It seems to me golang and Rust are often being compared with each other. Given that Swift starts to be used on server side, I would love to see some comparison between golang and Swift, or Rust and Swift.
justicezyx 10y ago
Do language debaters all think every human should speak one language?...
- int_19h 10y ago
  Yes. And it should be Lojban. ~
  - omginternets 10y ago
    I'm not sure I understand. Could you please translate your comment into Lojban?
- kiriakasis 10y ago
  I think it is more about how efforts in the software community come in finite amount and it fell pointless and damaging to waste so much of it of unsatisfactory language. If i learned of a esteemed professor choosing to publish their latest research in Italian i would be honored, but I would also consider i a terrible idea.
kristianp 10y ago
Like C, Go is a small language. Given that the creators of go like its smallness and simplicity, all those features are never going to be added to Go. When Bjarne Stroustrup wanted to add OO features to C, he created C++, initially as a translator that output C. If someone wants to add features to Go, they can create a "Go++" to Go translator, with pattern matching, generics, tagged unions. Clearly it's guaranteed to be very popular! /s
- ngrilly 10y ago
  It's the approach Robert Griesemer (member of the Go core team) chose to prototype implementation of operator methods in Go: https://github.com/griesemer/dotGo2016 https://github.com/griesemer/dotGo2016
  - kristianp 10y ago
    Actually it looks like he forked and modified the go compiler itself.
jrobn 10y ago
OK, go will never have generics (except that it does in "make", "range", "chan", ok whatever...). That's fine with me. But including even just a few suggestions in the parent article would make Go a more approachable language to everybody. * Pattern matching is intuitive and can be extremely powerful. * It's pretty clear that Null should not exist anymore. * Multiple return values, but no tuples?! The go designers seem to not have a problem with special cases so why didn't they include special cases for an Option<T> and Result<T,E>, two things that, with pattern matching, would fit right into Go's explicit error checking philosophy.
- sjellis 10y ago
  > OK, go will never have generics (except that it does in "make", "range", "chan", ok whatever...). That's fine with me. But including even just a few suggestions in the parent article would make Go a more approachable language to everybody. The current position is that the core team will only include generics if they can find a design that satisfies them. Which has sounded a lot like "no, never" but Russ Cox has said that he wants to look into implementing generics again this year.
hubert123 10y ago
Just another generic complaint about Go's lack of bloat. It's all completely naive, never understanding why Go doesnt want generics beyond a simple "b-b-but look, the pattern matching of Rust is simple too!" No it isnt simple just because you say it is. It is the opposite of simple. I've read the Rust docs on it several times and I still dont have a clear mental picture of how to read a match statement out loud. "match result with Some(number) .. then do..? But match HOW?" I've been thinking of a clearer syntax/naming for match and in my humble opinion it should literally just be called 'if' and any inconsistency that doesnt align with that be removed from the language. Calling 'match' match is haskell programmers gone wild. Programmers in the real world dont have a clue how to read 'match'
- steveklabnik 10y ago
  If you have the time and inclination, I'd love to know if the second edition of the book makes it more clear to you http://rust-lang.github.io/book/second-edition/ch06-02-match.html http://rust-lang.github.io/book/second-edition/ch06-02-match...
- kiriakasis 10y ago
  I agree a bit, in haskell for example it is not always easy to figure out the computation order, it is about tradeoff and go looks too much on the simpler side.
sdogruyol 10y ago
Crystal would be a great choice for the author.

113 points by jaxondu 10y ago

These are the changes that if made Go wouldn't be language it is. Go is simple, straightforward if little verbose. To me Go fits perfectly for business apps that I write currently in Java.

nemothekid 10y ago
I'm not sure - I've been writing Go for 4 years in a production setting, when we switched our API service from Python to Go at the release of Go 1.1. Since then our default language is Go, and I write Go everyday. Things like Generics I haven't been really bothered by. But where I thought he brought up really good points are 1. nil. He's right compared to more recent languages, nil is awkward. I've been bit multiple times by the 'nil checks sometimes fail.' concept. Option/Sum types are so much cleaner, and having non-nullable types make a lot of things easier to reason about. 2. error checking. My main gripe is when you are writing a process that involves calling multiple functions that could return errors. You then need more boiler plate in order to stay sane and DRY - and I've admittedly bitten myself with the 'err' shadowing that happens sometimes. I don't think a Maybe type would have made Go more complex, and I think it would have fit in nicely with the 'Zero Value' concept.
- richardwhiuk 10y ago
  Maybe/Option/Result types don't work without generics, because you significantly reduce the type checking.
  - stouset 10y ago
    And this is why people have been begging the golang developers to add generics practically since it was conceived. Yes, generics make compiler-writers' lives more difficult. But they can dramatically simplify the lives of everyone else.
  - saghm 10y ago
    I'm not a Go programmer, but from what I understand, things like Go's map implementation in the standard library are usable as if they're generic. Couldn't they add a few more types like this (e.g. Option and Result) in the same way without exposing generics as a language feature?
    - jimsmart 10y ago
      I program some Go - I believe you are talking about the 'empty interface', e.g. map[string]interface{} The problem with that is that you instantly lose compile-time type checking, and have to check/assert the types yourself at runtime after accessing the map. In a strongly-typed language this kinda goes against the grain, and is a PITA. (Although it still can be useful at times). My 2p.
      - sbov 10y ago
        The point is that a map can be type safe because it's built into the language, and that the designers could do exactly the same with a maybe/option/result feature.
    - kasey_junk 10y ago
      You are absolutely correct. Go has generics. It just doesn't have user defined ones. If the language designers thought an Option/Result/Try was valuable they could add it. Just like they could add Futures/Promises and concurrent safe maps if they wanted to.
- gue5t 10y ago
  Sum types aren't a "more recent" idea than Go; they've been around for about half a century. Go is just designed by/for programmers who have brain damage from writing C (in any language) for many years.
- stcredzero 10y ago
  2. error checking... I've admittedly bitten myself with the 'err' shadowing that happens sometimes. This is indeed a problem. It's the same problem with people writing a catch-all exception in Java, then forgetting to write the correct handler later. Considering the Go team's priorities, it's one they should fix!
  - kevhito 10y ago
    Go has "defer", which is great. Perhaps it should have a similar "whenever" construct. val, err := foo() if err != nil return err vee, err := bar() if err != nil return err Would become: var err error whenever err != nil return err val, err := foo() vee, err := bar() Static analysis would insert the appropriate check any time err is assigned in the function. Aliasing might be a gotcha, but I'd bet that is a rare case and static escape analysis could maybe catch it and either error, or just insert extra checks.
    - deleted 10y ago
      [deleted]
- Gibbon1 10y ago
  > 2. error checking What I want? I want to a) have an option where an unchecked return error causes the program to log and exit. error SomeFn(int blah, int haw) { if(blah < 0 || haw < 0) error(1); return(bah*haw); } // program will die here SomeFn(-20, 23); // program will not die here if(SomeFn(-20, 23) != 0) { // something } b) be able to pass a label to a function to handle errors. Example int SomeFn(int blah, int haw, error oops) { if(blah < 0 || haw < 0) oops(1); return(bah*haw); } int res = SomeFn(-20, 23, crap); printf("res =%i\n", res); // SomeFn returns here crap: print("parameters can't be negative");
AnimalMuppet 10y ago
Let Go be Go, let Rust be Rust, and let Haskell be Haskell. There's no need to try to make Go into Rust; we already have one of those.
- Zikes 10y ago
  One of the primary design principles behind Go is that it be designed to incorporate the best available features of other languages, as much as it is able while remaining simple and easy to learn and use. If there is a way to incorporate the best features of Haskell and Rust while maintaining Go's current simplicity and ease of use, then it should be incorporated. To that end, the Go core developers have expressed an intent to implement Generics, however they want to do so in a way that does not (significantly) negatively effect the language's simplicity or compile times. https://github.com/golang/go/issues/15292 https://github.com/golang/go/issues/15292
  - kasey_junk 10y ago
    > One of the primary design principles behind Go is that it be designed to incorporate the best available features of other languages Is that documented somewhere?
    - Zikes 10y ago
      I expected I would find it in https://golang.org/doc/faq https://golang.org/doc/faq but I'm not seeing it there, so I have no reliable sources for that statement at this time. It's something I hear often, though. That Go is intended to be a "modern" language, with the definition of "modern" being that the opportunity that a blank slate provides allows for the application of the best features and learnings of the languages of the past.
      - AnimalMuppet 10y ago
        > ... with the definition of "modern" being that the opportunity that a blank slate provides allows for the application of the best features and learnings of the languages of the past. Application of the best features and learnings to a particular problem domain. The (intended) domain is Google-scale code bases that live for decades. The ideas that are important there may not be applicable anywhere else. If they are, it's more by happenstance than design.
kasey_junk 10y ago
I think go would actually be a pretty bad match for software that is modeling some sort of business domain. The type system is just not robust enough for it. What it is good for is software that is about moving bytes around from place to place. Network daemons, web servers, cli tools that interact with JSON/Xml in simple ways.

alphabettsy 10y ago

This article should be called, "Things I'd like to see in Go from Rust".

partycoder 10y ago
Not only Rust but many languages that are moving in the same direction.
bluejekyll 10y ago
Rust is really a language that pulled a lot of concepts that were done elsewhere, into a really solid nice package. Go is unusual in the new language space in that in eschewed many of these modern techniques. Swift comes to mind as a comparison, which has many of the features that the author misses. Personally I like the examples offset by a single other language as it's less context switching.
- stouset 10y ago
  That's the feeling I get when using Rust: all of the bits of the language appear to work well together. People clearly thought about how all of the features in Rust would interoperate; it was designed. Go, on the other hand, continually feels like a language that wasn't designed as much as it accumulated. None of the parts seem to work in concert. Nil by itself was a bad idea, but when combined with actually-nil-but-not-really interfaces, it leads to subtly broken code. Tuples feel bolted on as second-class citizens, and tuple-based error patterns combined with sometimes-nonsensical zero values for types makes it uncomfortably easy to accidentally use invalid values when you have a typo in error-handling. Implicitly implementing interfaces makes sense until you type-switch on interfaces at runtime, and then through edits elsewhere one interface becomes a distinct subset of the other interface — depending on how they're ordered, you may never hit the other code. Some of the decisions made in golang make sense in isolation, but in concert they lead to confusion, subtle bugs, and copy-pasted code everywhere.
  - nortiero 10y ago
    I feel the exact opposite... Go is a bold design, if not an elegant one, yet powerful. Rust is a design-by-committee language, built from accretion and removal. Its origins as a managed language, pivoted and is now a second system C++ replacement -- the only one, to be fair.

kmicklas 10y ago

Go is what happens when you give people who have no idea about languages Google-level resources.

sidlls 10y ago
That's just not justifiable. Agree or not with the design decisions behind Go, its creators are at the far opposite end of "no idea about languages."
- twic 10y ago
  Then how did they come up with Go? Alternatively, if they are knowledgeable about language design, what other good language designs have they come up with? I am perpetually baffled by this particular defence of Go. Go has a number of real strengths, but it also has several howling, inexcusable, flaws. How can you possibly say that that this is the work of people who are expert in language design?
  - AnimalMuppet 10y ago
    Look up Pike's resume. Look up Thompson's. Look at your own. Those guys have far more experience at designing (and even using) languages than you do. You may not like the choices they made. Fine. But stop assuming that it was from ignorance or incompetence. It wasn't.
  - stcredzero 10y ago
    Why is it that some languages which are lauded for their programming language design aren't used? Alternatively, if "language design" as you think of it was all that truly mattered, why isn't the programming world as you wish it would be? (Such things were asked in the Smalltalk community for years.)
    - ajmurmann 10y ago
      I think Smalltalk is a bad example for this. I've been told by Smalltalk programmers that everything in that eco system used to be insanely expensive. A better example is probably Haskell or Lisp. As you are probably trying to imply the learning curve seriously matters. Go is a true winner here.

astdb 10y ago

Here we Go

stcredzero 10y ago
Here we Go We're rewarding these posts with attention. I guess on some level, these language wars are gratifying.

CalChris 10y ago

> First, functional programming is particularly difficult in Go. In fact the language discourages functional programming. Well, if I were the king of the forest, I'd move functional programming from Rust to Go. With Rust, there's a lot of this higher level stuff in a supposably lower level language that would be more at home and useful over in the two letter language.

stouset 10y ago
In what way are these tools not also useful in Rust? Why can't we have both?
tps5 10y ago
> there's a lot of this higher level stuff in a supposably lower level language I feel like you're suggesting that "high level stuff" is bad because it's "high level stuff." In my opinion, the goal of low level languages is to operate under certain constraints. If you can operate under those constraints and still include "high level stuff," then you should.
throwaway91111 10y ago
You seem to be conflating capability and abstraction. Rust has low-level access to hardware and execution but provides a high level of abstraction.

alvil 10y ago

I can't believe you can look at that ugly colorscheme whole day working in even uglier language which rust really is.

hhsnopek 10y ago

> First, functional programming is particularly difficult in Go. In fact the language discourages functional programming. Then it seems that Go isn't the language for you. With that Go nor any language, unless intended, is suppose to be a one-all solution for every problem. We can accomplish a majority, if not all, problems in a language, but this shouldn't assumed that a language is intended to do so.

stouset 10y ago
His point is that golang makes it unnecessarily hard to accomplish what really ought to be simple tasks inherited from functional programming ideas. Other languages, like Rust and Ruby, have adopted some of the really simple and powerful functional idioms like Map, Sum, Select, Reduce, etc., whereas golang makes it impossible to abstract away any sort of iteration logic. He even shows how this lack of abstraction power has knock-on effects in the form of dramatically-increased difficulty of parallelism and concurrency.
burke 10y ago
While I understand the argument for simplicity and agree with the premise in most cases, I find it pretty hard to argue for this code: ys := []byte{} for _, x in xs { ys = append(ys, f(x)) } over something like this code, which is more obvious, less error-prone, and, though it relies on an additional concept, it's an extremely broadly-known concept: ys := collections.map(xs, f) I don't think a proper collections library would require very invasive runtime changes -- though, once you start down this path, you and up at "but what if `f` returns `(myType, error)`, and then you're wishing for Option/Maybe types (which is another feature that I believe Go should have implemented, but is more obviously outside of the apparent mandate). EDIT: It would make static analysis significantly more complex too.
- jakewins 10y ago
  Go can't do this, because you can't define `map` as returning "a collection of whatever `f` returns". If they build a collections API like this now, without generics, and they then add generic types later, they will be in the same position Java found itself in - lots of painful API migrations. While the generics debate is legendary in go, it does still seem very much like the intention is to eventually include it. Given that, I think it makes perfect sense to wait to introduce more special cases (like `append`). In the meantime: func Map(in []interface{}, f func(interface{}) interface{}) []interface{} { out := make([]interface{}, len(in)) for i, v := range in { out[i] = f(v) } return out } :)

hhsnopek 10y ago

spraak 10y ago

I really want to love Rust, but it's so visually unappealing :/ I love how clean Go looks. I know it's vain..

kbenson 10y ago
That must be very subjective, as I have the exact opposite reaction. I mean, there are portions of rust that are dense and cluttered, such as function definitions with the ownership rules, but the content of those functions I find very clear and concise.
- dhfhduk 10y ago
  To me, Go and Rust are about equally appealing. Rust is more complex to me because it's a lower-level language; Go looks like a higher-level cousin. I learned from Rust that I dislike curly braces. The language itself seems great conceptually, but I prefer the appearance of languages like Python that drop curly braces. If Rust was developed without curly braces I'd probably be [more] obsessed with it. Strangely enough, parentheses and square brackets are also appealing. I also dislike writing code where whitespace is meaningful, even though I prefer to read it. It's just the appearance of curly braces that bothers me.
  - kbenson 10y ago
    > It's just the appearance of curly braces that bothers me. That sounds easily fixable with a different font. Or make your own. :)
beefsack 10y ago
Like all things superficial, the more time you spend looking at something, the more the visual appeal (or lack thereof) normalises to average. I think one tangibly good thing about Go though is how readable it is and how easy it is to grok, even with all the error handling boilerplate. I'd argue that Rust is also very readable though, and if the features of the language appeal to you I'd suggest giving it some time to get over the visual hurdle. From a personal standpoint having spent years working in both languages, it's rare I'll choose Go over Rust nowadays purely for practical reasons. I'm roughly equally productive in both, but the end result tends to be much more performant, maintainable and robust on the Rust side.

Risord 10y ago

For Go people: How (learning) Go made you better programmer? I haven't written any of these two languages but I have read Rust doc few times in depth and I constantly miss many of it's features in my daily .net work since then. Example: -Optional over null -Union types -Trait implementation is independent from source and target models

danaliv 10y ago
> How (learning) Go made you better programmer? It didn't. Go offers nothing that a dozen other languages haven't already offered, and fails to include important features that are standard in every other modern language. It is simplistic to a fault.
- kasey_junk 10y ago
  You know, that is my immediate reaction as well. But if I'm more introspective it did teach (or reinforce) a few lessons that are worth knowing. Dependencies have a cost (even if they are easy to manage). Abstractions have a cost (even if they are easy to write). Consistency is often better than best case performance. Code style doesn't matter. Scriptable tools are invaluable. Make ain't that bad. Enjoying your team is more important than enjoying your language. All told, I don't think Go will ever be my first choice, everything else being equal, for anything beyond what I like to call "bash++". But it also won't be a reason I don't take a job, or move to a team and if my team wants to use it, I won't object too strongly.
mtalantikite 10y ago
Go made me appreciate static typing and a compiler. Before picking up Go around the 1.0 release, the last time I spent any significant time with those tools was 10 years prior as an undergrad using Java. Java really made me hate those things. I spent the years in between with languages like Ruby, JavaScript, and Python. Now I actually prefer using compiled, statically typed languages, Rust being the most recent one for me (and I still dislike Java).
- Risord 10y ago

CalmStorm 10y ago

It seems to me golang and Rust are often being compared with each other. Given that Swift starts to be used on server side, I would love to see some comparison between golang and Swift, or Rust and Swift.

justicezyx 10y ago

Do language debaters all think every human should speak one language?...

int_19h 10y ago
Yes. And it should be Lojban. ~
- omginternets 10y ago
  I'm not sure I understand. Could you please translate your comment into Lojban?
kiriakasis 10y ago
I think it is more about how efforts in the software community come in finite amount and it fell pointless and damaging to waste so much of it of unsatisfactory language. If i learned of a esteemed professor choosing to publish their latest research in Italian i would be honored, but I would also consider i a terrible idea.

kristianp 10y ago

Like C, Go is a small language. Given that the creators of go like its smallness and simplicity, all those features are never going to be added to Go. When Bjarne Stroustrup wanted to add OO features to C, he created C++, initially as a translator that output C. If someone wants to add features to Go, they can create a "Go++" to Go translator, with pattern matching, generics, tagged unions. Clearly it's guaranteed to be very popular! /s

ngrilly 10y ago
It's the approach Robert Griesemer (member of the Go core team) chose to prototype implementation of operator methods in Go: https://github.com/griesemer/dotGo2016 https://github.com/griesemer/dotGo2016
- kristianp 10y ago
  Actually it looks like he forked and modified the go compiler itself.

jrobn 10y ago

OK, go will never have generics (except that it does in "make", "range", "chan", ok whatever...). That's fine with me. But including even just a few suggestions in the parent article would make Go a more approachable language to everybody. * Pattern matching is intuitive and can be extremely powerful. * It's pretty clear that Null should not exist anymore. * Multiple return values, but no tuples?! The go designers seem to not have a problem with special cases so why didn't they include special cases for an Option<T> and Result<T,E>, two things that, with pattern matching, would fit right into Go's explicit error checking philosophy.

sjellis 10y ago
> OK, go will never have generics (except that it does in "make", "range", "chan", ok whatever...). That's fine with me. But including even just a few suggestions in the parent article would make Go a more approachable language to everybody. The current position is that the core team will only include generics if they can find a design that satisfies them. Which has sounded a lot like "no, never" but Russ Cox has said that he wants to look into implementing generics again this year.

hubert123 10y ago

Just another generic complaint about Go's lack of bloat. It's all completely naive, never understanding why Go doesnt want generics beyond a simple "b-b-but look, the pattern matching of Rust is simple too!" No it isnt simple just because you say it is. It is the opposite of simple. I've read the Rust docs on it several times and I still dont have a clear mental picture of how to read a match statement out loud. "match result with Some(number) .. then do..? But match HOW?" I've been thinking of a clearer syntax/naming for match and in my humble opinion it should literally just be called 'if' and any inconsistency that doesnt align with that be removed from the language. Calling 'match' match is haskell programmers gone wild. Programmers in the real world dont have a clue how to read 'match'

steveklabnik 10y ago
If you have the time and inclination, I'd love to know if the second edition of the book makes it more clear to you http://rust-lang.github.io/book/second-edition/ch06-02-match.html http://rust-lang.github.io/book/second-edition/ch06-02-match...
kiriakasis 10y ago
I agree a bit, in haskell for example it is not always easy to figure out the computation order, it is about tradeoff and go looks too much on the simpler side.

sdogruyol 10y ago

Crystal would be a great choice for the author.