6 ms·

This has been discussed ad nauseum but there exists a group of developers who value other language features, such as ease of deployment, readability, compile ti

This has been discussed ad nauseum but there exists a group of developers who value other language features, such as ease of deployment, readability, compile time, language simplicity, toolchain simplicity, maintainability, etc etc For these developers Go can be a good fit. Everybody knows it doesn't have feature parity with Haskell et al from a computer science perspective. If that's all that mattered we would be seeing a lot of Haskell adoption wouldn't we? You shouldn't pick a language based on a checklist.

coldtea 12y ago
>This has been discussed ad nauseum but there exists a group of developers who value other language features, such as ease of deployment, readability, compile time, language simplicity, toolchain simplicity, maintainability, etc etc All of which are orthogonal to having a more modern language, except maybe simplicity. And even for that, after a while you understand that not having, say, generics, pattern matching or some such language feature, is not "simpler" is just having to do more busywork manually and in an error prone way. There's simplicity as in "this is simple to understand and use" and simplicity as in "we ommited some advanced functionality and you'll have to built it by yourself, every time". The second is a false simplicity. As Einstein put it: "we should make things as simple as possible, but not simpler". Pointing to a specific point were making something simpler makes it lose the essense it should have.
- NateDad 12y ago
  It is simpler. It's like comparing English to German. Sure, in German you can just say "schadenfreude" and in English you have to say "taking joy from someone else's misfortune", but everyone will understand the latter, and many people may misunderstand the former... And even though you may feel smarter for being able to use a big word, if you are writing a legal document that needs to be understood by many people, you're probably better off with the more wordy English.
  - coldtea 12y ago
    >but everyone will understand the latter, and many people may misunderstand the former... And the analogy breaks in that all German speakers will understand the former.
- zzzcpan 12y ago
  > There's simplicity as in "this is simple to understand and use" Yeah, it's a known fallacy. We should replace "simplicity" and "readability" with understandability, since we don't really care about the first two, but only confuse people.
copsarebastards 12y ago
Ease of deployment: the first and hardest deployment step is creating code worth deploying. Readability: I'm pretty sure having to create copies of container classes for each thing they can contain, or casting in and out of object, or wrapping all your contained classes in an interface, is less readable than generics, not more readable. Compile time: this is an overblown concern. If you're using a compilation system that compiles only the parts you change, your typical compilation should be so quick as to take negligible time. Complete rebuilds such as on a CI server should be happening asynchronously to development and therefore should only cost server time, which is of negligible value in comparison with development time. If your builds are taking so long that server time becomes an issue, your code has built up too much cruft and it's time to refactor to reduce your size (failure to do this will cause much bigger problems than slow compilation). Language simplicity: I'm pretty sure having to create copies of container classes for each thing they can contain, or casting in and out of object, or wrapping all your contained classes in an interface, is less simple than generics, not more simple. Toolchain simplicity: I am not able rightly to apprehend the kind of confusion of ideas that could provoke someone to think this is relevant. Maintainability: I'm pretty sure having to create copies of container classes for each thing they can contain, or casting in and out of object, or wrapping all your contained classes in an interface, is less maintainable than generics, not more maintainable.
- scott_s 12y ago
  Before you dismiss compile time as "an overblown concern", I recommend reading Rob Pike's paper version of his talk, "Language Design in the Service of Software Engineering" (http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article). In particular, take a look at section 5, "Dependencies in C and C++." From that section: The construction of a single C++ binary at Google can open and read hundreds of individual header files tens of thousands of times. In 2007, build engineers at Google instrumented the compilation of a major Google binary. The file contained about two thousand files that, if simply concatenated together, totaled 4.2 megabytes. By the time the #includes had been expanded, over 8 gigabytes were being delivered to the input of the compiler, a blow-up of 2000 bytes for every C++ source byte. As another data point, in 2003 Google's build system was moved from a single Makefile to a per-directory design with better-managed, more explicit dependencies. A typical binary shrank about 40% in file size, just from having more accurate dependencies recorded. Even so, the properties of C++ (or C for that matter) make it impractical to verify those dependencies automatically, and today we still do not have an accurate understanding of the dependency requirements of large Google C++ binaries. The consequence of these uncontrolled dependencies and massive scale is that it is impractical to build Google server binaries on a single computer, so a large distributed compilation system was created. With this system, involving many machines, much caching, and much complexity (the build system is a large program in its own right), builds at Google are practical, if still cumbersome. I think that Pike makes a convincing case that fast compile times at scale are a reasonable requirement for their needs.

