With exception of Kubernetes, most of Google's software keeps being written in Java, C++, Kotlin, and nowadays Rust.
Its use is much more widespread outside Mountain View walls than inside them.
Google's software runs on Borg, which is _not_ written in GoLang.
Google's three OS projects all eschew GoLang as well.
1. Borg precedes K8s and likely is tightly coupled with Google's backend infra - that's to say, Borg gets architected around Google's existing workflow and new backend development is written around Borg's workflow.
2. GoLang was never intended to be an OS-level programming language. It was created to enable more robust, efficient, and rapid development in a particular space. It would be just as silly to argue that Google's three OS projects all eschew Dart.
1. is fair.
2. I'd argue is false, given Fuschia and Dart are tightly integrated (as another commenter noted) and that GoLang was originally designed as a C++ replacement born from the Plan9/Inferno tool chains (certainly "OS-level"). Also there's a ton of non-kernel code in an OS so this is a really blurry distinction. containerd does some pretty low level stuff with Linux and GoLang is perfectly capable of this.. if Fuschia wanted to use it they could.
They were however rewritten in Rust, after the author left Google and they wanted to clean Fuchsia from Go code.
Go was created by three folks that got fed up waiting on C++ compile times, and from their point of view Go is designed for people unable to take feature rich languages, on Rob Pike's own words.
"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."
Or alternatively,
"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical."
I also fear Swift is going a step too far. For example, IMO Swift's compilation speed isn’t good enough.
If that’s a matter of lack of tooling, I won’t blame the language, but is it, or is its slowness unavoidable for a language that is so flexible? If the latter, I would rather have a bit less flexibility and more compilation speed.
Similarly, there’s quality of error messages. Swift has gotten better there, but still has some weird ones. Are they unavoidable for the current language?
It's been humbling to come back to it over the intervening 7 years and realize they weren't nitpicks that would be resolved shortly, and people would understand if they just read the swift-evolution mailing list. They were fundamental flaws.
This is a Swift-only feature in major languages with type inference.
One example that would improve the above: replace module imports with file specific imports, including within the module itself. You could also make a case for operator overloading and there are probably a bunch of candidates a swift compiler engineer could tell you that would be small but significant like that.
https://github.com/apple/swift/blob/main/docs/CompilerPerfor...
Xcode also trips on simple type errors and sometimes fails to even provide a line number where the error lies. As someone who just wrote a Swift app after no prior exposure, it's oddly immature in some basic ways after nearly a decade from launch.
Swift and Rust both suffer from slower compilation than Go, primarily because LLVM prioritizes optimization over speed.
There are of course other reasons like complexity of language, size of compilation units etc… but optimization tends to be the biggest hit in my experience.
Hence why Rust is adopting/investigating cranelift as a debug compiler to improve speed.
I guess you don’t have much experience with Swift. LLVM code generation may be slower than alternatives, but that’s more or less by a constant factor.
Swift’s type inference, on the other hand, can lead to a combinatorial explosion.
For example, https://www.hackingwithswift.com/articles/11/how-to-make-swi... claims that
let sum = [1, 2, 3].map {
String($0)
}.flatMap {
Int($0)
}.reduce(0, +)
compare this code:
let sum = [1, 2, 3].map { (num: Int) -> String in
String(num)
}.flatMap { (str: String) -> Int? in
Int(str)
}.reduce(0, +)
let numbers = [1, 2, 3]
let stringNumbers = numbers.map {
String($0)
}
let intNumbers = stringNumbers.flatMap {
Int($0)
}
let sum = intNumbers.reduce(0, +)
Of course, all of these use LLVM, and likely even generate highly similar intermediate code.
Also, you’ll see these slowdowns even in debug builds that don’t ask LLVM to optimize code much.
But nothing you said contradicts what I said either. Yes it’s easy to get into slow paths with Swift, but it’s also easy not to. Granted it takes a lot of up front knowledge to do so.
But even if you just stick to the LLVM portion, llvms debug mode is slower than cranelift and other toolchains debug modes. Debug doesn’t mean “no optimizations” whatsoever, nor does it mean efficient paths through the toolchain either.
I find every other aspect of "developer experience" excellent
Tools like Agda, Spark, Idris, and Coq move the tradeoff around towards "probably correct", and I welcome seeing some of their features become gradually available. Getting things right the first time is useful.
But these features can also make it hard to get anything done quickly.
Good developer experience means finding a balance between the quick and dirty, and the provably correct.
* Language features that make it so that you don't have to write code at all
* Tooling that makes it easier to find bugs in the code you do write
* Expressiveness and portability that allows the code to be used in more places
* Approachability, so that new people can pick up the language quickly
* "Batteries", so that people can rely on your high-quality libraries instead of having to manage their own
* Documentation and community, to handle the hardest parts of programming: people
* Performance, so that the code can use fewer resources
…among many other things.