4 ms·

This sort of gratuitous takedown is unfortunately crack for HN -- pages and pages of "here's how this popular thing is not like this other thing I like", withou

• moultano 11y ago
  While a proposal would be better than a takedown certainly, I do think this kind of language advocacy has value. People don't generally get to choose the languages they work in, the industry chooses for them. So if you don't want to work in a language you dislike, writing things like this is necessary. I tried a project in Go and really disliked it. For my personal projects, I will not start another one using it. But there are already situations where I have to write Go if I want to do my job. If I don't want that set of situations to grow I have to speak up.
• zippoxer 11y ago
  This article looks to me like a list of personal preferences presented as facts. There's much more depth to language design than what the author presents - a checklist of must-have features that are "obviously better".
• pcwalton 11y ago
  > E.g. you'll want a "match" operator. And then that means you need all statements work as expressions. And you'll have to change how zero values work, which are pervasive throughout the language. You don't need to make everything an expression for pattern matching to work. See Bjarne's C++ proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3449.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n344... You might have to change zero values, although you could make algebraic data types all be nullable if you wanted to avoid doing that.
  • evmar 11y ago
    Thanks (as always) for your informed comments! I agree that you can make pattern matching work without expressions. My intuition is rather that it's not especially useful, because you need some way to make use of the result of the match. Either you embed the rest of the function into the branch of the match statement, or you're back to stuff like: foo := ... # Some zero value ...perhaps nil? match get_foo() { Some(x) => foo = x None => return } # now use foo here That is, to make use of the result of the pattern match you need a way to get the value out of the pattern match which puts you back in the kind of code where there's no pattern match. You could make just "match" be an expression but now the arms of your match must be expressions which runs again into the problem of Go being a statement-oriented language -- for example, you might want to construct a struct in your match arm but if you can't fit the struct construction into a single expression you're stuck again. (It's a similar problem to Python's lambda.) There might be some other nice way to make this work, of course! All I am suggesting that if one does the effort of making a concrete proposal you'll find that any small feature like this brings in a bunch of related ideas (like Rust's semicolon) and is not as simple as "just add option types".
• nine_k 11y ago
  Did you have a chance to look at Kotlin? It manages to be pretty FP-friendly without being FP-front-and-center and keeping intreoperability with Java as easy as possible, and staying pretty simple. But yes, you need to rethink the design from the start. I wish it would have been done differently, less C-like, but it hadn't.
• acjohnson55 11y ago
  > (E.g. you'll want a "match" operator. And then that means you need all statements work as expressions. And you'll have to change how zero values work, which are pervasive throughout the language.) To me, that just sounds like the designers really painted themselves into a corner. I have yet to run into a situation where everything-is-an-expression feels like a problem. Am I missing something? > At some point if you really want Haskell you should just use Haskell. Or Rust. And then you will find out that those languages have problems too, and you will understand that engineering is a question of tradeoffs, not of feature checklists like this blog post. I think it's clear that Go has contributed to the conversation. In really accessible ways, it made some powerful points on the benefits of auto-formatting, fast compilation, static binaries, and so forth. But there's just so much missing of the highly productive points made by other languages, and there seems to be so little energy in the community to progress on those points. In that sense, it feels to me like Go is a bit of a dead end.
• commentzorro 11y ago
  We don't want Haskell. We don't want Rust. We don't want any of the current top twenty. We want Go-ish. We want the wonderful stuff that Go does have, but we want a few more high level features too. I suppose once that language comes along we can stop our constant whining ;-)