8 ms·

It seems reasonable to argue the exact opposite: (edit: for clarification, I think this argument is roughly equal in strength to the parent. My bias is defini

It seems reasonable to argue the exact opposite: (edit: for clarification, I think this argument is roughly equal in strength to the parent. My bias is definitely showing, but my main point is that knowing which will be true is hard.) Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans. It mostly remixes what has proven to work into a cohesive package. It's only as large as it absolutely needs to be (so new devs can learn it quickly), and has a strong focus on developer UX (gofmt, build speed, godoc). Rust on the other hand is a far more ambitious language. It's trying to statically solve many types of problems which are typically solved through testing and experience. Using Rust productively requires much more Rust specific learning. With how Rust is changing and having multiple approaches to things as the language is defined, long living code bases are going to accrue different methodologies from whatever was popular when each component was written. I think in 10 years a few experienced devs will do to Rust what Go did to C: Take the bits that obviously worked well, add a few ideas from other languages to soften some rough corners, and present it is a smaller, easy to use package. Though I also in general hope old languages are being replaced by new languages, as that must happen if as an industry we are getting better at building software. But also because I'm making a programming language and I have to believe I've found room for improvement for that to be a good idea.

gameswithgo 5y ago
>Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans. So have all languages, with wildly different philosophies about how to do that. We collectively just don't have any idea what we are doing. Clearly nobody has stumbled on a big win or one particular language would start dominating the industry due to the productivity bump.
- deleted 5y ago
  [deleted]
- BobbyJo 5y ago
  >So have all languages, with wildly different philosophies about how to do that. I think what you refer to as differing philosophies are in fact differing goals, and the goal of Golang is very different from pretty much all other modern languages: simplicity. I think boiling everything down to 'they are all trying to do it better' misses the fact that the 'it' they are trying to do better is very different in some cases.
  - gher-shyu3i 5y ago
    > simplicity This has to be quantified. Simplicity in the language, perhaps. It definitely does not translate into simplicity of resulting programs, and the ease of being able to reason about them, or write them.
    - BobbyJo 5y ago
      Having spent about 3 years each in Java, C++ and Golang, and getting a good amount of time with Python, I have to disagree with your final few points. Golang's simplicity in the spec itself DEFINITELY gives down stream benefits, simplifying a lot more beyond itself. That includes writing and reasoning about code.
      - gher-shyu3i 5y ago
        Having worked on several large golang code bases, its verbosity is tedious to deal with. It doesn't lend well to IDEs (e.g. it's so easy for a struct to accidentally implement interfaces it doesn't mean to because of structural typing). Error handling is always a mess, it doesn't have enums, and so many issues to list here that Java doesn't have. The golang authors' weird obsession with not having any methods on strings for example, makes it horrendous to work with them (e.g. can't chain someString.trim().toUpper().endsWith("...")). Don't get me started on the supposed fast compile times. Parsing is fast (but so almost any other language that is not C++ or Scala), but linking is horrendously slow. Modifying and re-running individual unit tests takes seconds at a time due to relinking. In Java, it's in a blink of an eye because there is no linking.
- bccdee 5y ago
  > Clearly nobody has stumbled on a big win or one particular language would start dominating the industry due to the productivity bump. This is what happened with Python. It provided a distinct productivity advantage over C & C++, and now no one writes web apps in C++ anymore. Granted, it's not just Python anymore, but newer languages learned from Python's success.
  - gameswithgo 5y ago
    Garbage collection got a clear productivity gain over not garbage collection. But it isn't clear that the various takes on GC languages, Python, Java, C#, Go etc have led to any one clear winner.
    - ska 5y ago
      > Python, Java, C#, Notably, we've had garbage collection for nearly as long as we've had programming languages - so this has been going on much longer than the examples you give would suggest.
    - bccdee 5y ago
      I'd argue that Java ultimately failed to innovate over C++ in the way that Python did. It added GC, but it's still clunky and hard to work with. In that sense, it's more of a pre-Python language, even though it's a few years younger than Python.
  - jokethrowaway 5y ago
    First we had web apps written in Java, then Perl, PHP. Python's popularity for web app development came way later (django was released in 2005)
    - bccdee 5y ago
      Python was originally written as a reaction to C & C++. It didn't really hit the mainstream for web apps until much later, granted, but when we compare it to the languages it was originally competing against, the difference is pretty clear.
- michael1999 5y ago
  I don't think you mean that, or you misunderstand how Javascript or PHP came to be.
  - gameswithgo 5y ago
    If I didn't understand how javascript came to be, I would be suggesting that javascript must be the best language!
- nemo1618 5y ago
  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.
    - 5y ago
coldtea 5y ago
>Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans. Several quite opinionated industry titans who appeared to ignore most things they didn't themselves invent in AT&T for UNIX or in Plan 9, and based on their own preconceptions of "programming at scale" as a pet project (not based some formal Google-initiated research on its practical needs). Algol and ADA were indeed created by "experience of several industry titans", in a process examining the field of applications and use cases for the languages. Go was not really that, whatever the story says.
- AnimalMuppet 5y ago
  > and based on their own preconceptions of "programming at scale" as a pet project Based on their experience working at Google. It wasn't just "preconceptions". (True, it also wasn't an examination of the field of the form that led to Algol and Ada, but it wasn't just preconceptions, either.)
  - coldtea 5y ago
    >Based on their experience working at Google. Yes, but that's their experience working at Google as 30+ years industry veterans and thought leaders (one would guess, mostly left to do their own thing, as prestige hires). Not as regular developers doing everyday Google grunt-work...
    - AnimalMuppet 5y ago
      Well, the founding myth of go says that it started from a conversation during a 45 minute C++ compile. I doubt that that was Rob Pike's personal "thing" project - he hadn't been there long enough to have a personal project that size. That was some big multi-person multi-year thing.
      - srparish 5y ago
        They had the limbo language in plan9, which has similar features and quirks. It seems most probable that the outcome of the 45 minute conversation wasn't "let's build a language from scratch", but rather "let's iterate on limbo".
gher-shyu3i 5y ago
> Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans This claim keeps getting repeated with absolutely nothing to back it up, other than repeating what the golang authors claimed. I work on a large golang code base, and it's quite horrid. The IDE experience is terrible. It's hard to navigate the code base, due to things like types unintentionally implementing interfaces because they happen to match on some of their function declarations. No proper visibility rules (only "public" and "package private"). interface{} everywhere because of no generics (I'm aware that's being worked on). Single character variable names are popular because the golang authors write code that way and it's seen as "smart". No reserved "this" or "self" keyword to declare methods means that every type will have its own single letter self variable which you have to look up every time. Error handling is terrible, and I've seen many insidious cases of mishandled errors. Null pointers are still a thing. The list goes on. Edit: not to mention things like the language is against quick prototyping (heavy friction due to things like unnused imports or variables, and a very verbose language), as well as the lack of mature libraries such as JDBI or Dapper.
- ikiris 5y ago
  This sounds like really bad code was allowed to be checked in, not the fault of the language. You can make terrible code in almost any language. The above does not match my experience in maintaining large go codebases because of proper code reviews and expectation of writing maintainable code.
  - gher-shyu3i 5y ago
    Nope, we have a very rigorous linting and review process. It's the shortcomings of the language.
    - ikiris 5y ago
      how are your complaints about your bad variable names shortcomings of the language and not the code you accept?
jokethrowaway 5y ago
From my experience having to debug and fix up / change things in old go codebases, it's an absolute nightmare. The lack of abstractions often force you to read a lot of code you don't care about. The language is so simple that reading complex code is actually hard.

gameswithgo 5y ago

>Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans. So have all languages, with wildly different philosophies about how to do that. We collectively just don't have any idea what we are doing. Clearly nobody has stumbled on a big win or one particular language would start dominating the industry due to the productivity bump.

deleted 5y ago
[deleted]
BobbyJo 5y ago
>So have all languages, with wildly different philosophies about how to do that. I think what you refer to as differing philosophies are in fact differing goals, and the goal of Golang is very different from pretty much all other modern languages: simplicity. I think boiling everything down to 'they are all trying to do it better' misses the fact that the 'it' they are trying to do better is very different in some cases.
- gher-shyu3i 5y ago
  > simplicity This has to be quantified. Simplicity in the language, perhaps. It definitely does not translate into simplicity of resulting programs, and the ease of being able to reason about them, or write them.
  - BobbyJo 5y ago
    Having spent about 3 years each in Java, C++ and Golang, and getting a good amount of time with Python, I have to disagree with your final few points. Golang's simplicity in the spec itself DEFINITELY gives down stream benefits, simplifying a lot more beyond itself. That includes writing and reasoning about code.
    - gher-shyu3i 5y ago
      Having worked on several large golang code bases, its verbosity is tedious to deal with. It doesn't lend well to IDEs (e.g. it's so easy for a struct to accidentally implement interfaces it doesn't mean to because of structural typing). Error handling is always a mess, it doesn't have enums, and so many issues to list here that Java doesn't have. The golang authors' weird obsession with not having any methods on strings for example, makes it horrendous to work with them (e.g. can't chain someString.trim().toUpper().endsWith("...")). Don't get me started on the supposed fast compile times. Parsing is fast (but so almost any other language that is not C++ or Scala), but linking is horrendously slow. Modifying and re-running individual unit tests takes seconds at a time due to relinking. In Java, it's in a blink of an eye because there is no linking.
bccdee 5y ago
> Clearly nobody has stumbled on a big win or one particular language would start dominating the industry due to the productivity bump. This is what happened with Python. It provided a distinct productivity advantage over C & C++, and now no one writes web apps in C++ anymore. Granted, it's not just Python anymore, but newer languages learned from Python's success.
- gameswithgo 5y ago
  Garbage collection got a clear productivity gain over not garbage collection. But it isn't clear that the various takes on GC languages, Python, Java, C#, Go etc have led to any one clear winner.
  - ska 5y ago
    > Python, Java, C#, Notably, we've had garbage collection for nearly as long as we've had programming languages - so this has been going on much longer than the examples you give would suggest.
  - bccdee 5y ago
    I'd argue that Java ultimately failed to innovate over C++ in the way that Python did. It added GC, but it's still clunky and hard to work with. In that sense, it's more of a pre-Python language, even though it's a few years younger than Python.
- jokethrowaway 5y ago
  First we had web apps written in Java, then Perl, PHP. Python's popularity for web app development came way later (django was released in 2005)
  - bccdee 5y ago
    Python was originally written as a reaction to C & C++. It didn't really hit the mainstream for web apps until much later, granted, but when we compare it to the languages it was originally competing against, the difference is pretty clear.
michael1999 5y ago
I don't think you mean that, or you misunderstand how Javascript or PHP came to be.
- gameswithgo 5y ago
  If I didn't understand how javascript came to be, I would be suggesting that javascript must be the best language!
nemo1618 5y ago
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.
  - 5y ago

coldtea 5y ago

>Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans. Several quite opinionated industry titans who appeared to ignore most things they didn't themselves invent in AT&T for UNIX or in Plan 9, and based on their own preconceptions of "programming at scale" as a pet project (not based some formal Google-initiated research on its practical needs). Algol and ADA were indeed created by "experience of several industry titans", in a process examining the field of applications and use cases for the languages. Go was not really that, whatever the story says.

AnimalMuppet 5y ago
> and based on their own preconceptions of "programming at scale" as a pet project Based on their experience working at Google. It wasn't just "preconceptions". (True, it also wasn't an examination of the field of the form that led to Algol and Ada, but it wasn't just preconceptions, either.)
- coldtea 5y ago
  >Based on their experience working at Google. Yes, but that's their experience working at Google as 30+ years industry veterans and thought leaders (one would guess, mostly left to do their own thing, as prestige hires). Not as regular developers doing everyday Google grunt-work...
  - AnimalMuppet 5y ago
    Well, the founding myth of go says that it started from a conversation during a 45 minute C++ compile. I doubt that that was Rob Pike's personal "thing" project - he hadn't been there long enough to have a personal project that size. That was some big multi-person multi-year thing.
    - srparish 5y ago
      They had the limbo language in plan9, which has similar features and quirks. It seems most probable that the outcome of the 45 minute conversation wasn't "let's build a language from scratch", but rather "let's iterate on limbo".

gher-shyu3i 5y ago

> Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans This claim keeps getting repeated with absolutely nothing to back it up, other than repeating what the golang authors claimed. I work on a large golang code base, and it's quite horrid. The IDE experience is terrible. It's hard to navigate the code base, due to things like types unintentionally implementing interfaces because they happen to match on some of their function declarations. No proper visibility rules (only "public" and "package private"). interface{} everywhere because of no generics (I'm aware that's being worked on). Single character variable names are popular because the golang authors write code that way and it's seen as "smart". No reserved "this" or "self" keyword to declare methods means that every type will have its own single letter self variable which you have to look up every time. Error handling is terrible, and I've seen many insidious cases of mishandled errors. Null pointers are still a thing. The list goes on. Edit: not to mention things like the language is against quick prototyping (heavy friction due to things like unnused imports or variables, and a very verbose language), as well as the lack of mature libraries such as JDBI or Dapper.

ikiris 5y ago
This sounds like really bad code was allowed to be checked in, not the fault of the language. You can make terrible code in almost any language. The above does not match my experience in maintaining large go codebases because of proper code reviews and expectation of writing maintainable code.
- gher-shyu3i 5y ago
  Nope, we have a very rigorous linting and review process. It's the shortcomings of the language.
  - ikiris 5y ago
    how are your complaints about your bad variable names shortcomings of the language and not the code you accept?

jokethrowaway 5y ago

From my experience having to debug and fix up / change things in old go codebases, it's an absolute nightmare. The lack of abstractions often force you to read a lot of code you don't care about. The language is so simple that reading complex code is actually hard.