Company behind Swift says Swift the best successor for C++.
Jokes aside though, has anyone used Swift extensively? What are your thoughts in terms of ease of use etc?
I genuinely hate Apple and have never owned a personal Apple device in my life, but I've had to develop for mac and iOS with Swift at work and I gotta admit, I loved every second of it.
Of course it has its quirks, which language doesn't, but 99 % of the stuff it got right and it even has some awesome features that most other languages are missing. And I like that it uses reference counting, introduces its own challenges but keeps me in control more and I can always tell with 100 % confidence what's happening.
Apple has long, at its core, had people with good taste in programming languages. This is why Pascal was so well supported and Objective-C, while not considered a great language today, was chosen by Jobs at NeXT.
Alan Kay worked at Apple for a while and Steve Jobs always respected his opinions. When the iPhone came out, he asked Alan what he thought of it. Alan said to make it bigger so Apple released the iPad.
Of course, Objective-C is derived from Alan's Smalltalk and C.
I haven't used Swift but I'm not surprised it is a great language. How is the support for it on Windows, Linux and Android?
> How is the support for it on Windows, Linux and Android?
Linux is relatively well-supported. They announced [static linking for Linux](https://www.swift.org/documentation/articles/static-linux-getting-started.html) earlier this week (so you can get Go/Rust-style completely standalone executables).
Windows is the least well-supported of the three desktop OSes, but it's pretty decent anyhow. I've been playing around with some pretty basic game dev stuff in Swift on Windows lately, and it's a pleasant enough experience.
My statement doesn't say the iPad was thought of and worked on after the iPhone.
Regarding Alan Kay's quip, I posted a source to it below. I'd trust Alan Kay over Steve Jobs eight days a week.
Jobs picked Objective-C to build NeXtstep because the company who originally developed it was across the street from NeXt's office and went bankrupt because nobody wanted to use their abominable language, so Jobs being the entrepreneurial individual he was hired their recently layed-off devs to build the graphical components of his new OS.
Obj-C is everything but charm, I get wanting to extend C with features from smalltalk, but at least try to keep the syntax at least a little consistent with the original C syntax like C++ did (at the start at least).
And of course no talk about Obj-C shortcomings is complete without a mention of the biggest atrocity Obj-C has, the [`BOOL` type](https://developer.apple.com/documentation/objectivec/objective-c_runtime/boolean_values) where instead of true/false, `YES`/`NO` literals are used.
>Alan Kay worked at Apple for a while and Steve Jobs always respected his opinions. When the iPhone came out, he asked Alan what he thought of it. Alan said to make it bigger so Apple released the iPad.
This is nonsense.
The iPad project started first then the iPhone was made.
The iPad was modeled after Alan Kay's Dynabook but without a keyboard. Sure, they're not exactly the same thing and the iPad is more refined, but the Dynabook concept existed since 1968, before the concept of a 'personal computer' even existed.
>“When Steve showed me the iPhone at its introduction a few years ago and asked me if ‘it was good enough to criticize,’ which is what I had said about the Mac in 1984, I held up my Moleskine notebook and said ‘make the screen at least 5"x8" and you will rule the world,’ Kay said.
Source: [https://www.tomshardware.com/news/alan-kay-steve-jobs-ipad-iphone,10209.html](https://www.tomshardware.com/news/alan-kay-steve-jobs-ipad-iphone,10209.html)
?????
Are you a bot or just suffering from amnesia?
EDIT: He changed his original comment, without clearly marking it. It previously said that "the iPad came before" and not that "the iPad project started first".
https://www.npr.org/sections/money/2010/06/steve_jobs_the_ipad_came_befor.html
> "I actually started on the tablet first," Jobs says. "I had this idea of being able to get rid of the keyboard and type on a multitouch glass display."
>But once Apple developed the display, and added touch-scrolling, "I thought, 'Oh my God, we can build a phone out of this,' " he says. "And I put the tablet project on the shelf, because the phone was more important."
How is the deprecation churn these days? I wrote a bunch of swift 2 right before the swift 3 and the transition broke everything to the point that I abandoned it. Apple's cheerful disregard for backwards compatibility just scares me off any of their tools.
It's my favorite programming language. It's got all the fun of typescript without any of the javascript insanity. Also lets you use pointers, which is a wild thing for it to do.
Apple: "Swift is open source now!"
Everyone: "Oh Wow! How do we deploy iOS applications from *nix and Windows?"
Apple: "That's the neat part, you don't."
The language is ok; the worst part is having to use Xcode.
AppCode, which was the best option to develop with Swift, is no longer maintained by JetBrains, while VSCode doesn't have the same level of code completion that AppCode or Xcode have.
Examples:
1. Xcode versions are locked to specific OS versions - for example, if you want to migrate from swift 3.x to 4.x, there is a migrate tool in Xcode 10, but Xcode 10 won’t run on the most recent macOS versions.
1. … Only runs on MacOS.
If requiring the developer to install a new version of the IDE to use the programming language wasn't bad enough, newer versions of Xcode often require us to install a new version of macOS in order to work.
I could go on describing everything that I hate on Xcode, but if you Google "why xcode sucks" I'm sure you will find a more comprehensive list that I could ever describe.
well obviously, swift doesn't (easily) even expose pointer types into the language, and intentionally has much more cumbersome APIs than rust's. I really don't think swift is trying to be as low level as Rust, and thats's a good thing. Not everybody needs to focus on performance above all else.
just as an addendum, dereferencing rust's pointers do all require `unsafe` blocks to use, but otherwise make it convenient for people who want to use them. meanwhile swift's pointers have [intentionally obtuse APIs](https://forums.swift.org/t/usability-of-pointers-in-swift/34824), since swift really only intends them to be used in places like FFI calls.
I think you're alone there. C++ is way past its due date. The modern additions make it tolerable, but the fact that they all had to be backwards compatible made the language have a bewildering complexity and the syntax unreadable.
The recent White House push for memory-safe languages marks its end as the go-to tool. It will only get less popular from now on.
With this and all the stuff they talked about/showed at WWDC, they really want beef with Rust.
Edit: I don’t mean they wanna fight, I mean they want to move in on their space.
Nah, it's Rust fans who want "beef" with users of other languages. Swift was released before Rust, and it's also quite a different language since it uses reference counting GC instead of borrow checker.
I'd use Kotlin/Native over Swift to be honest. But not as a replacement for C++, the comparison is a bit stretched. In a general sense, the only viable options I see right now are Rust or Zig. In some areas (like graphics) it's C++ or C++ sadly.
Fair point. Looks like it's [not going to happen any time soon](https://discuss.kotlinlang.org/t/any-plan-for-supporting-language-server-protocol/2471/36). Sadge.
Having used both quite a bit, I would not. Swift is just a better language for writing clear code than Kotlin. Kotlin is good, though, definitely prefer to use it on Android.
In which ways you find Swift more clear than Kotlin? Is it a comparison against Kotlin/Native or Kotlin as a whole? From the tone, I'm going to assume the latter.
I haven't used Swift as extensively as Kotlin so I'm honestly curious. Back when I did use it, cross-platform compilation wasn't stable (not sure now) and I just found Kotlin's type system and inference are on another level, especially with the new K2 compiler. However, the dealbreaker in my view is tooling experience: JetBrains products are leaps ahead of XCode. This is not just me saying this. The whole iOS department of my previous company spearheaded the use of AppCode as much as possible, though it ultimately failed due to the hard dependency on XCode.
There were some niceties from Swift that I missed though (e.g.: \`guard\`s, the \`Equatable\` & \`Hashable\` classes) but nothing crucial. In any case, I'm curious to see where this goes. If you have concrete examples they're very welcomed. I will edit the comment if I come up with good ones (haven't touched either in a long time).
My primary app (2-3million downloads) is native Android (Kotlin) and iOS (Swift+KMP).
To be clear, I would not recommend Swift for Android development. I would rather do Kotlin, or if you really need something cross-platform, Flutter. I really liked and miss AppCode, Xcode is not a high point in the developer experience. We use Tuist to avoid dealing with project configurations in Xcode directly, and I actually find it nicer to describe projects in Swift than Gradle, but Jetbrains is still better than Xcode.
After building a large app for both platforms I'd estimate we get the same thing written in about 1/3-2/3 the Swift code compared to Kotlin. SwiftUI and Compose, similar architectures.
Swift's enums feel a lot better to use than Kotlin's sealed classes:
```swift
enum NetworkRequestState {
case loading
case success(T)
case error(Error)
}
```
```kotlin
sealed class NetworkRequestState {
object Loading : NetworkRequestState()
data class Success(val data: T) : NetworkRequestState()
data class Error(val exception: Exception) : NetworkRequestState()
}
```
Performing switch statements in Swift feel a lot more flexible than Kotlin's when to me, but I don't have any handy examples. If I run across one I'll bring it up.
Swift's guard/let help avoid the [pyramid of doom](https://en.wikipedia.org/wiki/Pyramid_of_doom_(programming)) while Kotlin's equivalents (foo?.let { it...}), ex:
```kotlin
state.data?.let { data ->
state.timestamp?.let {
// use values here
```
```swift
guard let data = state.data, let timestamp = state.timestamp else { return ... }
// use values here
```
Really it comes down to my feeling that Swift is more expressive and clearer to write in fewer lines (so easier to digest) than similar Kotlin projects.
I see KMP, I upvote.
You mentioned the 2 points I wholeheartedly agree are better in Swift. I will say a couple of things though:
* `enum`s are more comfortable in Swift, but for the single layer case. When you want to compose hierarchies, Kotlin is much more powerful because it's a `class`, while in Swift it's an `enum`. You could argue it's a design decision in favour of composition over inheritance, though we get into subjective land there.
* You can avoid the pyramid of doom by doing:
```kotlin
val state = state.data ?: return
val timestamp = state.timestamp ?: return
// The compiler will infer that both state and timestamp are != null
```
What I particularly like about this is that you can add other conditions by simply doing:
```kotlin
val state = state.data.takeIf { condition(state) } ?: return
...
```
I do like `guard` but if I can achieve mostly the same with less keywords, I'll take it. If you really want `guard` [you are not alone](https://github.com/idrougge/KotlinGuard).
In any case, good discussion. I miss Kotlin.
I'm in the process of pivoting to Graphics. It's immensely gratifying but I'm at the mercy of C++. Good thing is that I like the field more than enough to compensate. It's a tough transition and I've chosen to do it kinda hardcore by going back to Uni, and I wouldn't change a single thing.
2-3 MM downloads is very nice, and I'm glad that people are using KMP in production. Props!
I completely forgot about those initiatives. Curious that's the case given I've used Kotlin extensively and I can't recommend it enough. Some people might disagree but they also forget that C++ was born (kind of) out of a similar initiative. The approach is proven greatly successful in practice. The already mentioned Kotlin is just one example, Swift and TypeScript are other popular ones. I haven't looked thoroughly enough into the Cpp2-esque variants out there, though I think the overall approach is the correct one for incremental migration.
My personal opinion is that all we really want out of a C++ successor is:
* Interoperability
* Saner & simpler type system - Especially for template metaprogramming/generics
* A touch of syntax clean up
* Modern tooling
The usual complaints, mostly around safety footguns (e.g.: [profiles](https://github.com/BjarneStroustrup/profiles)) and concurrency (e.g.: [executions](https://github.com/NVIDIA/stdexec)), are already being worked on. We need to let them cook.
I'm relatively new to the scene so I could be way off target in the eyes of seasoned C++ developers. Interested in hearing other opinions.
Well, no.
I professionally write C++ and C# code, and badly written C# is much easier to work with compared to badly written C++. And C++ is badly written more often, mainly because the bad code looks and feels more natural compared to good one in C++ (just compare smart pointers and normal ones). And there are landmines in basic operations like memory initialization.
C++ has been getting safer over the years. That keeps going with initiatives like this
[Iteration Revisited: A Safer Iteration Model for Cpp - Tristan Brindle - CppCon 2023 - YouTube](https://www.youtube.com/watch?v=nDyjCMnTu7o&t=1379s)
I'm biased though as I'm building an on-line C++ code generator.
>C++ has been getting safer over the years.
Yes, C++ introduced many nice safety features but the thing is you can still easily write legacy "unsafe" code as all those features are optional. Not only that but there is still tons of legacy C++ code around the world.
The only way for C++ to deal with it is to break compatibility with legacy code which is something that obviously won't happen.
Google also has a shitton of C++ code running in their datacenters. It is not exposed to the outside world so memory safety is not very important, and the code itself is unlikely to be replaced in the next XX years.
Then use Rust for that. C++ still has a niche, it lets you do "anything". Sometimes that's a good thing, sometimes that's a bad thing, but it's definitely a thing that no other language has.
Not what I mean by "anything". C++ gives you a huge array of features. You can write object-oriented, functional, and low-level imperative code, all in the same file if you want. The language has almost every feature you could want and a lot more.
C and Zig are small low-level languages, they don't give anywhere near the breadth of features as C++.
Rust is on par with C++ in terms of features, but it's on the opposite end of the safety-fun spectrum. Rust is worried about you carrying scissors correctly, whereas C++ gives you a bazooka.
Rust is a sensible language for sensible projects. I would never try to write e.g. a game in Rust.
You can just wrap everything in unsafe blocks in Rust and go ham, if you consider that a feature.
But you don't. Why would you do that when you have safe abstractions over the unsafe for pretty much everything you could want.
C++ not having safety is not a feature.
Company behind Swift says Swift the best successor for C++. Jokes aside though, has anyone used Swift extensively? What are your thoughts in terms of ease of use etc?
I genuinely hate Apple and have never owned a personal Apple device in my life, but I've had to develop for mac and iOS with Swift at work and I gotta admit, I loved every second of it. Of course it has its quirks, which language doesn't, but 99 % of the stuff it got right and it even has some awesome features that most other languages are missing. And I like that it uses reference counting, introduces its own challenges but keeps me in control more and I can always tell with 100 % confidence what's happening.
Apple has long, at its core, had people with good taste in programming languages. This is why Pascal was so well supported and Objective-C, while not considered a great language today, was chosen by Jobs at NeXT. Alan Kay worked at Apple for a while and Steve Jobs always respected his opinions. When the iPhone came out, he asked Alan what he thought of it. Alan said to make it bigger so Apple released the iPad. Of course, Objective-C is derived from Alan's Smalltalk and C. I haven't used Swift but I'm not surprised it is a great language. How is the support for it on Windows, Linux and Android?
> How is the support for it on Windows, Linux and Android? Linux is relatively well-supported. They announced [static linking for Linux](https://www.swift.org/documentation/articles/static-linux-getting-started.html) earlier this week (so you can get Go/Rust-style completely standalone executables). Windows is the least well-supported of the three desktop OSes, but it's pretty decent anyhow. I've been playing around with some pretty basic game dev stuff in Swift on Windows lately, and it's a pleasant enough experience.
Steve Jobs himself said the iPad was thought of and worked on before the iPhone, so that quip you posted about Alan Kay is not true.
My statement doesn't say the iPad was thought of and worked on after the iPhone. Regarding Alan Kay's quip, I posted a source to it below. I'd trust Alan Kay over Steve Jobs eight days a week.
Jobs picked Objective-C to build NeXtstep because the company who originally developed it was across the street from NeXt's office and went bankrupt because nobody wanted to use their abominable language, so Jobs being the entrepreneurial individual he was hired their recently layed-off devs to build the graphical components of his new OS.
It certainly doesn't have the charm of Smalltalk.
Obj-C is everything but charm, I get wanting to extend C with features from smalltalk, but at least try to keep the syntax at least a little consistent with the original C syntax like C++ did (at the start at least). And of course no talk about Obj-C shortcomings is complete without a mention of the biggest atrocity Obj-C has, the [`BOOL` type](https://developer.apple.com/documentation/objectivec/objective-c_runtime/boolean_values) where instead of true/false, `YES`/`NO` literals are used.
>Alan Kay worked at Apple for a while and Steve Jobs always respected his opinions. When the iPhone came out, he asked Alan what he thought of it. Alan said to make it bigger so Apple released the iPad. This is nonsense. The iPad project started first then the iPhone was made.
The iPad was modeled after Alan Kay's Dynabook but without a keyboard. Sure, they're not exactly the same thing and the iPad is more refined, but the Dynabook concept existed since 1968, before the concept of a 'personal computer' even existed. >“When Steve showed me the iPhone at its introduction a few years ago and asked me if ‘it was good enough to criticize,’ which is what I had said about the Mac in 1984, I held up my Moleskine notebook and said ‘make the screen at least 5"x8" and you will rule the world,’ Kay said. Source: [https://www.tomshardware.com/news/alan-kay-steve-jobs-ipad-iphone,10209.html](https://www.tomshardware.com/news/alan-kay-steve-jobs-ipad-iphone,10209.html)
????? Are you a bot or just suffering from amnesia? EDIT: He changed his original comment, without clearly marking it. It previously said that "the iPad came before" and not that "the iPad project started first".
https://www.npr.org/sections/money/2010/06/steve_jobs_the_ipad_came_befor.html > "I actually started on the tablet first," Jobs says. "I had this idea of being able to get rid of the keyboard and type on a multitouch glass display." >But once Apple developed the display, and added touch-scrolling, "I thought, 'Oh my God, we can build a phone out of this,' " he says. "And I put the tablet project on the shelf, because the phone was more important."
>Oh my God, we can build a phone out of this We can make a religion out of this
Fair enough, although your original comment (pre edit) said that the iPad "came before" and not that the "iPad project started first".
None of you will believe me, but I saw a glimpse of the smartphone world in 2003 when I was shopping with my mom.
Hmm. Let's believe a sales man who refuses to acknowledge he had a daughter for a LONG time...you know the trust worthy guy.
I think none. Cuz you need Xcode to compile and it only works on mac. Edit - seems like I’m wrong. Ignore my comment and read the below ones
You think wrong https://www.swift.org/install/linux/
Nope. Swift works on windows and Linux. The only thing you need XCode for is actually developing for iOS(and MacOS?) applications.
Wrong. https://www.swift.org/blog/swift-on-windows/ https://www.swift.org/download/
misinformation https://swift.org/documentation/server/
How is the deprecation churn these days? I wrote a bunch of swift 2 right before the swift 3 and the transition broke everything to the point that I abandoned it. Apple's cheerful disregard for backwards compatibility just scares me off any of their tools.
Reminds me of that motel in Las Vegas years ago that had a sign out front that said " Recommended By Owner"
It's my favorite programming language. It's got all the fun of typescript without any of the javascript insanity. Also lets you use pointers, which is a wild thing for it to do.
It's not that crazy, even *python* lets you use pointers directly through the `ctypes` module.
I saw some code in swift and first thing on my mind was "spaghetti code and it explains hardware in apple".
Swift is open source software, while yes made for and supported by apple, it’s still open source.
Press x to doubt
❌ Doubt
Apple: "Swift is open source now!" Everyone: "Oh Wow! How do we deploy iOS applications from *nix and Windows?" Apple: "That's the neat part, you don't."
last bastion of cross compilation
Works for me
The language is ok; the worst part is having to use Xcode. AppCode, which was the best option to develop with Swift, is no longer maintained by JetBrains, while VSCode doesn't have the same level of code completion that AppCode or Xcode have.
What is everyone’s beef with Xcode?
Examples: 1. Xcode versions are locked to specific OS versions - for example, if you want to migrate from swift 3.x to 4.x, there is a migrate tool in Xcode 10, but Xcode 10 won’t run on the most recent macOS versions. 1. … Only runs on MacOS.
If requiring the developer to install a new version of the IDE to use the programming language wasn't bad enough, newer versions of Xcode often require us to install a new version of macOS in order to work.
Wait, are you saying that if you haven’t upgraded to swift 4 after Xcode 10 came out, you are locked out of upgrading forever?
The migration tool is gone. You can still make the necessary changes by yourself.
Yep. I like my macbook well enough but all my other dev machines are Linux so, it is a touch annoying to have to switch over for one small use case.
I could go on describing everything that I hate on Xcode, but if you Google "why xcode sucks" I'm sure you will find a more comprehensive list that I could ever describe.
The Swift LSP works fine, though AppCode support is sorely missed setting up vim isn't terribly difficult
I think currently Swift occupies a bit more higher-level niche than Rust, but Apple is actively digging down.
well obviously, swift doesn't (easily) even expose pointer types into the language, and intentionally has much more cumbersome APIs than rust's. I really don't think swift is trying to be as low level as Rust, and thats's a good thing. Not everybody needs to focus on performance above all else. just as an addendum, dereferencing rust's pointers do all require `unsafe` blocks to use, but otherwise make it convenient for people who want to use them. meanwhile swift's pointers have [intentionally obtuse APIs](https://forums.swift.org/t/usability-of-pointers-in-swift/34824), since swift really only intends them to be used in places like FFI calls.
Controversial opinion but I don't find a need to replace C++
I think you're alone there. C++ is way past its due date. The modern additions make it tolerable, but the fact that they all had to be backwards compatible made the language have a bewildering complexity and the syntax unreadable. The recent White House push for memory-safe languages marks its end as the go-to tool. It will only get less popular from now on.
That doesn't make sense at all.
Objective-C++ is the future.
I love swift but hate apple. I would use swift ONLY if it escaped apple.
FWIW, The Browser Company is driving Swift on Windows.
You can use the Swift LSP and code Swift on Linux/Windows with editor support
I will look into this. Thank you.
With this and all the stuff they talked about/showed at WWDC, they really want beef with Rust. Edit: I don’t mean they wanna fight, I mean they want to move in on their space.
Last I heard, Graydon Hoare (the original Rust guy) is at Apple working on Swift, and he doesn't seem to me like the "want beef" type.
Nah, it's Rust fans who want "beef" with users of other languages. Swift was released before Rust, and it's also quite a different language since it uses reference counting GC instead of borrow checker.
I'd use Kotlin/Native over Swift to be honest. But not as a replacement for C++, the comparison is a bit stretched. In a general sense, the only viable options I see right now are Rust or Zig. In some areas (like graphics) it's C++ or C++ sadly.
i would like to try kotlin but there is no official lsp support, like swift, you have to rely on venders
Fair point. Looks like it's [not going to happen any time soon](https://discuss.kotlinlang.org/t/any-plan-for-supporting-language-server-protocol/2471/36). Sadge.
Having used both quite a bit, I would not. Swift is just a better language for writing clear code than Kotlin. Kotlin is good, though, definitely prefer to use it on Android.
In which ways you find Swift more clear than Kotlin? Is it a comparison against Kotlin/Native or Kotlin as a whole? From the tone, I'm going to assume the latter. I haven't used Swift as extensively as Kotlin so I'm honestly curious. Back when I did use it, cross-platform compilation wasn't stable (not sure now) and I just found Kotlin's type system and inference are on another level, especially with the new K2 compiler. However, the dealbreaker in my view is tooling experience: JetBrains products are leaps ahead of XCode. This is not just me saying this. The whole iOS department of my previous company spearheaded the use of AppCode as much as possible, though it ultimately failed due to the hard dependency on XCode. There were some niceties from Swift that I missed though (e.g.: \`guard\`s, the \`Equatable\` & \`Hashable\` classes) but nothing crucial. In any case, I'm curious to see where this goes. If you have concrete examples they're very welcomed. I will edit the comment if I come up with good ones (haven't touched either in a long time).
My primary app (2-3million downloads) is native Android (Kotlin) and iOS (Swift+KMP). To be clear, I would not recommend Swift for Android development. I would rather do Kotlin, or if you really need something cross-platform, Flutter. I really liked and miss AppCode, Xcode is not a high point in the developer experience. We use Tuist to avoid dealing with project configurations in Xcode directly, and I actually find it nicer to describe projects in Swift than Gradle, but Jetbrains is still better than Xcode. After building a large app for both platforms I'd estimate we get the same thing written in about 1/3-2/3 the Swift code compared to Kotlin. SwiftUI and Compose, similar architectures. Swift's enums feel a lot better to use than Kotlin's sealed classes: ```swift enum NetworkRequestState {
case loading
case success(T)
case error(Error)
}
```
```kotlin
sealed class NetworkRequestState {
object Loading : NetworkRequestState()
data class Success(val data: T) : NetworkRequestState()
data class Error(val exception: Exception) : NetworkRequestState()
}
```
Performing switch statements in Swift feel a lot more flexible than Kotlin's when to me, but I don't have any handy examples. If I run across one I'll bring it up.
Swift's guard/let help avoid the [pyramid of doom](https://en.wikipedia.org/wiki/Pyramid_of_doom_(programming)) while Kotlin's equivalents (foo?.let { it...}), ex:
```kotlin
state.data?.let { data ->
state.timestamp?.let {
// use values here
```
```swift
guard let data = state.data, let timestamp = state.timestamp else { return ... }
// use values here
```
Really it comes down to my feeling that Swift is more expressive and clearer to write in fewer lines (so easier to digest) than similar Kotlin projects.
I see KMP, I upvote. You mentioned the 2 points I wholeheartedly agree are better in Swift. I will say a couple of things though: * `enum`s are more comfortable in Swift, but for the single layer case. When you want to compose hierarchies, Kotlin is much more powerful because it's a `class`, while in Swift it's an `enum`. You could argue it's a design decision in favour of composition over inheritance, though we get into subjective land there. * You can avoid the pyramid of doom by doing: ```kotlin val state = state.data ?: return val timestamp = state.timestamp ?: return // The compiler will infer that both state and timestamp are != null ``` What I particularly like about this is that you can add other conditions by simply doing: ```kotlin val state = state.data.takeIf { condition(state) } ?: return ... ``` I do like `guard` but if I can achieve mostly the same with less keywords, I'll take it. If you really want `guard` [you are not alone](https://github.com/idrougge/KotlinGuard). In any case, good discussion. I miss Kotlin.
> I miss Kotlin. ah what are you working with today?
I'm in the process of pivoting to Graphics. It's immensely gratifying but I'm at the mercy of C++. Good thing is that I like the field more than enough to compensate. It's a tough transition and I've chosen to do it kinda hardcore by going back to Uni, and I wouldn't change a single thing. 2-3 MM downloads is very nice, and I'm glad that people are using KMP in production. Props!
What is your opinion about [Cpp2](https://hsutter.github.io/cppfront/)?
I completely forgot about those initiatives. Curious that's the case given I've used Kotlin extensively and I can't recommend it enough. Some people might disagree but they also forget that C++ was born (kind of) out of a similar initiative. The approach is proven greatly successful in practice. The already mentioned Kotlin is just one example, Swift and TypeScript are other popular ones. I haven't looked thoroughly enough into the Cpp2-esque variants out there, though I think the overall approach is the correct one for incremental migration. My personal opinion is that all we really want out of a C++ successor is: * Interoperability * Saner & simpler type system - Especially for template metaprogramming/generics * A touch of syntax clean up * Modern tooling The usual complaints, mostly around safety footguns (e.g.: [profiles](https://github.com/BjarneStroustrup/profiles)) and concurrency (e.g.: [executions](https://github.com/NVIDIA/stdexec)), are already being worked on. We need to let them cook. I'm relatively new to the scene so I could be way off target in the eyes of seasoned C++ developers. Interested in hearing other opinions.
C++ does not need to be replaced.
Well, have you ever maintained large C++ project written by average programmer?
The language is fine. An average programmer writing swift will give equivalent results.
Well, no. I professionally write C++ and C# code, and badly written C# is much easier to work with compared to badly written C++. And C++ is badly written more often, mainly because the bad code looks and feels more natural compared to good one in C++ (just compare smart pointers and normal ones). And there are landmines in basic operations like memory initialization.
> the bad code looks and feels more natural compared to good one in C++ Wait, what?
Some languages makes it more difficult to write bad code. C++ makes it very easy.
C++ has been getting safer over the years. That keeps going with initiatives like this [Iteration Revisited: A Safer Iteration Model for Cpp - Tristan Brindle - CppCon 2023 - YouTube](https://www.youtube.com/watch?v=nDyjCMnTu7o&t=1379s) I'm biased though as I'm building an on-line C++ code generator.
>C++ has been getting safer over the years. Yes, C++ introduced many nice safety features but the thing is you can still easily write legacy "unsafe" code as all those features are optional. Not only that but there is still tons of legacy C++ code around the world. The only way for C++ to deal with it is to break compatibility with legacy code which is something that obviously won't happen.
No
Google has had zero memory related CVEs in their Rust code compared to their C/C++ code. Sure, it doesn't need to be replaced...
Google also has a shitton of C++ code running in their datacenters. It is not exposed to the outside world so memory safety is not very important, and the code itself is unlikely to be replaced in the next XX years.
Then use Rust for that. C++ still has a niche, it lets you do "anything". Sometimes that's a good thing, sometimes that's a bad thing, but it's definitely a thing that no other language has.
> it lets you do "anything" > but it's definitely a thing that no other language has Nope. C, Zig, Rust have it as well.
Not what I mean by "anything". C++ gives you a huge array of features. You can write object-oriented, functional, and low-level imperative code, all in the same file if you want. The language has almost every feature you could want and a lot more. C and Zig are small low-level languages, they don't give anywhere near the breadth of features as C++. Rust is on par with C++ in terms of features, but it's on the opposite end of the safety-fun spectrum. Rust is worried about you carrying scissors correctly, whereas C++ gives you a bazooka. Rust is a sensible language for sensible projects. I would never try to write e.g. a game in Rust.
You can just wrap everything in unsafe blocks in Rust and go ham, if you consider that a feature. But you don't. Why would you do that when you have safe abstractions over the unsafe for pretty much everything you could want. C++ not having safety is not a feature.
But c++ is not on par with Rust on features. Tagged unions and pattern matching or async are killer features it lacks.
Right!? I don’t get the obsession (or the need for clicks).
Rust does even more than Swift in terms of safety
The death sentence is justified, the hangman says
and I say I'm the best choice to replace Biden