4 ms·

I've not looked at Rust, but I've been using Go in production now for years at this point with non-trivial code bases. In our cases, they are mostly SMTP and HT

I've not looked at Rust, but I've been using Go in production now for years at this point with non-trivial code bases. In our cases, they are mostly SMTP and HTTP servers. Sometimes the boiler plate gets in the way (and I think Go should almost never be used for simple CRUD stuff, there are better options), but I find the readability fantastic. It really dawned on my how readable it can be when I had to fix a missed condition in clean up on shutdown. It was fixed in an hour. For the perl version that the Go one replaced, it would have been a day before I even understood what would have needed fixing.

stormcrowsx 10y ago
Really not a property of Go. Any codebase can be hard to follow if the designer wants it to be. It just happened that the Perl community went off the deep end and decided that tiny unreadable code was better than big readable code.
- kbenson 10y ago
  > It just happened that the Perl community went off the deep end and decided that tiny unreadable code was better than big readable code. That's one way to look at it. The other is that they embedded more syntax which makes the learning curve longer, but yields more more efficient writing and reading of code once you've fully internalized that syntax. The big mistake, IMO, was that they also made the language easily usable to get something done before you've fully internalized those rules, which leads to subtly wrong or weird programs that just work most of the time. Perl is fundamentally different than most languages in how it uses context, but you can get away with not really understanding that at all by just learning a few rules-of-thumb. This, predictably, results in frustration in the writer, as they run up against what look like rough edges and weird idiosyncrasies in the language but are often just places where they've never actually learned how Perl really works. That's not to say Perl doesn't have actual rough points and problems (what language doesn't after almost 30 years?), but contrary to popular belief, Perl is actually highly designed, and usually conforms to a few core principles (even it those principles are not what many other languages emphasize).
  - mbrock 10y ago
    It's worth keeping in mind that Perl, like its predecessors sed and awk, was intended among other things to be useful and convenient as an embedded language in shell scripts.
ngrilly 10y ago
> I think Go should almost never be used for simple CRUD stuff Why? > there are better options Which ones?
- idobai 10y ago
  > there are better options > Which ones? Which isn't?
- goatlover 10y ago
  PHP, Ruby, Javascript, Python - pick one.
  - duaneb 10y ago
    Why are they better? Dynamic languages are orthogonal to creating CRUD apps and come with massive runtime and reading overhead.
    - goatlover 10y ago
      The overhead doesn't matter for simple CRUD stuff. The developer's time is what matters. The dynamic language are more productive.
      - duaneb 10y ago
        > The dynamic language are more productive. Do you have a source for that? I hear it a lot and I just don't buy it.
        goatlover 10y ago
        If dynamic languages require less code and less hoops to jump through with more high level abstractions available to express yourself with, then chances are they will be more productive. There is a price to pay for this expressivity in terms of performance, overhead and potential bugs not caught at compile time. This is well understood, which is why you hear it a lot. Now like most things having to do with programming, there is little empirical research backing up any language claim. As such, your anecdotal experiences might be different than the what you hear a lot. Maybe you are more productive in a statically compiled language. Maybe the metaprogramming features in a Ruby or Lisp don't make you more productive. Perhaps a more restrictive language fits your coding style and thought processes better. Or maybe you're a Haskell programmer, at which point I would defer.

stormcrowsx 10y ago

Really not a property of Go. Any codebase can be hard to follow if the designer wants it to be. It just happened that the Perl community went off the deep end and decided that tiny unreadable code was better than big readable code.

kbenson 10y ago
> It just happened that the Perl community went off the deep end and decided that tiny unreadable code was better than big readable code. That's one way to look at it. The other is that they embedded more syntax which makes the learning curve longer, but yields more more efficient writing and reading of code once you've fully internalized that syntax. The big mistake, IMO, was that they also made the language easily usable to get something done before you've fully internalized those rules, which leads to subtly wrong or weird programs that just work most of the time. Perl is fundamentally different than most languages in how it uses context, but you can get away with not really understanding that at all by just learning a few rules-of-thumb. This, predictably, results in frustration in the writer, as they run up against what look like rough edges and weird idiosyncrasies in the language but are often just places where they've never actually learned how Perl really works. That's not to say Perl doesn't have actual rough points and problems (what language doesn't after almost 30 years?), but contrary to popular belief, Perl is actually highly designed, and usually conforms to a few core principles (even it those principles are not what many other languages emphasize).
- mbrock 10y ago
  It's worth keeping in mind that Perl, like its predecessors sed and awk, was intended among other things to be useful and convenient as an embedded language in shell scripts.

ngrilly 10y ago

> I think Go should almost never be used for simple CRUD stuff Why? > there are better options Which ones?

idobai 10y ago
> there are better options > Which ones? Which isn't?
goatlover 10y ago
PHP, Ruby, Javascript, Python - pick one.
- duaneb 10y ago
  Why are they better? Dynamic languages are orthogonal to creating CRUD apps and come with massive runtime and reading overhead.
  - goatlover 10y ago
    The overhead doesn't matter for simple CRUD stuff. The developer's time is what matters. The dynamic language are more productive.
    - duaneb 10y ago
      > The dynamic language are more productive. Do you have a source for that? I hear it a lot and I just don't buy it.
      - goatlover 10y ago
        If dynamic languages require less code and less hoops to jump through with more high level abstractions available to express yourself with, then chances are they will be more productive. There is a price to pay for this expressivity in terms of performance, overhead and potential bugs not caught at compile time. This is well understood, which is why you hear it a lot. Now like most things having to do with programming, there is little empirical research backing up any language claim. As such, your anecdotal experiences might be different than the what you hear a lot. Maybe you are more productive in a statically compiled language. Maybe the metaprogramming features in a Ruby or Lisp don't make you more productive. Perhaps a more restrictive language fits your coding style and thought processes better. Or maybe you're a Haskell programmer, at which point I would defer.