Name: NDC TechTown 2025
Start: 2025-09-22
End: 2025-09-25
Location: NDC TechTown

The main focus of the talk are vectorization inhibitors: parts of your C++ code that prevent automatic compiler vectorization. We give examples of unvectorized loops, we examine CLANG's vectorization report and we give solutions that will make codes several times faster with minimal modification.

Talk (60 min)

Faster programs with your compilers autovectorization feature

Technique

In this talk, we will focus on what really goes wrong in the C++ industry. We’ll talk about the 10% bubble, i.e. the fact that the vast majority of “C++ developers” is not fully aware of the state of the art and does not use the recommended tools and features. We’ll take a look at the reason why current teaching material
is not consequently updated to the newest best practices. And finally, we’ll consider the lack of investment into good programmers. Although initially it may sound like a legacy problem, we’ll come to realize that C++ has a people problem.

"No matter what they tell you, it's a people problem" (Gerald Weinberg)

The Real Problem of C++

This talk will focus on the most significant practical challenges faced when working with std::expected, providing insights into common pitfalls and offering potential solutions. While some of these challenges are addressed in separate libraries, others are not. Much of the functionality discussed in this talk is not available in the standard library. However, I’ll demonstrate real-world code samples and point to open-source helper utilities that address some of these gaps.
This talk will be useful for software engineers looking to understand the limitations of std::expected, explore possible workarounds, and even contribute to the evolution of this abstraction by submitting proposals for future improvements.

Preliminary outline
1. Briefly about std::expected
2. Issue #1: The same type of error and value are allowed
3. Issue #2: A can of worms: having monadic and regular interface altogether
4. Issue #3: No customisation points when a value or error cannot be accessed
5. Issue #4: No built-in back and front binders for arguments
6. Issue #5: Not enough monadic operations (an applicative-like functionality)
7. Bonus: generic unwrap (aka access value) mechanisms
8. Conclusions

Five Issues with std::expected and How to Fix Them

In this talk we'll explore how to set up comprehensive testing of embedded software in Rust. While this talk will be focused on Rust, the principles can be applied to other languages as well.

Comprehensive testing of embedded software

Testing

Rust

Keynote

When to give up, and how?

Yet adopting a new language is a complex process, and not one to be taken on lightly; there are many trade-offs involved from hiring and training to compatibility and maintenance. Rust is not the right answer to every problem everywhere, nor is *now* necessarily the right timing for you. And unfortunately, it can be difficult to assess the trade-off space in adopting Rust without significant experience on both sides of the fence: both in Rust and in the technology you work with today.

So, we're bringing together a panel of experts to discuss when, where, and why Rust is, and isn't, appropriate, based on their experience across languages and domains. Their goal is to help separate myth from fact, critically evaluate where and how Rust can deliver value in practice, and answer questions people may have that make them uncomfortable with the idea of adopting the language.

These kinds of panels work best when they help the audience answer *their* questions, so please do submit questions in advance to the panel host at TODO.

[Panel] Rust: when, where, and why

Language

This talk will detail our approach to building a flexible and efficient serialization library in C++. Inspired by libraries like cereal but designed for the unique constraints of embedded systems, our solution enables complex data formats to be implemented declaratively - minimizing code duplication across serialization, deserialization, and logging.

Attendees will gain insights into leveraging C++ templates and concepts to design serialization systems that balance adaptability with maintainability.

Adventures in Serialization: A Flexible Approach for Embedded Systems in C++

We’ll look at which standard algorithms can be parallelized and how their behavior changes when you apply parallel execution. I’ll also show you a few special algorithms that are only available in the parallel world.

Then, we’ll dive into execution policies: what they do, when to use which one, and what their trade-offs are. Along the way, I’ll share small examples to make the concepts easier to grasp and explain the reasoning behind the design choices.

To wrap up, we’ll talk about the current limitations of this approach, and I’ll give you a quick peek at what’s coming next in the C++ standard related to parallelism.

If you’re curious about parallel features in C++ and want a hands-on introduction - this session is for you.

Parallel Algorithms: Work Smarter, Not Harder

In this talk, we’ll go beyond theory and dive into what it really takes to deliver OTA at scale. You’ll get a breakdown of architectural patterns, tooling options, and the real-world tradeoffs you’ll face when deploying firmware updates to constrained devices — often with unreliable connectivity, limited storage, and mission-critical uptime requirements.

