Introducing a Memory-Safe Successor Language in Large C++ Code Bases - John McCall - CppNow 2023
Vložit
- čas přidán 28. 05. 2024
- www.cppnow.org
/ cppnow
---
Introducing a Memory-Safe Successor Language in Large Code Bases - John McCall - CppNow 2023
Slides: github.com/boostcon/cppnow_pr...
---
Interest in memory-safe programming has never been higher, but how can you adopt it in an existing, large C++ code base without rewriting massive amounts of code at once?
One tempting approach is to incrementally improve C++ by bringing the ideas from memory-safe languages back to C++. However, this path has inherent hard limitations forced by the language and library design. New languages offer the chance to start fresh with a memory-safe model, providing language affordances to make memory-safe programming the ergonomic and high-performance default. But the introduction of a new programming language in an existing code base typically requires widespread rewrites or the creation of large stub libraries.
Swift is a memory-safe, multi-paradigm programming language designed from the beginning with fast, native bidirectional interoperability with the C family of languages. Swift code can be introduced into an existing code base a single file at a time, allowing large code bases to adopt incrementally, for example by implementing new features in Swift or performing targeted rewrites of problematic or safety-critical code.
This talk will explore the key design aspects of Swift that make it uniquely suitable for integration into existing code bases. It will demonstrate how we’ve made use of Swift’s nascent C++ interoperability feature to bring Swift’s safety and expressiveness to large, established C++ code bases without massive rewrites. Along the way, we’ll reflect on lessons learned from our rollout of a new, memory-safe language throughout a large software ecosystem, in the hope that it can help the C++ community chart a path forward to a memory-safe future.
---
John McCall
John McCall has worked on programming languages at Apple for fifteen years. He is a language designer for Swift, for which he serves as the Chair of the Language Workgroup in charge of language and standard library evolution, as well as on Objective-C and many of Apple's language extensions to C. He is also a compiler and runtime implementor on both Swift and Clang and is a code owner of LLVM IR generation in both compilers. John helped bring up C++ support in Clang, including implementing core language features such as access control and exceptions. He also led the design and implementation of a number of memory safety and security features, such as automatic reference counting (ARC) in Objective-C, Apple's ABI adoption of ARMv8.3 pointer authentication in C, Objective-C, and C++, and the basic implementation design of Swift.
---
Video Sponsors: think-cell and Bloomberg Engineering
Audience Audio Sponsors: Innoplex and Maryland Research Institute
---
Videos Filmed & Edited By Bash Films: bashfilms.com/
CZcams Channel Managed & Optimized By Digital Medium Ltd: events.digital-medium.co.uk
---
CppNow 2024
www.cppnow.org
/ cppnow
---
#boost #cpp #swiftprogramming - Věda a technologie
"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.
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.
Very interesting!
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.
35:53 you got the Fahrenheit to Celsius formula wrong :)
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!
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.
the audio of a large portion of talk sucks
Bad audio quality