4 ms·

I actually don't think this is true, which is kind of nuts. Programming languages generally fall into two categories: 1) They were either designed by one or tw

I actually don't think this is true, which is kind of nuts. Programming languages generally fall into two categories: 1) They were either designed by one or two eccentrics, and thus contain a few great guiding principles and many questionable ideas, which invariably come back to bite large projects; or, 2) They were designed by a committee who tried to make the Final Universal Language that would solve every possible problem, resulting in a kitchen-sink mess of a language with a 400-page specification that no one reads. Most mainstream languages made some attempt to serve software-at-scale; for example, OO used to be the obvious thing that would make software more maintainable, so most languages support it at least in part. But if you look at a language like C++, it's obvious that many of its features were added simply because they were cool or increased expressiveness (e.g. operator overloading) without regard for long-term maintainability. Even things as mundane as "implicit 'this'" are clearly harmful to readability, with specious benefit. AFAIK, Go is the only language that really takes engineering seriously: https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article If there are similar articles for other mainstream languages, I'm certainly curious to read them and see how they hold up today!

gher-shyu3i 5y ago
> https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article The shortcomings listed in that talk are mainly against C and C++. Other serious languages and platforms like Java, C#, and also Rust have solved these issues.
gameswithgo 5y ago
I think what is actually going on is that Rob Pike's ideas about how software engineering should work resonate strongly with you, while Anders Hejlsberg, Don Syme, James Gosling, Christ Lattner, and Rich Hinkey does not resonate with you. I think it would be a difficult argument to suggest that those other people do not have similar engineering chops, or haven't been around a long time. But if you are right we should see Go winning in the marketplace more and more in the future in a way unprecedented for programming languages.
- nemo1618 5y ago
  I don't mean to suggest that at all -- I have great respect for those people, particularly Rich Hickey, whose framing of "simple" vs "easy" is vital to these discussions. But it's clear that a language like Clojure is not a good fit for million-line, decades-old codebases. Java wasn't explicitly designed for large-scale engineering either; it's north star was Write Once, Run Anywhere. In short, I think there are very few languages that prioritize engineering to the exclusion of other features, and Go is one of them. Ada is another; it was explicitly designed for large-scale engineering, but hasn't seen nearly as much success as Go. I'd like to learn more about why it failed. Perhaps it was the language itself, or maybe it was merely a timing issue, or the fact that it was backed by the government. This comment has some good info: https://news.ycombinator.com/item?id=7825008 https://news.ycombinator.com/item?id=7825008
  - Jtsummers 5y ago
    Why Ada failed has been discussed ad nauseum including on here. Early compilers were $$,$$$ per seat and proprietary, they're still easily $,$$$ per seat. Good open source compilers came later, there's still a strong disparity between the FOSS and commercial compilers and tooling. The language was a mandate from US DOD which rubbed a lot of people the wrong way. It largely sat in the same space as Fortran and C, C was free (or much less expensive) and more readily available even when it did cost. Cosmetic: People strongly dislike the verbosity of Ada. Some parts are reasonable to consider changing (but really are just cosmetic) like begin/end versus {/}. Other verbose portions are hard to change without fundamentally altering the language. You want to print integers and strings and you don't want to have to use Integer'Image(X) all over the place? with Text_IO; use Text_IO; with Ada.Integer_Text_IO; use Ada.Integer_Text_IO; Now Put and Put_Line can be used with both strings and integers. Oh, you want to print more types? More withing for you. I don't mind it, you don't need to print in every package, but it is very cumbersome. If you want to write a quick CLI tool, Ada is not your language (though I've done it), go for Perl, Python, Ruby, sh/bash, or even Go. C and C++ can be easier for that purpose. But once you start scaling it's a very good language. The only way to get Ada in the mainstream now is to make it much cheaper and greatly improve the FOSS compilers and tooling, and have SPARK/Ada support an increasingly large subset including approaching feature parity with respect to memory safety as Rust. That's being worked on, but it's a non-trivial problem.
monoideism 5y ago
> AFAIK, Go is the only language that really takes engineering seriously: Ada is the consummate engineer's programming language. And with Spark, even more so. Unfortunately, the compilers were super expensive at a critical stage in its evolution. And the DoD thing. And I've never used Rust professionally (unlike Go), but it has all the applicable points in the article you list (obviously no garbage collection). But in Rust, these features are often implemented in a more robust manner than in Go (eg, like Go, Rust avoids exceptions and uses error values, but instead of returning a special-cased interface, it returns a regular sum type, which allows for proper type checking of the error handling, and which is also composable since it's also a monad). And unlike Go, Rust got package management down from the start. Go's package management has gotten better, but it's still not as good as Rust's through Cargo (to be fair, Cargo is best of class).

gher-shyu3i 5y ago

> https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article The shortcomings listed in that talk are mainly against C and C++. Other serious languages and platforms like Java, C#, and also Rust have solved these issues.

gameswithgo 5y ago

I think what is actually going on is that Rob Pike's ideas about how software engineering should work resonate strongly with you, while Anders Hejlsberg, Don Syme, James Gosling, Christ Lattner, and Rich Hinkey does not resonate with you. I think it would be a difficult argument to suggest that those other people do not have similar engineering chops, or haven't been around a long time. But if you are right we should see Go winning in the marketplace more and more in the future in a way unprecedented for programming languages.

nemo1618 5y ago
I don't mean to suggest that at all -- I have great respect for those people, particularly Rich Hickey, whose framing of "simple" vs "easy" is vital to these discussions. But it's clear that a language like Clojure is not a good fit for million-line, decades-old codebases. Java wasn't explicitly designed for large-scale engineering either; it's north star was Write Once, Run Anywhere. In short, I think there are very few languages that prioritize engineering to the exclusion of other features, and Go is one of them. Ada is another; it was explicitly designed for large-scale engineering, but hasn't seen nearly as much success as Go. I'd like to learn more about why it failed. Perhaps it was the language itself, or maybe it was merely a timing issue, or the fact that it was backed by the government. This comment has some good info: https://news.ycombinator.com/item?id=7825008 https://news.ycombinator.com/item?id=7825008
- Jtsummers 5y ago
  Why Ada failed has been discussed ad nauseum including on here. Early compilers were $$,$$$ per seat and proprietary, they're still easily $,$$$ per seat. Good open source compilers came later, there's still a strong disparity between the FOSS and commercial compilers and tooling. The language was a mandate from US DOD which rubbed a lot of people the wrong way. It largely sat in the same space as Fortran and C, C was free (or much less expensive) and more readily available even when it did cost. Cosmetic: People strongly dislike the verbosity of Ada. Some parts are reasonable to consider changing (but really are just cosmetic) like begin/end versus {/}. Other verbose portions are hard to change without fundamentally altering the language. You want to print integers and strings and you don't want to have to use Integer'Image(X) all over the place? with Text_IO; use Text_IO; with Ada.Integer_Text_IO; use Ada.Integer_Text_IO; Now Put and Put_Line can be used with both strings and integers. Oh, you want to print more types? More withing for you. I don't mind it, you don't need to print in every package, but it is very cumbersome. If you want to write a quick CLI tool, Ada is not your language (though I've done it), go for Perl, Python, Ruby, sh/bash, or even Go. C and C++ can be easier for that purpose. But once you start scaling it's a very good language. The only way to get Ada in the mainstream now is to make it much cheaper and greatly improve the FOSS compilers and tooling, and have SPARK/Ada support an increasingly large subset including approaching feature parity with respect to memory safety as Rust. That's being worked on, but it's a non-trivial problem.

monoideism 5y ago

> AFAIK, Go is the only language that really takes engineering seriously: Ada is the consummate engineer's programming language. And with Spark, even more so. Unfortunately, the compilers were super expensive at a critical stage in its evolution. And the DoD thing. And I've never used Rust professionally (unlike Go), but it has all the applicable points in the article you list (obviously no garbage collection). But in Rust, these features are often implemented in a more robust manner than in Go (eg, like Go, Rust avoids exceptions and uses error values, but instead of returning a special-cased interface, it returns a regular sum type, which allows for proper type checking of the error handling, and which is also composable since it's also a monad). And unlike Go, Rust got package management down from the start. Go's package management has gotten better, but it's still not as good as Rust's through Cargo (to be fair, Cargo is best of class).