OTA Updates in the Wild: Lessons from the Field

In this talk, we'll discard all abstraction layers to uncover the intricate details of our CPU, whether they are disclosed or not. Through hands-on reverse-engineering techniques focused on a specific x86 CPU, we aim to unlock significant performance enhancements for our code. While our focus is on an x86 architecture, these techniques are transferable to any type of CPU and architecture. After this talk, I hope you see reverse engineering as not only insightful but also downright fun!

Unlocking Performance Through Reverse Engineering

How to declare a constant in C++

Block-based programming models divides inputs into local arrays (tiles) that are processed concurrently by groups of threads (blocks). Users write sequential array-centric code, and the framework handles parallelization, synchronization, and data movement behind the scenes. Block-based models have been around for a long time, but in recent years, they've grown in popularity for GPU programming in languages such as [Triton](https://openai.com/index/triton/), [JAX/Pallas](https://docs.jax.dev/en/latest/pallas/index.html), and [Warp](https://nvidia.github.io/warp/modules/tiles.html), aiming to make parallelism more accessible and increase portability.

In this example-driven talk, we'll cover the basics of block-based programming in both Python and C++. We'll present cuTile, NVIDIA's new block-based programming model for Python, C++, and other languages, and Tile IR, the new compiler stack that it is built with. We'll reveal new details about this new technology for the first time in this talk. We'll compare and contrast block-based models with traditional parallel programming models.

We'll look at a variety of examples, including a new tile-based [LLAMA3](https://github.com/meta-llama/llama3)-based large language model demo, a stencil code, and an FFT solver.

In this session, you'll:
- Learn the best practices for writing block-based parallel applications for CPUs and GPUs.
- Gain insight into the performance of block-based code and how it actually gets executed.
- Discover how to reason about and debug block-based applications.
- Understand the differences between block-based and traditional parallel programming and when each paradigm should be used.

By the end of the session, you'll understand how block-based programming enables more intuitive, portable, and efficient development of high-performance, data-parallel applications.

Block-Based Parallel Programming

Tools

Python

We will deepen the discussion by looking into some of the software solutions developed at Six Robotics, and how we believe software-driven swarm robotics will shape the future of defence.

Swarmfare - When the shit hits a thousand fans

Product

The first half of this talk begins with a quick refresher on what modules are and the problems they aim to solve. From there, we'll explore the current state of compiler support, real-world adoption, and how build systems are (or aren’t) keeping up.

The second half of the talk focuses on the new possibilities that C++ modules open up for build systems. By offering clear module boundaries and better encapsulation, modules pave the way for smarter, more scalable build tooling. We'll explore how these features could enable a more streamlined, cargo-like experience in C++, with automatic dependency resolution and simplified project structures.

C++20 Modules, 5 Years Later

I will describe the project, how it came about and why Rust in cars is a great idea!

Rust at Volvo Cars

If you've ever used a regex, a programming language, markup language or even a data format, there has most likely been a parser involved. Maybe even a parser generator!

In this session, we'll be exploring the process of parsing. We'll start from scratch with the basics and expand our knowledge. Armed with some fundamentals, we'll look at real-world applications like regexes and programming languages and show how the different types of parsers are suited for different tasks.

A bird's eye view of a parser

Data-Oriented Design (DOD) presents a different way of thinking: prioritizing data layout not only unlocks significant performance gains via cache efficiency but can also lead to surprising simplicity in the code that actually processes the data.

This talk is a practical introduction for C++ developers familiar with OOP. Through a step-by-step refactoring of a conventional OOP design, we'll both cover how data access patterns influence speed and how a data-first approach can clarify intent.

We’ll measure the performance impact with benchmarks and analyze how the refactored code, particularly the data processing loops, can become more direct and conceptually simpler.

Key techniques like Structure-of-Arrays (SoA) vs. Array-of-Structures (AoS) will be explained and benchmarked, considering their effects on both execution time and code clarity. We’ll pragmatically weigh the strengths (performance, simpler data logic) and weaknesses of DOD, highlighting how it can complement, not just replace, OOP.

