4 ms·

This seems odd for an article that got 30 upvotes in 15 minutes (probably not really enough time to read it all, mind you.) The complaints are a rehash of what’

by jchw 5y ago

This seems odd for an article that got 30 upvotes in 15 minutes (probably not really enough time to read it all, mind you.) The complaints are a rehash of what’s been said already, only worse. Which is completely fair considering it is at least as old as 2014! It says Go’s solution to generics is interface{}. Not really; Go just doesn’t have a solution for that yet. Go 2 of course, promises to add one, that would answer to the basic asks in this article. As for operator overloading and language extensibility, I think most people would agree these are never really clear cut wins as they can add inordinate complexity in exchange for sometimes dubious value. It certainly makes some things look nicer (matrix and vector types for sure) but you can always use functions to get the same utility with less sugar. You can go on. A lot of concerns raised about Go don’t end up reflecting the day to day problems with writing Go code though, which imo is a sign that there is a gap between what people think is a problem by comparing it to other languages like C++ and Rust, and what is actually a problem by experiencing the language first hand for an extended period. I’d argue the generics problem is overblown; a solution to it will probably be welcomed, but it wasn’t like Go codebases were suffering from this. It was just making certain things (like working with slices) slightly more awkward and error prone. For an article from 2014 these would’ve been valid concerns though in practice nobody writes Go code the way that they write C++, Rust, etc. code making some of the complaints feel like they are missing the point.

wyager 5y ago
> The complaints are a rehash of what’s been said already I wrote this like 7 or 8 years ago, so it was fairly novel at the time :) > Go just doesn’t have a solution for that yet. Go 2 of course, promises to add one I’ve also been hearing this since I initially wrote this. In any case, the article is about Go as it exists. If Go 2 actually makes significant improvements in these domains I will add an updated header pointing that out.
- jchw 5y ago
  Yes, to be clear, it makes sense for back then. It was weird to see it on HN frontpage as if it were new. However the Go 2 thing is not in the same state it was in 2014; the design proposal was formally accepted and a compiler exists. It will likely take a long time to see how it hashes out, but it’s probably fair to treat it as an inevitability at this point.
tialaramex 5y ago
> As for operator overloading and language extensibility, I think most people would agree these are never really clear cut wins as they can add inordinate complexity in exchange for sometimes dubious value. It certainly makes some things look nicer (matrix and vector types for sure) but you can always use functions to get the same utility with less sugar. Operator overloading to do what C++ did from the outset is a mistake. It looks flashy, but it buries land mines in the habits of your programmers. A programmer who is actually both shifting numbers and doing some other arithmetic operation may look at the code and wonder, "What is the precedence of these operations?" and having concluded that they don't remember, or at least, that their reviewers may not remember, though the compiler surely does, they'll add parentheses or re-factor. But if they've learned that shift is really some other operation concealed by overloading - they can be astonished when the compiler cheerfully applies that other operation with the precedence of a shift 'cos as far as the compiler is concerned that's still what it is. But there definitely are uses (matrix addition for example) where just overloading an operator feels very sensible. I can see a strong case for == and != too if your language has that from the outset, it won't make sense to add it later. So the trick is that a language should do this very sparingly and encourage programmers likewise, but I think that only makes it a feature to avoid entirely if you're very dedicated to having a small language, since overloading is nice but not necessary. Go maybe is in that category.

by jchw 5y ago

wyager 5y ago

> The complaints are a rehash of what’s been said already I wrote this like 7 or 8 years ago, so it was fairly novel at the time :) > Go just doesn’t have a solution for that yet. Go 2 of course, promises to add one I’ve also been hearing this since I initially wrote this. In any case, the article is about Go as it exists. If Go 2 actually makes significant improvements in these domains I will add an updated header pointing that out.

jchw 5y ago
Yes, to be clear, it makes sense for back then. It was weird to see it on HN frontpage as if it were new. However the Go 2 thing is not in the same state it was in 2014; the design proposal was formally accepted and a compiler exists. It will likely take a long time to see how it hashes out, but it’s probably fair to treat it as an inevitability at this point.

tialaramex 5y ago

> As for operator overloading and language extensibility, I think most people would agree these are never really clear cut wins as they can add inordinate complexity in exchange for sometimes dubious value. It certainly makes some things look nicer (matrix and vector types for sure) but you can always use functions to get the same utility with less sugar. Operator overloading to do what C++ did from the outset is a mistake. It looks flashy, but it buries land mines in the habits of your programmers. A programmer who is actually both shifting numbers and doing some other arithmetic operation may look at the code and wonder, "What is the precedence of these operations?" and having concluded that they don't remember, or at least, that their reviewers may not remember, though the compiler surely does, they'll add parentheses or re-factor. But if they've learned that shift is really some other operation concealed by overloading - they can be astonished when the compiler cheerfully applies that other operation with the precedence of a shift 'cos as far as the compiler is concerned that's still what it is. But there definitely are uses (matrix addition for example) where just overloading an operator feels very sensible. I can see a strong case for == and != too if your language has that from the outset, it won't make sense to add it later. So the trick is that a language should do this very sparingly and encourage programmers likewise, but I think that only makes it a feature to avoid entirely if you're very dedicated to having a small language, since overloading is nice but not necessary. Go maybe is in that category.