10 ms·

They are probably referring to what Rob said in a presentation. "The key point here is our programmers are Googlers, they’re not researchers. They’re typically

They are probably referring to what Rob said in a presentation. "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."

f3408fh 14d ago
Ah, well, I take it back then. Sorry dist-epoch!
cestith 14d ago
This sounds like he's discounting Lisp, Scheme, OCaml, and Haskell in favor of something that's more of a safer, fresher take on the C language for his target group. The real competition for a language like Go these days are Rust, Zig, maybe D or Swift. Python, Fortran, JS, TypeScript, PHP, Julia, and such are mostly used in other niches. Common Lisp, Scheme, Haskell, OCaml, Objective Pascal, Ada, and several more are capable languages but don't benefit as much from the network effects of C-family syntax.
- cmrdporcupine 14d ago
  Rust development was already in the air a bit at the time that Go made its debut. And in a shape at the time that was arguably more Go-shaped than what it became (did not have borrow checker yet, and had a managed runtime and GC option as well I think). I personally think hubris led to Pike not working with others in the industry and Go bears the stamps of some very unfortunate idiosyncratic decisions as a result. The error handling in particular is awful. Refusal to admit parameterized types (until forced to, later) another. I like to imagine an alternate reality where Google and Mozilla had birthed something together halfway between Go and Rust. I think the world really still needs something like this for server development; parametrized types, ML-influenced type system, proper strictly typed error handling and pattern machine like Rust / ML; native code production like both; but with GC and fast compilation and a good powerful standard library like Go. Closest to this out there might be OCaml, I dunno. Maybe Swift.
  - genxy 14d ago
    Rust with a GC would give you this. You might like https://arxiv.org/abs/2504.01841v4 https://arxiv.org/abs/2504.01841v4
  - Jtsummers 14d ago
    > Rust development was already in the air a bit at the time that Go made its debut. Go's debut was in 2009 (1.0 a few years later, but you could have used it not long after its announcement at the end of 2009). Rust's first public release was in 2012. It's very unlikely that early, pre-public release Rust could have had any significant real or hypothetical influence on Go.
  - cestith 12d ago
    Using explicitly checked errors instead of exceptions was a considered design choice and is well explained in the Go literature. It may not be to everyone's taste, but there are reasons for it. One of those reasons is how often very normal flow control is shoehorned into exceptions when they are available.

f3408fh 14d ago

Ah, well, I take it back then. Sorry dist-epoch!

cestith 14d ago

This sounds like he's discounting Lisp, Scheme, OCaml, and Haskell in favor of something that's more of a safer, fresher take on the C language for his target group. The real competition for a language like Go these days are Rust, Zig, maybe D or Swift. Python, Fortran, JS, TypeScript, PHP, Julia, and such are mostly used in other niches. Common Lisp, Scheme, Haskell, OCaml, Objective Pascal, Ada, and several more are capable languages but don't benefit as much from the network effects of C-family syntax.

cmrdporcupine 14d ago
Rust development was already in the air a bit at the time that Go made its debut. And in a shape at the time that was arguably more Go-shaped than what it became (did not have borrow checker yet, and had a managed runtime and GC option as well I think). I personally think hubris led to Pike not working with others in the industry and Go bears the stamps of some very unfortunate idiosyncratic decisions as a result. The error handling in particular is awful. Refusal to admit parameterized types (until forced to, later) another. I like to imagine an alternate reality where Google and Mozilla had birthed something together halfway between Go and Rust. I think the world really still needs something like this for server development; parametrized types, ML-influenced type system, proper strictly typed error handling and pattern machine like Rust / ML; native code production like both; but with GC and fast compilation and a good powerful standard library like Go. Closest to this out there might be OCaml, I dunno. Maybe Swift.
- genxy 14d ago
  Rust with a GC would give you this. You might like https://arxiv.org/abs/2504.01841v4 https://arxiv.org/abs/2504.01841v4
- Jtsummers 14d ago
  > Rust development was already in the air a bit at the time that Go made its debut. Go's debut was in 2009 (1.0 a few years later, but you could have used it not long after its announcement at the end of 2009). Rust's first public release was in 2012. It's very unlikely that early, pre-public release Rust could have had any significant real or hypothetical influence on Go.
- cestith 12d ago
  Using explicitly checked errors instead of exceptions was a considered design choice and is well explained in the Go literature. It may not be to everyone's taste, but there are reasons for it. One of those reasons is how often very normal flow control is shoehorned into exceptions when they are available.