5 ms·

> I can't speak for Go's genesis within Google, but outside of Google, this underanalysed political stance dividing programmers into "trustworthy" and "not" und

> I can't speak for Go's genesis within Google, but outside of Google, this underanalysed political stance dividing programmers into "trustworthy" and "not" underlies many arguments about the language. This summarises my opinion of Go that has been forming recently, that it's a replacement for Java. Java was the "safe" choice. Many engineers knew it, bad engineers couldn't be _that_ bad in it and would manage to produce something. They could be handed an architecture spec and implement it word for word without doing much translation to the Java language. But I don't think good engineers could "shine" with it. It normalised all engineers around some median of productivity, and made projects predictable. I believe Go is doing the same thing in some ways. It's not supposed to allow good engineers to find great ways of expressing complex architectures (however necessary that may be), it's designed to let engineers of all skill levels hit all problems with a Go shaped hammer and get something that looks inoffensive, boring and predictable. This is very unsurprising given that it came out of a large engineering organisation. Google have many engineers of a wide range of skill levels, and normalising engineering is more important than doing it better. I realise Google probably has a higher than average engineering ability, maybe far higher than average, but they still have a wide range, and I also include in this engineers who might be fantastic frontend engineers, who have to get stuck into some system software, for example.

dis-sys 8y ago
> But I don't think good engineers could "shine" with it. any concrete example on what a good engineer couldn't achieve when using Go in its intended domain/role?
- danpalmer 8y ago
  I've seen some amazing abstractions created in Rust and Haskell. Some of the Haskell ORMs are really nice abstractions over SQL for example, and there are many examples of Rust macros doing amazing things (I believe async/await was implemented as a macro?). Obviously you can write an ORM in Go, and you can write async code or code that will do whatever Rust macros can do, but the solutions will be less elegant, less re-usable, less useful. There's an argument to be made that this is all "clever" code, and that that is bad for maintainability. I'd agree they can be misused, but when used correctly they can level up how code is written in a very substantial way. Understanding the difference and when they are appropriate is what I really mean good engineering here.
  - skohan 8y ago
    I'm a huge proponent of boring code, but for me it's an orthogonal concept to having a lot of tools for abstractions in a language. What you actually want is to be able to write code which is as close to the problem domain as possible. Overly "clever" code is one way to get that wrong, but so is being too low-level or needing a lot of boilerplate. Having the right level of abstraction lets you write self-documenting code whose function and intent is made clear just by reading it.
    - danpalmer 8y ago
      Exactly. I’m not sure Go provides the tools. Although I could be wrong.
pm90 8y ago
I don’t think this theory holds much water. Go code is very opinionated but still flexible; it seems to be C but with superpowers and great tooling out of the box. A whole bunch of complex software is written and in production using go; I don’t think it limits the productive/clever engineers from doing what they would do with Java.
- danpalmer 8y ago
  Interesting. You could be right! My experience with Go is very limited, but I tend to see interesting abstractions built with other languages. Ruby, Haskell, Swift, JS, even some Python – I see engineers building DSLs and architectures that strongly fit particular use-cases. In Go, everything just tends to be functions and structs, and the lack of expressiveness make it difficult to do anything with nicer ergonomics. I would agree that it is C with superpowers in some respects though. > A whole bunch of complex software is written and in production using go This is true, but my point isn't that you can't write the software, just that it might have been better code in another language (easier to understand, reason about, more reliable, more maintainable?). The biggest benefit along these lines that Go seems to have is that lots of other software is written in it, which comes back to a similar argument as Java.
  - vertline3 8y ago
    It's a replacement for c plus plus. Python, Ruby all those things are higher level. Haskell is different paradigm. It's apples and oranges
    - danpalmer 8y ago
      >It's a replacement for c plus plus. Python, Ruby all those things are higher level. Ok then, Rust or Swift. These are both replacements for C/C++ and the same applies. > Haskell is different paradigm I don't think this is a reason to reject it. That paradigm might allow for better solutions to the problems.
      - vertline3 8y ago
gralx 8y ago
> ... it's a replacement for Java. Kotlin is the Java replacement I keep reading about.
- danpalmer 8y ago
  My point isn't a technical one, but more a cultural/political one.

dis-sys 8y ago

> But I don't think good engineers could "shine" with it. any concrete example on what a good engineer couldn't achieve when using Go in its intended domain/role?

danpalmer 8y ago
I've seen some amazing abstractions created in Rust and Haskell. Some of the Haskell ORMs are really nice abstractions over SQL for example, and there are many examples of Rust macros doing amazing things (I believe async/await was implemented as a macro?). Obviously you can write an ORM in Go, and you can write async code or code that will do whatever Rust macros can do, but the solutions will be less elegant, less re-usable, less useful. There's an argument to be made that this is all "clever" code, and that that is bad for maintainability. I'd agree they can be misused, but when used correctly they can level up how code is written in a very substantial way. Understanding the difference and when they are appropriate is what I really mean good engineering here.
- skohan 8y ago
  I'm a huge proponent of boring code, but for me it's an orthogonal concept to having a lot of tools for abstractions in a language. What you actually want is to be able to write code which is as close to the problem domain as possible. Overly "clever" code is one way to get that wrong, but so is being too low-level or needing a lot of boilerplate. Having the right level of abstraction lets you write self-documenting code whose function and intent is made clear just by reading it.
  - danpalmer 8y ago
    Exactly. I’m not sure Go provides the tools. Although I could be wrong.

pm90 8y ago

I don’t think this theory holds much water. Go code is very opinionated but still flexible; it seems to be C but with superpowers and great tooling out of the box. A whole bunch of complex software is written and in production using go; I don’t think it limits the productive/clever engineers from doing what they would do with Java.

danpalmer 8y ago
Interesting. You could be right! My experience with Go is very limited, but I tend to see interesting abstractions built with other languages. Ruby, Haskell, Swift, JS, even some Python – I see engineers building DSLs and architectures that strongly fit particular use-cases. In Go, everything just tends to be functions and structs, and the lack of expressiveness make it difficult to do anything with nicer ergonomics. I would agree that it is C with superpowers in some respects though. > A whole bunch of complex software is written and in production using go This is true, but my point isn't that you can't write the software, just that it might have been better code in another language (easier to understand, reason about, more reliable, more maintainable?). The biggest benefit along these lines that Go seems to have is that lots of other software is written in it, which comes back to a similar argument as Java.
- vertline3 8y ago
  It's a replacement for c plus plus. Python, Ruby all those things are higher level. Haskell is different paradigm. It's apples and oranges
  - danpalmer 8y ago
    >It's a replacement for c plus plus. Python, Ruby all those things are higher level. Ok then, Rust or Swift. These are both replacements for C/C++ and the same applies. > Haskell is different paradigm I don't think this is a reason to reject it. That paradigm might allow for better solutions to the problems.
    - vertline3 8y ago

gralx 8y ago

> ... it's a replacement for Java. Kotlin is the Java replacement I keep reading about.

danpalmer 8y ago
My point isn't a technical one, but more a cultural/political one.