coldtea 12y ago

>This has been discussed ad nauseum but there exists a group of developers who value other language features, such as ease of deployment, readability, compile time, language simplicity, toolchain simplicity, maintainability, etc etc All of which are orthogonal to having a more modern language, except maybe simplicity. And even for that, after a while you understand that not having, say, generics, pattern matching or some such language feature, is not "simpler" is just having to do more busywork manually and in an error prone way. There's simplicity as in "this is simple to understand and use" and simplicity as in "we ommited some advanced functionality and you'll have to built it by yourself, every time". The second is a false simplicity. As Einstein put it: "we should make things as simple as possible, but not simpler". Pointing to a specific point were making something simpler makes it lose the essense it should have.

NateDad 12y ago
It is simpler. It's like comparing English to German. Sure, in German you can just say "schadenfreude" and in English you have to say "taking joy from someone else's misfortune", but everyone will understand the latter, and many people may misunderstand the former... And even though you may feel smarter for being able to use a big word, if you are writing a legal document that needs to be understood by many people, you're probably better off with the more wordy English.
- coldtea 12y ago
  >but everyone will understand the latter, and many people may misunderstand the former... And the analogy breaks in that all German speakers will understand the former.
zzzcpan 12y ago
> There's simplicity as in "this is simple to understand and use" Yeah, it's a known fallacy. We should replace "simplicity" and "readability" with understandability, since we don't really care about the first two, but only confuse people.

copsarebastards 12y ago

Ease of deployment: the first and hardest deployment step is creating code worth deploying. Readability: I'm pretty sure having to create copies of container classes for each thing they can contain, or casting in and out of object, or wrapping all your contained classes in an interface, is less readable than generics, not more readable. Compile time: this is an overblown concern. If you're using a compilation system that compiles only the parts you change, your typical compilation should be so quick as to take negligible time. Complete rebuilds such as on a CI server should be happening asynchronously to development and therefore should only cost server time, which is of negligible value in comparison with development time. If your builds are taking so long that server time becomes an issue, your code has built up too much cruft and it's time to refactor to reduce your size (failure to do this will cause much bigger problems than slow compilation). Language simplicity: I'm pretty sure having to create copies of container classes for each thing they can contain, or casting in and out of object, or wrapping all your contained classes in an interface, is less simple than generics, not more simple. Toolchain simplicity: I am not able rightly to apprehend the kind of confusion of ideas that could provoke someone to think this is relevant. Maintainability: I'm pretty sure having to create copies of container classes for each thing they can contain, or casting in and out of object, or wrapping all your contained classes in an interface, is less maintainable than generics, not more maintainable.

scott_s 12y ago
Before you dismiss compile time as "an overblown concern", I recommend reading Rob Pike's paper version of his talk, "Language Design in the Service of Software Engineering" (http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article). In particular, take a look at section 5, "Dependencies in C and C++." From that section: The construction of a single C++ binary at Google can open and read hundreds of individual header files tens of thousands of times. In 2007, build engineers at Google instrumented the compilation of a major Google binary. The file contained about two thousand files that, if simply concatenated together, totaled 4.2 megabytes. By the time the #includes had been expanded, over 8 gigabytes were being delivered to the input of the compiler, a blow-up of 2000 bytes for every C++ source byte. As another data point, in 2003 Google's build system was moved from a single Makefile to a per-directory design with better-managed, more explicit dependencies. A typical binary shrank about 40% in file size, just from having more accurate dependencies recorded. Even so, the properties of C++ (or C for that matter) make it impractical to verify those dependencies automatically, and today we still do not have an accurate understanding of the dependency requirements of large Google C++ binaries. The consequence of these uncontrolled dependencies and massive scale is that it is impractical to build Google server binaries on a single computer, so a large distributed compilation system was created. With this system, involving many machines, much caching, and much complexity (the build system is a large program in its own right), builds at Google are practical, if still cumbersome. I think that Pike makes a convincing case that fast compile times at scale are a reasonable requirement for their needs.