3 ms·

This is the killer feature of Go, and it's what so many who clamor for various features-of-other-languages miss. Go is designed for simplicity. It is easy to w

This is the killer feature of Go, and it's what so many who clamor for various features-of-other-languages miss. Go is designed for simplicity. It is easy to write, but more importantly is easy to understand, even far in the future. For a given problem, n programmers will generally coalesce on a small number of possible Go implementations, whereas other languages will often yield n divergent solutions. I've had Go solutions that I built years ago that I can get into and maintain in seconds, even when I hadn't touched Go in months. Go isn't my primary tooling (my life today is mostly Swift), but as a comparison where a language has gone awry I'd point to C# -- as Microsoft has tried to incorporate whatever cool thing every other language has added, C# projects have often turned into write-only projects where the original author barely can grok their code a month later, and everyone shrugs and says "rewrite it" when confronted with another programmer's C# code. Rust is much the same.

pcwalton 7y ago
Can you give an example of Rust incorporating "whatever cool thing every other language has added"? I have never had the experience of Rust code becoming write-only after a month, and I don't know anyone else who has either.
- endorphone 7y ago
  That statement was clearly in reference to C#, which evolved from a beautifully concise language to now being a mishmash of every other style of programming (including the abomination that is LINQ). Rust, though, suffers from being too clever, making it a language in which you can make concise, powerful solutions, but it can making grokking the code difficult, inefficient and error prone. This is where our egos step forward and we announce that it's No Problem For Me, but we've all experienced a situation where we've leveraged a powerful language to do some amazing things, and then a month later it is a gruelling, headache inducing experience trying to figure out what is doing what, where, so we announce that we'll just rewrite the whole thing.
  - pcwalton 7y ago
    > Rust, though, suffers from being too clever, making it a language in which you can make concise, powerful solutions, but it can making grokking the code difficult, inefficient and error prone. Can you explain specifically how Rust is supposedly too clever?
    - endorphone 7y ago
      With all due respect, I don't think you're in a position to have a unbiased perspective on this, and I am certain I'm never going to convince you. But I'll leave it that there have been countless "Rust is too difficult" links for you to find on Google, many of which have been posted on here. And invariably when we discuss Rust the conversation goes like this- "why is it so complex to do [some simple thing]?" "Oh well Rust is a System Programming Language, and it's doing important things in important ways" "Okay, but I'm not building an OS, I'm just..." [chest puffing, ego's appear, etc] "Well I certainly have no problem with it..."
      - pcwalton 7y ago
        I still can't figure out exactly what design decisions you disagree with, but it sounds like you're objecting to the lack of GC or memory safety. There are some applications for which GC is not appropriate. Maybe you don't work on any of those applications. That's fine, but that's very different from saying Rust is overly complicated.
        helper 7y ago
        I think this is a great point that indirectly highlights how people are often talking past each other when a go vs rust debate comes up. People work in different problem domains with different constraints and therefore the a good language choice in one domain might be wrong for the other. I don't think anyone in the go community would suggest you write a browser in go. Ignoring the GC performance issues, just the awkwardness of using cgo would make most go developers shudder. Likewise there are many problem domains where a GC'ed language works just fine. In these cases it is appropriate to consider other factors when deciding which language to use. Perhaps your team is made up of a bunch of experienced scala developers, scala might be a good choice for you over go or rust. That doesn't mean your good choice is universally applicable to all teams. Some teams might care more about getting the most value per cpu cycle possible. Other teams might care more about the time it takes to get a new engineer up to speed in the language. Both of these can be valid reasons to choose a specific language. I guess what I'm trying to say is: "Try to choose the language (and other tools) that best matches your organizations constraints. Don't assume that other teams have the same constraints."

pcwalton 7y ago

Can you give an example of Rust incorporating "whatever cool thing every other language has added"? I have never had the experience of Rust code becoming write-only after a month, and I don't know anyone else who has either.

endorphone 7y ago
That statement was clearly in reference to C#, which evolved from a beautifully concise language to now being a mishmash of every other style of programming (including the abomination that is LINQ). Rust, though, suffers from being too clever, making it a language in which you can make concise, powerful solutions, but it can making grokking the code difficult, inefficient and error prone. This is where our egos step forward and we announce that it's No Problem For Me, but we've all experienced a situation where we've leveraged a powerful language to do some amazing things, and then a month later it is a gruelling, headache inducing experience trying to figure out what is doing what, where, so we announce that we'll just rewrite the whole thing.
- pcwalton 7y ago
  > Rust, though, suffers from being too clever, making it a language in which you can make concise, powerful solutions, but it can making grokking the code difficult, inefficient and error prone. Can you explain specifically how Rust is supposedly too clever?
  - endorphone 7y ago
    With all due respect, I don't think you're in a position to have a unbiased perspective on this, and I am certain I'm never going to convince you. But I'll leave it that there have been countless "Rust is too difficult" links for you to find on Google, many of which have been posted on here. And invariably when we discuss Rust the conversation goes like this- "why is it so complex to do [some simple thing]?" "Oh well Rust is a System Programming Language, and it's doing important things in important ways" "Okay, but I'm not building an OS, I'm just..." [chest puffing, ego's appear, etc] "Well I certainly have no problem with it..."
    - pcwalton 7y ago
      I still can't figure out exactly what design decisions you disagree with, but it sounds like you're objecting to the lack of GC or memory safety. There are some applications for which GC is not appropriate. Maybe you don't work on any of those applications. That's fine, but that's very different from saying Rust is overly complicated.
      - helper 7y ago
        I think this is a great point that indirectly highlights how people are often talking past each other when a go vs rust debate comes up. People work in different problem domains with different constraints and therefore the a good language choice in one domain might be wrong for the other. I don't think anyone in the go community would suggest you write a browser in go. Ignoring the GC performance issues, just the awkwardness of using cgo would make most go developers shudder. Likewise there are many problem domains where a GC'ed language works just fine. In these cases it is appropriate to consider other factors when deciding which language to use. Perhaps your team is made up of a bunch of experienced scala developers, scala might be a good choice for you over go or rust. That doesn't mean your good choice is universally applicable to all teams. Some teams might care more about getting the most value per cpu cycle possible. Other teams might care more about the time it takes to get a new engineer up to speed in the language. Both of these can be valid reasons to choose a specific language. I guess what I'm trying to say is: "Try to choose the language (and other tools) that best matches your organizations constraints. Don't assume that other teams have the same constraints."