3 ms·

Coming from a scripting language background Go was like moving into the future: concurrency primitives, static linking, channels, fast compile times, awesome st

Coming from a scripting language background Go was like moving into the future: concurrency primitives, static linking, channels, fast compile times, awesome standard lib. Not to mention the fact that go fmt makes everyone’s code look exactly the same. No more weird, personal styles being brought into into source code or pointless discussions of naming conventions or indentation.

coldtea 9y ago
Concurrency primitives maybe (though languages had those for 20 years too). But what about static linking, fast compile times and awesome standard lib is like "stepping into the feature"?
- matt_wulfeck 9y ago
  Static linking: no more futzing around with package nightmares on systems. Making sure system packages are present so python virtualenv can install. Static linking makes portability a breeze. I don’t know why this idea was lost in virtually every scripting language from the past 20 years. Standard lib is just plain awesome. You can build most things right out of the box without searching the web for competing versions of the same thing. Web apps are a great example. Fast compile times was a feature built into Go from the beginning. Presumably from people frustrated by compile times of large C/C++ codebases [1]. It’s about developer productivity. 1. https://golang.org/doc/faq#What_compiler_technology_is_used_to_build_the_compilers https://golang.org/doc/faq#What_compiler_technology_is_used_...
  - uranusjr 9y ago
    > Static linking makes portability a breeze. I don’t know why this idea was lost in virtually every scripting language from the past 20 years. Because they are invented at a time before storage and RAM is dirt cheap and lightning fast. It was painfully wasteful and slow to load a copy of the standard library for every process. Dynamic linking was invented basically because static linking wasn’t feasible.

coldtea 9y ago

Concurrency primitives maybe (though languages had those for 20 years too). But what about static linking, fast compile times and awesome standard lib is like "stepping into the feature"?

matt_wulfeck 9y ago
Static linking: no more futzing around with package nightmares on systems. Making sure system packages are present so python virtualenv can install. Static linking makes portability a breeze. I don’t know why this idea was lost in virtually every scripting language from the past 20 years. Standard lib is just plain awesome. You can build most things right out of the box without searching the web for competing versions of the same thing. Web apps are a great example. Fast compile times was a feature built into Go from the beginning. Presumably from people frustrated by compile times of large C/C++ codebases [1]. It’s about developer productivity. 1. https://golang.org/doc/faq#What_compiler_technology_is_used_to_build_the_compilers https://golang.org/doc/faq#What_compiler_technology_is_used_...
- uranusjr 9y ago
  > Static linking makes portability a breeze. I don’t know why this idea was lost in virtually every scripting language from the past 20 years. Because they are invented at a time before storage and RAM is dirt cheap and lightning fast. It was painfully wasteful and slow to load a copy of the standard library for every process. Dynamic linking was invented basically because static linking wasn’t feasible.