4 ms·

For me it were four things: 1) no bloat 2) great tooling 3) speed, speed, speed 4) developed by legends in Computer Science To expand a little bit more: 1

by divan 4y ago

For me it were four things: 1) no bloat 2) great tooling 3) speed, speed, speed 4) developed by legends in Computer Science To expand a little bit more: 1) Go is still the only language is not developed by analogy (i.e. let's do X because all other languages have it). It's designed from the first principles, and that's why so many newcomers are buffed about weirdly different take on things they consider "basic" or "common sense". "Less is more" sounds funny for people coming from the feature-bloated languages. For me, minimalistic feature space was a breath of fresh air. I liked how Go authors see it as a vector space, with features being basis vectors (that's where "orthogonality of features" comes from in the articles about Go). Thus Go is optimized to simplify the search for the optimal path in that vector space which is a proxy for cognitive load while writing code. I'm not sure why it's noy obvious for other languages designers, but seems like "the more features - the better" narrative is rarely questioned. Go holds its stand firmly here. 2) Go tooling got it fair share of praises, and inspired other languages and frameworks to follow the same approach. Rustfmt or single binary `flutter` tool for everything are good examples. But back then in 2013 it was, again, an unusual approach that reflected some amount of thought and design put in it. (As opposed to the zoo of different commands, approaches and tools in many other languages). 3) Go was quite close to hardware – you could play with structures bit packing if you need to. Witnessing how whole companies burn cash to scale servers while using memory and CPU hungry languages (and not raising an eyebrows over that), Go seemed like a perfect choice for anything server and backend related. 4) Appeal to authority is not a logical fallacy when the authority is an actual authority. Designing a programming language requires more than CS course on compilers. Go authors had extremely deep understanding of hardware and software internals (obviously), but also had *decades* of practice in different teams, companies and even epochs. That made me trust their decisions over my initial responses. I still remember how I was mad at gofmt ("Who the hell they think they are to tell me how I want to format my code!"). Needless to say I was struck by how incredibly useful that turned to be at scale. What was never on my list of Go selling points is that it was originated in Google. Never understood this argument. I have more respect to Apple than to Google, yet I'm not writing Swift just because it's backed by company I respect more.

metaltyphoon 4y ago
> newcomers are buffed about weirdly different take on things they consider "basic" or "common sense" Yep makes sense: "2006-01-02 15:04:05"
- divan 4y ago
  Oh yes, great example. It's literally "1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6th year, 7th timezone" Clever mnemonic tecnhique which is much easier to use and memorize. Most people can remember "January 2nd 2006" and "15:04:05" easily, and then crafting date/time format strings becomes a toy. While with more widespread and common "HH/MM/SS" approach, which has bunch of incompatible implementations in different languages, you have to constantly do mental gymnastics remembering if "MM" means minutes or months, and whether "Y" or "yyyy" represents full year. Format string "D m y", for example, produces: - 'Tue 05 22' in PHP - '05/31/22 05 22' in Ruby and Rust - 'D 40 22' in .Net - '151 23 2022' in Dart and Swift I have no idea how such a messy and suboptimal approach to date formatting even makes sense to people. But of course, many people are bashing Go date formatting simply because it's not what they used to in other languages.
  - aniforprez 4y ago
    It's a really dumb date because it's so easy to just pick a date that was greater than 12 to easily make out that something is a date and not a month. As it is, 01-02 could literally be anything. I much prefer strftime formats to Go's inane date formatting thing. I find it MUCH easier to simply remember "dd-mm-YYYY" (which is about the only format I use almost 99% of the time) than the specific date they're looking for. I don't really care if something is different in other languages. I'm already context switching and it's easy to look this up
  - dragonwriter 4y ago
    > 1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6th year, 7th timezone Which, would be intuitive and easy to remember if month-day-hour-minute-second-year-timezone was a sane logical ordering. > Format string "D m y", for example, produces: > - '05/31/22 05 22' in Ruby and Rust How are you doing that in Ruby? The standard Ruby DateTime formatting method is DateTime#strftime() which uses approximately (mostly, fixing the locale-dependent options because the method is not locale sensitive) POSIX strftime format strings, which that is not. Did you mean “%D %m %y”? Then that's right for Ruby/Rust. But that doesn't seem to produce the results you list for other languages (some of which also have a POSIX-ish strftime, though, e.g., it is deprecated in PHP.)

by divan 4y ago

metaltyphoon 4y ago

> newcomers are buffed about weirdly different take on things they consider "basic" or "common sense" Yep makes sense: "2006-01-02 15:04:05"

divan 4y ago
Oh yes, great example. It's literally "1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6th year, 7th timezone" Clever mnemonic tecnhique which is much easier to use and memorize. Most people can remember "January 2nd 2006" and "15:04:05" easily, and then crafting date/time format strings becomes a toy. While with more widespread and common "HH/MM/SS" approach, which has bunch of incompatible implementations in different languages, you have to constantly do mental gymnastics remembering if "MM" means minutes or months, and whether "Y" or "yyyy" represents full year. Format string "D m y", for example, produces: - 'Tue 05 22' in PHP - '05/31/22 05 22' in Ruby and Rust - 'D 40 22' in .Net - '151 23 2022' in Dart and Swift I have no idea how such a messy and suboptimal approach to date formatting even makes sense to people. But of course, many people are bashing Go date formatting simply because it's not what they used to in other languages.
- aniforprez 4y ago
  It's a really dumb date because it's so easy to just pick a date that was greater than 12 to easily make out that something is a date and not a month. As it is, 01-02 could literally be anything. I much prefer strftime formats to Go's inane date formatting thing. I find it MUCH easier to simply remember "dd-mm-YYYY" (which is about the only format I use almost 99% of the time) than the specific date they're looking for. I don't really care if something is different in other languages. I'm already context switching and it's easy to look this up
- dragonwriter 4y ago
  > 1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6th year, 7th timezone Which, would be intuitive and easy to remember if month-day-hour-minute-second-year-timezone was a sane logical ordering. > Format string "D m y", for example, produces: > - '05/31/22 05 22' in Ruby and Rust How are you doing that in Ruby? The standard Ruby DateTime formatting method is DateTime#strftime() which uses approximately (mostly, fixing the locale-dependent options because the method is not locale sensitive) POSIX strftime format strings, which that is not. Did you mean “%D %m %y”? Then that's right for Ruby/Rust. But that doesn't seem to produce the results you list for other languages (some of which also have a POSIX-ish strftime, though, e.g., it is deprecated in PHP.)