We'll also demonstrate that DOD doesn't necessitate abandoning robust abstractions, showcasing C++ techniques for creating safe, expressive APIs that manage both complexity and performance.

Let's learn how thinking "data-first" can make your C++ code faster and easier to reason about!

More Speed & Simplicity: Practical Data-Oriented Design in C++

Akiles is a manufacturer of access control devices and have been using Rust to program our embedded devices for over 4 years. Embedded Rust projects like Embassy started at Akiles, and have since flourished and grown into a widely used open source project.

This talk will give an introduction to the Embedded Rust ecosystem, async Rust, and share our experience using Rust in production at Akiles.

Embedded Rust in Production

You’ll get a peek into the inner workings of breakpoints, register and memory manipulation, debug information, stepping, stack unwinding, expression evaluation, and more. X64 Linux systems will be used as an example, but most of the concepts are applicable to other platforms.

How Debuggers Work

In this talk, we will demonstrate function effect analysis and explain how it works. We will also see why it can be hard to enable FEA in the presence of third-party libraries, and what can be done about it.

At Squarehead, we've used FEA almost since its official release to refactor our soft real-time pipeline towards harder real-time. We will present our experience and lessons learned from this process, and the talk will be packed with useful real-life tips, tricks, and practices to set you up for success.

If time permits, we will also demonstrate the brand-new RealtimeSanitizer, the run-time companion to FEA.

After this talk, you'll know how and why to use Function Effect Analysis and RealtimeSanitizer and be aware of real-life tips, tricks, and practices for using them in your own projects.

Real-time Safety — Guaranteed by the Compiler!

Choosing the right tool for the job requires understanding how each works under the hood and where they shine. By exploring how each interacts with the operating system and hardware, this talk will help software engineers build that intuition to make better decisions about which to use, and when to use them.

We'll explore how threads and synchronization primitives work at the operating system and hardware level, from thread creation and scheduling to where context switching and synchronization introduce performance costs. We’ll then contrast this to the coroutine model introduced in C++20, which takes a fundamentally different approach by using a cooperative model based on the suspension and resumption of work.

Given this understanding, we’ll apply this intuition to a set of real-world scenarios to identify whether threads or coroutines are a better fit for the problem at hand.

Threads vs. Coroutines: Understanding C++’s Concurrency Models

I’ll go through how we at Neat have used Python Behave for almost four years now to create automated tests covering just about every feature of our videoconferencing devices’ behavior. While it doesn’t hurt that our tests are eminently human readable, Behave also shines as an endlessly adaptable test automation framework. It’s also effective, since it follows in the footsteps of Robot Framework and lets you build up your test cases from reusable test steps, thus accelerating the speed of test automation over time as your collection of reusable test steps grows.

With real world code, we’ll take a look at web automation with Playwright and blisteringly fast GUI-automation of native Android apps with uiautomator2. In both cases we’ll use a Python-based page object model framework that isolates tests from GUI changes arguably better than any other page object model solution available.

From there we’ll integrate with a low-level C++ API and even fluently incorporate machine learning based asserts in production tests.

We’ll see that while Python Behave can help you “shift left” and revolutionize your software development process from requirements gathering to end-to-end testing, it may also just be the best test automation framework you’ve never tried.

Test automation with Python Behave without BDD

In this talk, we will explore two readily available options. On the one side, there is MicroPython, an implementation of Python that targets microcontrollers. Python is a powerful and expressive language, and manages its memory with a garbage collector. Unfortunately, it is also famous for its performance limitations, which are even more pronounced in constrained environments.

On the other side, we can reach for Rust, a modern systems language with zero-cost abstractions and ownership-based memory management. As a drawback, the language is arguably more difficult to use, and its ecosystem for embedded environments is (still) not quite mature enough.

What if we could combine the advantages of the two?

This session explores the intersection of the contrasting programming paradigms and how they can coexist within the constrained memory space of a microcontroller. We'll cover the background on both languages’ memory models, and specific challenges encountered when they interact, such as ownership conflicts, buffer aliasing issues, and garbage collection considerations.

We will present the experiences gained when implementing a Rust-MicroPython interop layer, solutions to some of the problems outlined above, and techniques for implementing a safe Rust API for extending MicroPython.

Extending MicroPython with Rust: Two Worlds Collide

Languages

