▲ 84 points
back
105 comments
C++ interop is impressive, and notoriously hard to get right. This seems like it would be able to cover a lot of APIs.
Swift and C# are the well-designed languages I'd rather use at my work instead of Go. It's a real shame both are effectively locked into a specific platform.
You can really tell that they had years of attention and careful design by experts in PL poured into them. Go seems like an amateur hobby project in comparison.
Currently developing both in swift and go and i have the exact inverse feeling.
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.
Depends on what you think they’re masters of. Developer experience? Sure. Modern programming languages design? Absolutely not.
I think Go is made for writing a certain kind of software that is important for Google, and for a certain kind of developer Google wants to have writing this software. That the result is not the kind of language I would want to use is immaterial. I'm quite sure Go is masterfully targeted for the purposes Google wants it for.
But developer experience is a factor that should weigh heavily in evaluating the quality of a programming language.
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?
What is the purpose of modern language design, if not to improve developer experience?
Go seems to have been developped by true masters that really understand that less is more.
"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.
I'll offer a different take: Thinking that complexity can be offloaded into the language is not seeing the whole picture.
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.
golang concurrent programming is by far the best i've ever used for its application domain which is mainly infrastructure middlewares running in a connected environment.
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".
What pain points are you referring to? Beyond the lack of meaningful cross-platform abilities, what "real world" issues do you find painful in Swift?
indeed that would be number 1 by a VERY high margin. It's pretty ridiculous to start with "world domination" as an objective and end up 10 years later without a portable stdlib (aka foundation).
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.
Echoing these sentiments - I find Swift very painful to use.
I'm not sure why you're saying Swift is locked in to Apple platforms, it's definitely cross-platform. It's no problem to run Swift on Linux or Windows. Of course, Apple's UI libraries aren't cross-platform. And they're putting a bunch of effort into making it better for servers and such. I wish more people realized how usable it is cross-platform, I think this is a misconception that hampers Swift adoption.
Swift is definitely my favorite programming language from a language standpoint. I really like the way Swift works. It's safe, concise without being terse, and easy to extend.
Sure, some people can argue there's some "bloat", but I think that's inevitable in a language that was designed to immediately be usable within Apple's existing APIs and frameworks. There's going to be complexity with Objective-C interop, C++ interop, etc. But that stuff is necessary for Swift to be usable for big projects. And I think Apple has done quite a good job of evolving Swift to be cleaner, clearer, more ergonomic, etc.
I'm very excited that there's a lot of effort behind an open-source, cross-platform type-safe, compiled language that also prioritizes ergonomic high-level programming.
> I'm not sure why you're saying Swift is locked in to Apple platforms, it's definitely cross-platform
I think the key word in OPs comment is "effectively".
The tools for building cross platform Swift exist and work in various levels but they aren't at the point where you would want to choose Swift over existing cross platform tools.
That caveat does not match the definition of “effectively” to me.
I don't trust Apple to care about platforms or developers that aren't directly benefiting them.
They barely care about developers for their own platforms. Their docs are atrocious.
Who do you trust to do that?
I'm using F# via the .NET SDK on macOS (i.e. I could also use C#), so it seems to have less platform lock-in than Swift at this point. It does have its limitations, for instance I can't for the life of me figure out how to make the F# REPL UTF8-capable. As ludicrous as that is, it's not really my use case, so I can live with that for now.
IMO Go would have been 70% better with Result instead of (*type, error). So, so much duplicative code would have been avoided. It's not even a different paradigm. What a wasted opportunity.
>It's a real shame both are effectively locked into a specific platform.
This view of C# will be wrong for a almost a decade very soon! (if you don’t count mono)
Depends on where on C# ecosystem one is, Web development, versus desktop.
How is C# locked in? It's pretty well supported on linux and mac.
It is kind of, given the tooling that is still bound to .NET Framework, or that if you want to analyse profiling data, that is only available in VS/Windows.
Also many .NET shops still only target VS for their SDK plugins.
Additionally, VSCode seems to be getting a new developer experience, also tied to the same licenses as VS and VS4Mac.
Finally, if you really want a cross platform GUI, you're better off with 3rd party like Avalonia and Uno, than anything Microsoft.
This stuff in many shops is what makes them go Java instead of .NET, regardless of .NET Core/.NET 5+, as there are no "yes but" when discussing frameworks versus OS support.
> A C++ class or structure becomes a standalone type in Swift. Its relationship with base C++ classes is not preserved in Swift.
C++ `class Fern: public Plant` becomes two different types in Swift `struct Plant` and `struct Fern`, how is this supposed to help anyone?
https://www.swift.org/documentation/cxx-interop/#accessing-i...
It still allows you to use them for interop. The only functionality that would be impaired is checking for inheritance with an `as?` type check/conform.
No, this blocks a fundamental concept of OOP: Liskov Substitution Principle.
The idea is that you should be able to use a derived object anywhere the base one is required.
It impairs that principle, yes. But it doesn’t block similar patterns that give you similar end results. Swift has very flexible generics programming and type abstraction that still lets you use it with a little extra work.
Yes, it won’t be as ergonomic as the ideal, but it’s better than many binding solutions from C++ to compiled languages, while providing most of the usability.
Plus the footnote says that they plan to resolve this in future Swift versions.
Interop isn't magic. It can't make the C++ model transparently compatible with that of Swift when the two languages deviate.
I’ve been bitten enough by Objective-C++ compiler bugs (Apple’s attempt at mixing Objective-C and C++), as well as bugs in Apple’s code in the Swift ecosystem, not to trust the stability here for at least several years. I also don’t see how this is much better than just creating a C or ObjC wrapper around a C++ library, rather than needing to keep C++‘s complicated language features, and Swift’s interop with it, in my head as I use the library. Were there people clamoring for this? I can’t really see the point.
You might have better luck using g++ rather than clang for Objective-C++. We originally developed it on gcc (there was no llvm and the NeXT used gcc). By the time Apple switched to llvm I imagine they weren't as interested in Objective-c++
GCC isn't that compatible with everything post Objective-C 2.0, there is only a kind of partial support.
At WWDC 2023 there were a couple of sessions with Objective-C++ content, e.g. how to extend PyTorch on macOS.
Your imagination is incorrect.
Going from C++ through ObjC++ to ObjC to Swift is pretty onerous. There’s a lot of type reduction and conversion along the way and a lot of manual binding generation. Performance and safety footguns are plentiful through that route.
If you have large existing C++ libraries, this (in theory) would really help simplify the process and reduce that mental overhead you mention.
I’m not sure how your suggestion of creating wrappers is better because you’d have to still keep the C++ side for those wrappers and introduce a new intermediary layer to manage as well. Surely having one less layer is desirable?
It’s more direct is the point. Why add C in between when you can use C++ directly? Like actually, what’s the point of the C in between? It’s only adding yet another thing to maintain when your can just access C++ directly from Swift and vice versa.
I don't think I've ever encountered an obj c++-related compiler bug in close to a decade of working on a ~200k loc Obj-C++ project, and we do pretty aggressively mix obj-c and c++ things
Actually compiler bugs or just badly documented interactions between the two models, leading to misunderstandings?
Address sanitizer violations caused when using C++ containers with ObjC objects
This is a lot of what folks refer to as compiler bugs when dealing with ObjC++, yeah, usually when they not asking for help and instead just cobbling together their own workarounds.
History class, Objective-C++ was created by NeXT.
I have not yet understood who this is for. Are there many developers who have Mac apps written in C++ that want to move their code base to Swift? If so how do they do UI? I thought you needed to at least use Objective-C to use Apple GUI frameworks.
Or is there some set of libraries in C++ that are crucial to bring into Swift?
You don’t need to use Objective-C to use the GUI frameworks, haven’t had to for nearly a decade if I’ve been using Swift since then.
Now with more and more pure Swift apps, the C++ interop is more direct than having to go through Swift’s existing C interop.
On a related topic of hybrid Swift and C++ tooling - has anyone used Doxygen/Sphinx to generate HML docs for modern Swift, similar to how people do it for pure C++ projects?
Swift does have docc that does the same
https://swift.org/blog/swift-docc/
I’ve never had good luck getting documentation working cross language and so I use docc for Swift, doxygen for C++, rustdoc for Rust and Sphinx for Python. Then I just link between them if a project uses more than one language
Sure, but how do you style and host those docs? Can you style them identically? We use a combo of Furo + Sphinx + Doxygen for C/C++, Python, JavaScript, Java here: https://unum-cloud.github.io/docs/usearch
For ObjC, Swift, Rust, and other languages we couldn’t make it work for now.
i wonder if this isn't going to have the side effect of making some people write more cross platform code in c++.
People are going to keep writing libraries in C++ until there’s a better option.
The reason why many of us still reach out to C++, is that in many cases the option is only between C or C++, and from both, at least C++ provides some safety knobs.
I think that’s fine as long as there’s no performance penalty.
People were doing it anyway. This just eases the friction, and potentially increases performance since many wrappers are really inefficient with regards to data marshalling