"We're not going to let those languages [C++] hold us back. There are better languages out there, Swift is one of them. And we need to move forward. [applause]"
I live in hope that people are starting to make progress. For some years now I have watching many presentations at C++ conferences and it seems that they have been increasingly focused on all the reliability problems of C++. Usually including presenting an endlessly growing mountain of rules and guidelines to avoid them. Now I see audiences start to enthuse about abandoning C++ moving on to safer more robust languages. Happily those alternatives are coming along nicely:)
Yet current state of Swift in 2024: - average performances (not even close to replace c/c++ perf wise). - overly complex type / generic / protocol / existential system. Not only making the program difficult to reason about but make compiling take so much longer, and you will spend most of your time fighting the type system instead of being productive. (try to serialize heterogeneous arrays just to give it a try). Arrays of existential which are supposed to give some flexibility actually uses twice more memory than concrete types and hinder performance with additional indirections. Also existentials do not conform to their own protocol and they stated this case is probably not solvable (so much for the "we think we can solve all issues" at the end of the conf). - broken compiler / debugger / autocompletion / diagnostics. You can't even print the value of a variable most of the time and it takes forever just to get a single value. We are back using print everywhere as breakpoints are so slow and so buggy. If you make mistakes in your code, (even worst in swiftUI), the compiler analysis will either give up, point to the wrong line or give you an unhelpful message. - Over complex concurrency with Actors that nobody gets correctly (also because of lack of documentation as usual with Apple) and which is brought up constantly on Swift Forums. - broken Macro system with huge performance issues. For the last two: some will say "it's new and we should be patient" but that's what we have been hearing since the beginning of Swift. And things *never* get fixed. We haven't been able to get reliable basic stuff like debugging or refactoring in 10y now. Just to name the latest one: Xcode 14 -> Xcode 15, same code, takes twice the time to compile. Still not fixed. The fun part of the talk is how McCall points all the issues of C/C++ but not WHY people have putting up with them for so long: performance. You want to replace C/C++, your language should be as performant as them. If not, you can solve every safety problems you want, it won't. People who don't need performance already switched to other programming languages with managed memory. What will replace C/C++? Zig, Odin, Jai, Rust, to name a few. The difference? Those languages are built bottom up and not top down with dogmatic principles like Swift or Haskell. You take Odin for example, not even 1.0, already battle tested in production with a huge and successful app showing incredible performance. Unlike Odin, Zig, Jai, who are created by performance expert from day 1, most programming languages are created by programming language theoreticians. That's their expertise: theory, not making products which is the end goal of all programming languages. Pragmatism vs Theory, pick your camp. I am a Swift programmer since day 1, but I am getting tired to wait for them to deliver on all their broken promises. So looking for alternatives.
You can avoid using existentials with 'some' keyword. But at the same time they left semi-generic protocols with assotiative types and by adding 'some' now we can use semi-generic protocols as a types. Before it was possible to use them as a generics constraint only. Quite weird for me but i am not an expert in compilers but tired of it as well :)
There is no "previous instance", as init is not an instance method, you cannot even invoke it directly - it even lacks the func designator. It is a constructor called this way: var t = Temperature(celsius: ) or var t = Temperature(fahrenheit: ). As things are getting constructed here, memory is allocated for them, then the proper init method is called to set everything up.
Side note: in the example of use of unitialized memory, both clang and MSVC warn that len is potentially uninitialised. Gcc doesn’t, but clearly it is possible to spot these particular kinds of errors without having to create a new language.
That's naturally a "fits on a slide" simplified example, but imagine a case where a value is initialized via an out `Result *` parameter. A function might return a non-zero error code (which you might forget to check), and have left your `Result` uninitialized. Statically detecting that (in the general case) becomes impossible, as the initialization logic becomes non-local, and impossible if the function's definition isn't visible.
Yeah Rust solves most of these problems, it is even specifically designed to solved these problems. But I their main problem is building on top of C++ and Rust doesn't seem very good at that
I tried rust and it is super nice. I went back to swift because after a hello world kind of aha Rust became very fast very difficult. Swift is difficult too but it seams to show you this difficulties later on in the process. So both are good just I already like the approach of c in swift. If they managed to do the same thing for c++ this is a big win!
"We're not going to let those languages [C++] hold us back. There are better languages out there, Swift is one of them. And we need to move forward. [applause]"
... at a C++ conference.
Swift is from apple? No good
I live in hope that people are starting to make progress. For some years now I have watching many presentations at C++ conferences and it seems that they have been increasingly focused on all the reliability problems of C++. Usually including presenting an endlessly growing mountain of rules and guidelines to avoid them. Now I see audiences start to enthuse about abandoning C++ moving on to safer more robust languages. Happily those alternatives are coming along nicely:)
Thanks Mr. McCall! Great talk
Awesome presentation! Seems like the Carbon project has a really mature competitor.
Not really. No one is lining up to bend over for Apple.
Yet current state of Swift in 2024:
- average performances (not even close to replace c/c++ perf wise).
- overly complex type / generic / protocol / existential system. Not only making the program difficult to reason about but make compiling take so much longer, and you will spend most of your time fighting the type system instead of being productive. (try to serialize heterogeneous arrays just to give it a try). Arrays of existential which are supposed to give some flexibility actually uses twice more memory than concrete types and hinder performance with additional indirections. Also existentials do not conform to their own protocol and they stated this case is probably not solvable (so much for the "we think we can solve all issues" at the end of the conf).
- broken compiler / debugger / autocompletion / diagnostics. You can't even print the value of a variable most of the time and it takes forever just to get a single value. We are back using print everywhere as breakpoints are so slow and so buggy. If you make mistakes in your code, (even worst in swiftUI), the compiler analysis will either give up, point to the wrong line or give you an unhelpful message.
- Over complex concurrency with Actors that nobody gets correctly (also because of lack of documentation as usual with Apple) and which is brought up constantly on Swift Forums.
- broken Macro system with huge performance issues.
For the last two: some will say "it's new and we should be patient" but that's what we have been hearing since the beginning of Swift. And things *never* get fixed. We haven't been able to get reliable basic stuff like debugging or refactoring in 10y now. Just to name the latest one: Xcode 14 -> Xcode 15, same code, takes twice the time to compile. Still not fixed.
The fun part of the talk is how McCall points all the issues of C/C++ but not WHY people have putting up with them for so long: performance. You want to replace C/C++, your language should be as performant as them. If not, you can solve every safety problems you want, it won't. People who don't need performance already switched to other programming languages with managed memory.
What will replace C/C++?
Zig, Odin, Jai, Rust, to name a few.
The difference? Those languages are built bottom up and not top down with dogmatic principles like Swift or Haskell. You take Odin for example, not even 1.0, already battle tested in production with a huge and successful app showing incredible performance. Unlike Odin, Zig, Jai, who are created by performance expert from day 1, most programming languages are created by programming language theoreticians. That's their expertise: theory, not making products which is the end goal of all programming languages.
Pragmatism vs Theory, pick your camp. I am a Swift programmer since day 1, but I am getting tired to wait for them to deliver on all their broken promises. So looking for alternatives.
You can avoid using existentials with 'some' keyword. But at the same time they left semi-generic protocols with assotiative types and by adding 'some' now we can use semi-generic protocols as a types. Before it was possible to use them as a generics constraint only. Quite weird for me but i am not an expert in compilers but tired of it as well :)
Did he discuss rust at all? if so, what did he say about it? and why did he consider swift a superior alternative?
Very interesting!
35:53 you got the Fahrenheit to Celsius formula wrong :)
At 36:20 when we init with Fahrenheit, do we create a new instance? Does that allocated new memory and free the previous instance?
There is no "previous instance", as init is not an instance method, you cannot even invoke it directly - it even lacks the func designator. It is a constructor called this way: var t = Temperature(celsius: ) or var t = Temperature(fahrenheit: ). As things are getting constructed here, memory is allocated for them, then the proper init method is called to set everything up.
I enjoyed the talk, but oh man was it distracting when he used the wrong formula for Fahrenheit to Celsius 😂
Side note: in the example of use of unitialized memory, both clang and MSVC warn that len is potentially uninitialised. Gcc doesn’t, but clearly it is possible to spot these particular kinds of errors without having to create a new language.
That's naturally a "fits on a slide" simplified example, but imagine a case where a value is initialized via an out `Result *` parameter.
A function might return a non-zero error code (which you might forget to check), and have left your `Result` uninitialized.
Statically detecting that (in the general case) becomes impossible, as the initialization logic becomes non-local, and impossible if the function's definition isn't visible.
Feels like how referencing work in rust, right?
Yeah Rust solves most of these problems, it is even specifically designed to solved these problems. But I their main problem is building on top of C++ and Rust doesn't seem very good at that
I tried rust and it is super nice. I went back to swift because after a hello world kind of aha Rust became very fast very difficult. Swift is difficult too but it seams to show you this difficulties later on in the process. So both are good just I already like the approach of c in swift. If they managed to do the same thing for c++ this is a big win!
the audio of a large portion of talk sucks
Bad audio quality