Many interesting developments have happened on all three of those layers over the years, and while contemporary hardware has gone a long way forward, it often suffers from the attention deficit caused by an overshadowing flood of advancements and “advancements” in the software part of the universe. This new shiny programming language is safe, performant, and solves a backlog of problems that have been dragging for long. While that new shiny programming paradigm automagically relieves from dealing with low level details and the toolchain is plain amazing. The hardware side brings into this fistfight a set of new architectures, ISAs, and hardware abstractions – just to stay on par with the software side. Looks perfect? What else would an engineer dream about, no?

Not really. Let’s take a look at the contemporary commodity hardware platforms of today, and also at the trendy software engineering waves of today, and try to sense how and why it could (and frequently does) cross out the potential benefits of hardware advancements – and what could be done to actually be friendly to your underlying hardware, and at what cost.

This is a set of somewhat separate topics, bound together into a common logical set of performance engineering.

How do language constructs such as references, lambdas, inheritance, object representation, runtime checks, and selected STL examples map to the actual runnable platform level code, and at what cost.

The notion of out-of-order execution, claims on whether OoO is superior and there is no need to look at the level of instruction selection. What specifically is out of order in the context of contemporary x86 platforms (surprisingly, it is not instructions), and what impact does it have to the overall performance. A brief look into where the complexity lies inside the contemporary high performance execution cores and sockets, and why aspects such as variable length instruction encoding are trivial to resolve.

Memory hierarchy operation, logical, physical, and geometrical address spaces, their relationship and translations, memory performance in virtual address spaces, and clever ways to hide capacitor array’s latency.

Vectorization and why it is still not there yet universally everywhere, and why it won’t be?

Data dependencies and what could be done about it.

How could one help the compiler to do the right thing, and yet more important – how could one stay away from making things more complex for the compiler to do the right thing.

ABI aspects, parameter passing, compilation unit scope and its impact.

The claims on the imminent obsolescence of x86 and how the new wave of ARM and RISC-V upstarts will overtake it once again after previous not so successful attempts.

This is a reasonably simplified talk on a set of interrelated topics for generalist software engineering audience, motivated by the trends of handwaving on how Rust, Go, Zig, D, and the species yet unseen will take over C with classes and solve all the outstanding problems in the field of performance, security, time to market, and global warming too. A viewpoint is from someone dealing with performance optimization in domains of network engineering, electronic trading, and high performance computing. No specialty background is required and expected from the target audience, although the depth of coverage is targeted for senior engineering staff sufficiently proficient in the contemporary software engineering ecosystem. The content itself would be a lightened-up version of specialty workshops organized for hardware engineers on how software expects to see the platform, and for software engineers on what the underlying hardware actually does; not presented publicly previously. Content could be tweaked according to the target audience profile if you would see a need for that, however it is not expected to be an entry-level talk at all. The level of possible technical opinionated argumentation, reaching up to controllable flaming, is also possible, either via a format of a workshop-style presentation, or a panel discussion.

Performance engineering - being friendly to your hardware

Platform

Along the way we will learn how runtime linking works and how executables and shared libraries are combined into a single application. We will dissect the ELF file format, implement code relocations and stub external dependencies. In the end we will have a small, but fully working standalone program, which can load an external piece of code and execute it.

Workshop (60 min)

Part 1/2: How to execute an object file

Part 2/2: How to execute an object file

Coverage is a major component (for good reason) in the testing cycle
of safety critical systems, such as automobiles, aeroplanes, and
spacecraft, but coverage can be very useful as a programming tool.
Coverage guides testing, and testing correlates with quality.In this talk we will use the coverage capabilities of GCC 15 to
understand and improve programs. We will look for holes in our test
suite, play with program representation/visualization, and try to
finally break coverage out of Goodhart's prison.-

Coverage, quality, and Goodhart's Law

In this talk, I want to share different techniques to increase the likelihood of self-documented code. We will look into how to name variables and functions, how language features can increase readability and how unit tests can serve as documentation of how the code should be used.
Lastly, we are going to explore instances of where a comment is useful and how to write a good one.

The Code is Documentation Enough

Together we'll go over many examples of implicit conversions. We'll test our skills on what conversions exist and why some examples are able to compile.

Hopefully we'll come to some conclusion what "good" vs "bad" implicit conversions and have some guidelines for how to proceed.

