Two tracks this year (a first).

As usual, videos are prerecorded and released as YouTube Premiere.

Track 1: https://youtube.com/playlist?list=PLHI4D93Ts8_k&si=06qsQgYUd...

Track 2: https://youtube.com/playlist?list=PLHUPmLYoCMoY&si=iMwL7UeIO...

personal highlight I looked forward to:

- Araq's update on Nimony and Nim 3 (and NIF, which is so cool)

- Constantin's love letter to Nim (long overdue and I expect to connect strongly with this one)

- Treeform talking about Nim and AI (always very clean and inspiring presentations)

- Capocasa's testimony about building a (economic) coding agent in Nim

- Gianmarco talking about Nim for embedded

- Peter telling the story on how he introduces Nim to his company's new hires

I am pretty sure the general quality will be good and there will be hidden pearls (last year pearl for me was the one about putting Nim on e-ink screens all over the house)

(you won't find name of authors in the conf page but you will find them in the youtube playlists)

Did Nim 3 go all-in on compile time memory management?

AFAIK main focus of Nim 3 is about incremental compilation and enabling better developer tooling bringing in innovations experimented in Nimony (key is NIF intermediate format).

The new compile time memory mgmt was the focus of Nim 2 (it is possible there are still improvements)

For those new to the topic and less patient than "full conference" levels of attention, it doesn't cover things like UFCS/command-call, user-defined operators, or many other details, but for its incredibly short run-time, this video might give you a tiny taste of the flavor: https://www.youtube.com/watch?v=WHyOHQ_GkNo

FYI, there appear to be several typos where occurrences of "h" seem to have been replaced with "d", such as in "tde".

It took me way too long to realize that "Nim for tde" wasn't referring to some obscure system...

It's nice seeing Nim has some activity.

A lot of it depends on what kind of company / industry you work in. For example, in Rust space there's big divide between LLM-heavy users and light/no-LLM users. Main rust repositories: the language, standard library, formatter, linter, LSP - all forbid LLM-generated code, and lots of third-party libraries, especially low-level and security related, follow suit. However, application code written in Rust is often LLM generated. So, if you work with Rust and you contribute to core Rust projects you have to write a large portion of the code yourself.

But when I talk to my friends who work with TypeScript it seems like they all moved to LLM-generated coding full-time.

Last I saw, the LLM policy for the Rust project was under discussion, and it did not ban all LLM related code.

Some of us are still writing code.

The Nim compiler is now also slopcoded.

My coworkers never cared about this even before the age of slop.

Coding agents do not affect me at all, meaning, I don't care about them. I think this is also the case for some other developers.

Having said that, though, this assumes that xyz is great - or was great already - before coding agents. The team around Nim is great, and nim is not inelegant, but you kind of need to want to like types, and I found that to be the biggest obstacle for entry (also for crystal, by the way; the "just ruby, but with types" is IMO an incorrect description - just simulating syntax does not mean you are having the same language. This is even more so not the case with elixir. Some people think ruby is solely or primarily ruby because of the syntax. This is wrong; it is the philosophy that is the main difference between e. g. ruby and crystal or ruby and elixir, not the syntax; syntax comes after the philosophy and the philosophy is very different, though admittedly in crystal it is closer to ruby's philosophy than elixir's philosophy is to ruby's philosophy). I kind of like having to not want to care about types at all. This is also why I think those who want to slap on types on ruby and python are wrong. They use their own biased mindset to project from this point on, how languages without types are useless. And you can not convince them otherwise - they have set up their brain to function only that way already, which is interesting (and explains why they are so desperately trying to add types to e. g. ruby and python, as an example).

This may seem like a modern conflict, but what I like about your post is its more general human cognitive orientation. Since to each new generation everything is new, people tend to forget that this kind of tension goes back to the dawn of programming with Fortran and Lisp, or even earlier if you count various notations for math.

FWIW, CPUs/hardware structurally do not have quite as much luxury for dynamism/monotyped things. So, all this does connect with how tight/abstract a bridge to the hardware world one cares about (which just varies). That naturally connects to performance, but that also becomes tricky once one moves to pragmatic problem decomposition over purity (e.g. NOT "pure" Python or "pure" Ruby). In my experience, people tend to overvalue purity as much as they tend to over-simplify. :-)