Go seems to have been developped by true masters that really understand that less is more. They've also kept a laser sharp focus on working on things that really matters and took the time to do things right.
Swift on the other hand looks like more and more bloated every day, without adressing the main pain points of the experience of coding in swift in the real world.
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?
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.
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.
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.
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."
"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." - Rob Pike
Ignoring complexity on the language level simply passes the buck to application code, and developers end up paying that price across the ecosystem in perpetuity.
They've also kept a laser sharp focus on working on things that really matters and took the time to do things right.
Go's async model is underspecified, its implementation of generics incurs runtime overhead, much of the "wonderful tooling" only exists because of severe shortcomings in the language design and/or compiler implementation, its FFI is... difficult, etc.
To be blunt, the values that Go embraces are none of the values I seek in a programming language or community. And I feel sorry for anyone too heavily invested in Go to turn back.
The tradeof between language features and maintainability is also IMHO the best in class. Never before have i ever looked at a stdlib sourcecode and told myself "hu, yeah i see how that works".
Offloading complexity into the language works for the simple cases, but the more one is trying to fit a solution into a physical box with physical constraints, and the more flexibility is required from the business logic, the situation will change in such a way that more control about the specific of the solution becomes a requirement, and the language shortcuts will fit less and less, to the point where they become a liability. Doubly so if it is difficult or impossible to unwrap the layers of language features.
Of course, many problems can be solved with just a few Python scripts, or even with a huge pile of them. On the other hand, we can find a possible explanation why it could make sense for some teams to code huge apps in low-level languages (C or C++) or languages with few language features (e.g. Golang), or even to try and control the whole stack by maintaining their own language infrastructure.
This is exactly what Go does. Languages like C++ or Rust make it possible to expose and interact with those complex requirements, whereas Go takes it away in the name of “simplification”. Just look at all of the insane hacking tailscale does on Go to make it work for them.
I can understand that sometimes you want tools to quickly cut through obstacles, however I've also noticed that applying such tools without extreme care, like on a regular basis, seems to always lead into local maxima and at some point these choices have to be reconsidered.
One explanation for this phenomenon that I've found is that language features are typically accessed using special syntax, because otherwise they could be library features. Well, it's hard or typically even impossible to abstract over syntactic uses of such features. For example, it's hard to automate the definition of a class based on more abstract concepts, when such creation has to be done as explicit syntax instead of using a builder-style API that iteratively adds members and methods.
Another issue would be a coherent concurrency system. Today we have a mix of gcd and actor system, declarative task, async await, etc which when put together makes me totally unable to understand what's going on in a real world program, unless you're doing like i do in my team : i specifically ban all modern concurrency apis in favor of the old ones.
The same could be said with protocol extension + generics + class + structs.
For each problem, there are approximately 4 possible designs with subtle tradeoffs. Swift team advocates for "expressiveness". My personnal experience is that all patterns and technics will ultimately end up showing in the codebase, depending on the mood of the developer.
In the end, i've started to do like C++ developers end up doing : write guidelines on which language features are allowed, and which are forbidden.
Compare that to go, where there's (at most) one satisfying way to design the problem in the typesystem. As a sideeffect people have to think more about the problem they're trying to solve, and how to simplify it to the maximum.
The end result is that go pushes you toward simple and maintainable code. Swift pushes you toward being fancy for no good reasons.
you are referring to basic languauge features... you consider classes and structs pain points? these are the basic building blocks of the language, if you find them painful this is definitely not the language for you.
It looks great on paper and do enable beautiful designs in some cases. But after tasting languages like go you realize you can get away with struct & functions in 99% of the cases, and that having less design options is actually a plus. It lets you focus on what really matters : domain modeling.
(a) Foundation is portable and available on Windows and Linux.
(b) You are confusing language features and OS features. Async/await is part of the language. GCD is part of the OS.
(c) Banning modern concurrency primitives is not viable forever — you’ll be left behind as the native APIs adopt them.
I wouldn't want to be the guy relying on this table advancement for his own project. The fact that they're rewriting it in pure swift probably says a lot about the quality of the current approach.
b: makes absolutely no difference from a developer perspective. if you want to run threads in swift you're going to use gcd.
c: my take with all apple software tech has been to wait until they've dogfooded their own tech long enough to make it useable. Worked very well for me so far, thank you very much.
There’s a layering:
- gcd is the lowest level
- async/await lets you write tasks with suspension points (they wait for events to happen); but an async function is still conceptually executed serially
- the Task API let’s you spin up async functions into various arrangements of parallel tasks and wait for those tasks to complete
- ‘async let’ is sugar for creating a Task to compute a single expression
- for async functions and Tasks to share data there is a Sendable model and various static isolation checks
- actors build on everything else; actors are classes whose state is completely isolated to the actor, and all method calls are posted on the actor’s executor
Memory-safe concurrency is hard. There’s a lot of ground to cover to replace the kind of things people do with shared state concurrency, and just actors alone are not enough.
> Compare that to go, where there's (at most) one satisfying way to design the problem in the typesystem. As a sideeffect people have to think more about the problem they're trying to solve, and how to simplify it to the maximum.
I like the aesthetics of small languages too, but I think Go picked the wrong small subset. It reminds me of Java in the 1.x days, for x <= 4, where the language had fundamental expressiveness constraints that created a huge amount of unavoidable boilerplate and type unsafety in even the most basic programming situations.
i was having doubts before go introduced generics. But the fact that they managed to add it so perfectly while maintaining the unambiguous focus on simplicity and structs made me confident they've really nailed it.
The only feature i don't get why they haven't added yet is proper enum to get some kind of ADT. It looks super orthogonal to the language and quite convenient. However at this point i fully trust their taste. If they think it's going to lead to catastrophic design decisions, i fully believe them.
It really feels like a refactoring tool rather than a new design tool : you still think mostly about functions and structs and don't get carried by "is x a kind of y" kinds of discussion.
Result builders are a case in point. Essentially, they didn't like the bracket and the comma between array items in the special case where a function returns only a single array.
// So rather than this
let items = makeUgly {
[
Item("One"),
Item("Two"),
Item("Three")
]
}
// It had to look like this
let items = makePretty {
Item("One")
Item("Two")
Item("Three")
}
So now there are essentially two separate syntax modes in Swift, and every time you look at some code you have to make up your mind on whether to read it in normal mode or in result builder mode. Sometimes that's easy to know in context. But it's another thing you have to pay attention to at all times.
Looks like a manager once said "we've got to look like jsx/html, now !" and the poor devs had to obey. It makes absolutely no sense from a language design POV.
I guess you never looked into Kubernetes and their blobs of generated code to work around Go's weaknesses.
As such it should provide comparable level of flexibility, tooling and developer power.
Anything else isn't part of swift focus.
However i have yet to see any swift codebase of comparable complexity. So, the jury is still out on which language enable the largest scale.