Implicit Conversions Considered Harmful

Security

The reason for this is that cryptographic algorithms might leak side-channel information such as timings, power consumption, or electromagnetic emission that depends on secret key material. An adversary that observes the cryptographic computation might (gradually) learn enough information to steal the secrets and break the schemes.

This talk will detail what kind of information might leak, how this can be exploited to break mainstream cryptographic schemes such as AES, RSA, and ECDSA, and how we protect against such leakage when implementing cryptography on embedded devices.

Cryptographic Side-Channels on Embedded Devices

At GET Academy, we have spent years testing alternative methods to educate, train, and connect aspiring developers with the job market. By focusing on competency-based learning, real-world experience, and growth mindset, we have enabled companies to hire developers who might otherwise have been overlooked.


●	Skills-first recruitment – Looking beyond degrees and resumes to assess true capabilities.
●	21st-century skills – Focusing on problem-solving, adaptability, collaboration, and communication as core success factors.
●	Project-based learning – Training developers through real-world coding challenges that mimic the job market.
●	Industry collaboration – Working closely with companies to ensure candidates are job-ready from day one.


Diversity in tech is more than a buzzword—it’s a competitive advantage. Research shows that diverse teams outperform homogenous ones in problem-solving, innovation, and decision-making. Companies like DNB, Google, and IBM have actively sought talent outside traditional recruitment channels, including individuals from underrepresented backgrounds, self-taught programmers, and neurodivergent developers. The results? More creative solutions, stronger teams, and better business outcomes.

In this session, we’ll share concrete examples of how non-traditional developers have entered and thrived in the tech industry. Attendees will leave with actionable strategies for identifying, training, and hiring talent in new ways—helping their organizations grow while contributing to a more inclusive and socially sustainable industry.


●	How non-traditional education models can uncover hidden talent.
●	The business case for diversity and creative recruitment strategies.
●	How to build hiring processes that focus on skills over background.


Join us to explore how thinking outside the box can unlock new talent, create stronger teams, and build a future-proof tech industry.

Thinking Outside the Box – Social Sustainability in Tech Education & Recruitment

In recent years, with the development of diversity of marine data acquisition techniques from marine vessels, marine data grow exponentially in last decade, which forms marine big data. This big data from marine vessels, can then be widely used for performance monitoring, condition monitoring, environmental forecasting, critical situation visualizations, modeling of equipment shutdown/ failures etc., These information from the analysis of big data helps vessel operators to optimize their vessels day-to-day operations.

However, some organization who charter vessels from different companies for their operations finds it difficult to have the complete picture of all these vessels performance. It is therefore essential to solve this gap and where by big data from different vessels can be integrated and analyzed on the same platform. This is a great challenge for organization as marine big data involves privileged, confidential and strategic data, making it vigilant for cyber threat. Therefore, security of data is imperative when it involves more than one data owner. Data security involves in all the process of marine big data management, security in data storage, data access, data computation , data sharing and data supervision must be considered all over marine data management.

The latest improvement in technology has helped organization to deal with the challenges of marine big data such as availability, storage, accessing and sharing in an efficient manner. Thus KM, with assets of such big volume of inter-data from various similar type of marine vessels has the possibility to identify interrelationship between the big data. Deep Learning algorithm has proven to be an effective tool for big data analytics. The deep learning algorithm extracts high-level, complex abstractions as data representations through a hierarchical learning process. Complex abstractions are learned at a given level based on relatively simpler abstractions formulated in the preceding level in the hierarchy. A key benefit of deep learning is the analysis and learning of massive amounts of unsupervised data, making it a valuable tool for big data analytics.

The information retrieval from the online stream of marine big data with the help of deep learning algorithms, provides us the knowledge for optimizing operations. The knowledge gained from a particular process in a vessel can then be transferred over to other similar vessels. This helps in inter-cross knowledge transfer across similar marine vessels systems. For example, voyage of a vessel which resulted in good fuel performance index can be applied while planning a similar voyage for another vessel, a predicted environmental loads on a vessels can be used applied for another vessel to minimize the effects.,

Thus with the help of deep learning technique for marine big data, it is possible to have knowledge transfer which will be help for optimization of ship operations and planning.

Inter-Data Analytics for Optimization of ship operations and planning

This talk tells the story of Computer Lib, the man behind it, and the philosophy that shaped it. It explores how Nelson’s ideas could have led to a very different digital world—one built around open, decentralised knowledge rather than the walled gardens and algorithmic control we have today. What if his vision had won? What would the internet look like if computing had followed the path of Computer Lib instead of Big Tech?

Nelson once wrote that “most authority is malignant.” This is a talk about the man who wanted to dismantle it, and the future we lost when the world ignored him.

Dream Machines and Walled Gardens

A case study of distributing the control of a robotic arm augmented with a hand-held IMU illustrates the robustness and extensibility of using TSN in control applications. In addition, we show how tools can be developed and attached to a running system without affecting critical signal paths. and how this was used extensively when working with the distributed robot controller.

Practical TSN; using NetChan for distributed PoC

In this talk, I discuss the risks and pitfalls of switching to a new compiler as experienced in different projects, as well as the benefits beyond getting access to shiny new language features. The talk will also cover some thoughts and experiences of mitigating those risks.

"Just switch the compiler", they said.

It takes care of all the annoying stuff – platform-dependence, feature flags, dependencies, installation; and leaves you with the task of simply defining your library (and executable), and where your source files are located.

This has been in use at reMarkable while it is still in development among teams that are doing the pulling out of their components, and it's gotten rave reviews from all of them. I hope to share this method for multi-repository product development with the NDC Techtown crowd.

Building C++: It Doesn't Have to be Painful!

Long-term efforts in the standardization of C++ look like to become available in C++26. There is a wide variety of proposals to improve the language, and merging them into the international standard is of utmost priority to the C++ committee.

We will look at those proposals, the current status of the C++26 standard, and their potential impact on the ecosystem and the development landscape.

Towards Correctness, Safety and Security in C++26


That’s the motto of Bazel. In this talk I will give an introduction to the open-source build and test tool developed by Google. The first major release was published by the end of 2019. What is so special about Bazel? It is fast, reliable, multi-platform, scalable and extensible. Everything extracted using a high-level build language similar to Python called Starlark. During the talk I will show you how to define libraries, binaries and tests for C++, as well as for Python and Rust. 

In addition I will show you how to combine languages in a project and how to set up a build toolchain. At the end of the talk I will give you some ideas on extensions that can be added to fit your project and requirements.

Introduction to Bazel

[Bazel](https://bazel.build) is an open source build system popular with large and complex code bases, especially those that combine multiple languages and platforms. Thus it is not surprising that it's gaining traction in the embedded and automotive space. Bazel's motto, "{ Fast, Correct } -- Choose two", is achieved by making each step of the build process reproducible and thus cacheable.

[Testwell CTC++](https://verifysoft.com/en_ctcpp.html) is a proprietary code coverage tool from Verifysoft, and a popular choice for ensuring good code coverage in the automative industry. It relies on instrumenting the source code during the build process as well as generating extra build-time and run-time outputs that are not particularly reproducible or cacheable.

We'll cover how we resolved the impedance mismatch between these two tools:
- Adjusting the Bazel sandbox to allow CTC++ to run successfully from Bazel
- Hacking the intermediate outputs from CTC++ to achieve reproducibility, and thus be able to benefit from Bazel's caching.
- Various bumps we ran into along the way, including some light ELF hacking for fun and profit!


War story from the build system trenches: Integrating Bazel and Testwell CTC++ code coverage

This talk aims to put such CMake knowledge on a firmer foundation. We will introduce modern CMake usage principles, starting from the basics. We will also look at which approaches preceded the modern ones and why they are now outdated.

The goal is to establish a solid understanding of CMake terminology and concepts, which can also serve as a good starting point for further study. CMake offers extensive reference documentation showing the "how," so we will focus on "what" to look for in there and "why."

CMake — From Basics to Building

I'll then look at some other development approaches we could take and see if they could be of use. We'll start with Design by Contract as advocated by Meyers. Investigating its limitations, we then move on to the use of sophisticated type systems. Why are these approaches not used more often? What's the catch?

We'll end with some suggestions for a pragmatic approach which can help you to produce more robust products in real-world situations.

Eliminating bugs: testing is not enough

Qt 5, the previous major version, was closely tied to OpenGL (ES) and the associated shading language. Qt 6 moves away from this tight dependency, introducing abstraction layers for 3D APIs to enable rendering Qt Quick and Qt Quick 3D scenes with Vulkan, Metal, Direct 3D 11 and 12, and OpenGL, while building on open-source source libraries to handle the translation of graphics and compute shaders in a world where target a single 3D API and shading language is no longer an option. With Qt's strong compatibility promises and vast support for platforms and devices, including some relatively exotic ones, all this comes with a number of challenges and compromises. 

In this talk we are going to look at this journey, with real world examples of the fun and no so fun aspects of moving a large 2D/3D framework on to new foundations.

The joys and sorrows of portable, cross-platform 3D graphics in Qt 6

Qt is currently a widely used framework, that has proven to be mature enough to be a industry-quality solution for people that want to develop User Interfaces, however being written in C++ limits the people that can use it. Luckily, a few bindings to newer languages, like Qt for Python have been around to open the doors to new generations of developers, but the problem is not solved. Writing bindings to new languages or even re-writing modules in new languages is an enormous task that needs a better solution.

With that in mind, one of the Qt Framework goals is to find ways of using our technology that has been around for a long time, in a quick manner, without requiring a lot of knowledge of programming languages that are not familiar with our stack.

On this talk, you will learn about a new initiative within the Qt Project that aims to unlock the Qt framework’s features and technology into more programming languages without the need of relying on bindings or learning C++.

No previous experience in Qt nor C++ is required for attending this talk.

The role of new languages in the Future of the Qt Ecosystem

We'll walk through the differences in compilation, visibility, and dependency management compared to the preprocessor-based model. We'll also explore the current landscape of C++ module support across major compilers and briefly examine the state of tooling integration with build systems and package managers. In addition, we’ll discuss the limitations, ongoing ecosystem gaps, and trade-offs that developers should be aware of when adopting C++ modules today.

By the end of this talk, attendees will have a clear understanding of how to begin integrating C++20 modules into their projects, recognizing both the advantages and the current challenges of this evolving feature.

Outline:
- Introduction: Why Modules?
- What Are C++ Modules?
- Traditional Headers vs. Modules
- Compiler Support Landscape
- Build Systems and Tooling for Modules
- Adopting Modules in Projects
- Current Limitations and Practical Considerations
- Future and Current Outlook
- Conclusion: The Future of C++?

Knockin' on Header's Door: An Overview of C++ Modules

Then I talk about the benefits of being able to compile the client proxy for WebAssembly as well as any other target, making multi-platform architectures easier and safer to assemble.

Lastly some speculations on future improvements, especially in terms of enhanced security to prevent incorrect method access at compile time, and also the option of introducing a WASM based migration system to improve version compatibility between clients and servers.

Rustly typed APIs; Strongly typed and authorized JSON RPC with Rust, Procedural macros and a DSL

How hard could it possibly be to write a replacement?

This talk will visit some Rust techniques learned through this effort, and look briefly at how to publish Rust crates.

We'll also look at how random generators work, how to choose one and how to properly "seed" random generators.

That will also take us on a small detour to look at how Linux to generates values you can use a seeds.

We will also take a detour to look at the relationship beteen random generators and crypto algorithms, which will take us all the way back to the Cuban Missile Crisis, a Norwegian crypto unit in The White House, and a random-factory at the Akershus Fortress in Oslo.

Things I learned from developing smallrand

When we think of software and technology we often think in terms of progress and rapid change. Programming languages, however, typically move at a far slower pace. Mainstream languages are still embracing ideas that are decades old. Constructs that developers welcome as new to their language of choice are often older than the developers themselves. And over all this hangs the question, what of the future? How will current trends, from FOSS to LLMs, shape programming languages and their use? In this talk, we will take a tour of the past, present and future of programming languages.

Locknote: The Past, Present and Future of Programming Languages

In this talk, we’ll dive into how Rust enables Tauri’s lightweight and secure architecture, replacing the heavy Electron runtime with a lean, native backend. We’ll explore Tauri’s design philosophy, where Rust handles system-level operations such as file access, process management, and secure communication, while your favorite frontend frameworks (like React or Svelte) power the user interface.

At Squarehead, our adoption of Tauri was driven by its Rust-based advantages: tight memory control, fast execution, and seamless cross-platform capabilities. We’ll share how we leverage Rust’s concurrency and safety features to run performant “sidecar” processes and manage native integrations, all from within Tauri.

By the end of this session, you’ll understand not just how Tauri works—but why Rust is a game-changer for front-end developers seeking performance and reliability without giving up modern web tooling.

Good Bye Electron, Hello Rust + Tauri!

Having seamless interop between the C++ and Rust components is essential for the success of this symbiosis. There are many challenges in this process, but people found various ways to make things "work" - from dealing with ABI compatibility and platform/toolchain guarantees, to going down to C and FFI, to various techniques and tools for generating glue-code between the two languages.

Alas, general-purpose interoperability (not tied to a specific toolchain/IR) without loss of performance has yet to be achieved. Just "making things work" is not enough in the domain space of C++ and Rust; as such, many of the explored solutions so far by the community fail to deliver on all the needed requirements, swinging the wide range between performant and ergonomic.

This presentation aims to highlight all of the interop challenges, some of the explored solutions out there, and tease out the avenues at the forefront of this pursuit.

Rust/C++ Interop: Carcinization or Intelligent Design?

Let’s explore what seems to be the opposite of programming: how we use nothingness in computing, different meanings for different nothingnesses. You’ll come out of this talk having learned Nothing. A deliberate, purposeful, mayhap useful Nothing.

Much ado about noping

This is particularly interesting when it comes to arrays and the myriad was their sizes can be specified. Tucked away in this dark corner is, of course, some undefined behaviors and some defects that the C Standards Committee intends to eliminate in C2Y. We'll discuss all this, and what you can do in the short-term to deal with these issues.

Composite Array Types in C

This talk will break down the basics of making change happen, and show you how to get started, how to get better at it, and how to notice you are doing it. You'll also learn how to shrink your target when the change you're trying to make is too big for right now.

You should see benefits from these techniques right away, and also over the next few decades. Change isn't something other people do, and it isn't something that happens overnight. You can be one of the people who are actively working to change some small thing, and perhaps also some large things. I'll show you what it takes.

NDC { TechTown }

Agenda

09:00 - 10:00 (UTC+02)

Keynote

Hana Dusíková

10:20 - 11:20 (UTC+02)

Real-time Safety — Guaranteed by the Compiler!

Anders Schau Knatten

More Speed & Simplicity: Practical Data-Oriented Design in C++

Vittorio Romeo

Performance engineering - being friendly to your hardware

Ignas Bagdonas

How to declare a constant in C++

Mikhail Matrosov

Comprehensive testing of embedded software

Eivind Bergem

11:40 - 12:40 (UTC+02)

Rust at Volvo Cars

Julius Gustavsson

Five Issues with std::expected and How to Fix Them

Vitaly Fanaskov

Adventures in Serialization: A Flexible Approach for Embedded Systems in C++

Jørn Bersvendsen

OTA Updates in the Wild: Lessons from the Field

Jana Perić

Unlocking Performance Through Reverse Engineering

Patrick Schittekat

13:40 - 14:40 (UTC+02)

[Panel] Rust: when, where, and why

Jon Gjengset

How Debuggers Work

Sy Brand

Faster programs with your compilers autovectorization feature

Ivica Bogosavljevic

The Real Problem of C++

Klaus Iglberger

Test automation with Python Behave without BDD

James Westfall

15:00 - 16:00 (UTC+02)

Block-Based Parallel Programming

Bryce Adelstein Lelbach

Threads vs. Coroutines: Understanding C++’s Concurrency Models

Conor Spilsbury

Embedded Rust in Production

Ulf Lilleengen

A bird's eye view of a parser

Joakim Lier

Part 1/2: How to execute an object file

Ignat Korchagin

16:20 - 17:20 (UTC+02)

Parallel Algorithms: Work Smarter, Not Harder

Jana Machutová

When to give up, and how?

Björn Fahller

Extending MicroPython with Rust: Two Worlds Collide

Jan Matějek

C++20 Modules, 5 Years Later

Mikhail Svetkin

Swarmfare - When the shit hits a thousand fans

Jan Dyre Bjerknes

Part 2/2: How to execute an object file

Ignat Korchagin