DCONF 2023 Talks.md

This file is a summary of the Dconf 2023 talks that happened in London from 29th Aug 2023 to 31th Aug 2023.

I wasn't there in London, haven't been able to travel (late on product schedule) but spies in Dconf helped me report. So, some talks have double reports, by @Webfreak and @p0nce (me) as commenters.

Now, watching Youtube at home is not the same energy at all.

Not being there, it's easy to miss the excitement and backstory that happen in-between the talks, so be sure to actually watch the talks you are interested in since often much more is conveyed than just the few information reported here. Also, some talks I just barely watched. Feel free to reach out to edit the gist.

Note: Text in italics are my remote reactions, not what the speaker said.

Dconf Day 1

Talk "The Truth About D" by Saeed Sabeti

• Start by making people introduce to their neighbour each other with the most transformative story in their life. Room is warming up very quickly.
• Saeed is no programmer, so a bit unusual for Dconf.
• Saeed noted that D programmers often tell magical passionate stories about D.
• Ucora considers finding D as nothing short of a miracle.
• Ucora is building complex systems in D.
• Also a service company for well known clients.
• IVY stands for "Ideal Version of Yourself", means more or less a "goal".
• Surprising adequation of Saeed with its own IVY description, he is obviously a captivating storyteller. As a small-time marketer/business I really appreciate that.
• Organization have their own IVY.
• "You are cutting trees, but are you cutting the right trees?"
• Announces the DLF under IVY program.
• Main takeaway is that people should find/update their "IVY", and that IVY alignment creates meaningful collaboration (even if it's only temporary). Can solve the job problem of lack of alignment.
• Question: "But goals change!". But IVY is dynamic, Saeed is at 7th edition of own IVY.
• Question: "What level of details for an IVY?" Usually kind of broad. => You're not supposed to be "done", if so change the IVY I guess.
• IVY based upon the idea that people follow their own goals, in a selfish way.
  • so, key is to create win-win.

Talk "Types and Tuples in D" by Timon Gehr

p0nce's summary:

• Rundown of D type system, and what types do in general.
• For example: tracking effects, distinguish L-values from R-values, etc.
• Shows unintuitive parses for immutable, ref, and complicated rules I didn't know about.
• A perfect type system would have many desirable (lists them), but you cannot have it all and must choose.
• However, some type systems are simple AND expressive, people don't know about them.
• Shows a failure of Value Range Propagation.
• The reason for "attribute soup" in D is the pressure to add expressivity back into the type system.
• Very interesting moment where Timon defined what @system, @trusted and @safe really mean. That will become a classic Powerpoint slide. I do recommend this talk just for this.
• @trusted is trickier to use than we think.
• List D type system challenges.
• "const is so strong it's almost useless", coworker said.
• Displays more inout problems and more type system challenges.
• The name of AliasSeq was dropped multiple times on stage.
• Tuples is a big remaining work.
• Question: What to do for no-TLS transitively?
• Walter appreciate to see every mistake he made exposed!
• Timon says those issues have a dark core but some do not matter all that much. Looks clear to me it won't necessarily all be worth fixing.

Webfreak's summary

• Parsing weirdness with immutable and ref not meaning the same, especially with delegates.
• @trusted defines safe interface, but programmer needs to guarantee everything.
• so (() @trusted => ...)() is considered rather a hack, since the interface is implicit.
• Type system issues:
  • pure not too specified.
  • no inference for variable types (only on initializers).
  • need to choose between templates or virtual calls (not both, even if both are desirable).
  • opApply needs way too many overloads.
  • inout has weird semantics with member functions inside functions.
• if you have multiple returns in a parameter list, compiler will pick the lowest lifetime return.
• suggested effect and mutability annotations.
• partial implementation: https://github.com/tgehr/d-compiler
• talking about tuples.
• issues with no syntax right now.
• AliasSeq does not work with the type system and is not a good replacement.
• got a tuple DIP.

Talk "DMD as a Library: Between Myth and Reality" by Ravzan Nitu

Webfreak reporting:

• Problems in the past: changes didn't really get through, slow merging
• Compiler Architecture
  • Lexing -> Parsing -> Semantic Analysis -> Code Optimization -> Code Generation
  • DMD: Lexing & Parsing in one (like a range based interface)
  • DMD: Optimization is tighly coupled with Semantic Analysis
• Goals for library that weren't possible:
  • Separation between compilation phases
  • modifying AST nodes
  • modify compilation phases
  • ask for any kind of information (compiler discards a lot of information)
  • should be parallelizable (compiler used a lot of globals)
  • share code base between library and compiler
• Current non-concerns for the library:
  • incremental compilation
  • compile time of DMD itself
• Current Progress:
  • replaced Parser with templates for Parsers, where template argument takes a struct that does everything
  • struct include public import to get regular behavior, methods can be individually replaced to change what happens
  • extracted AST's custom semantic methods into visitors for bachelor thesis
  • people wondered during its progress what the benefit is (no resolve to this question?)
  • trying to actually use it in projects
    • DCD (not attempted very far, issues with scope not being exposed much)
    • D-Scanner (70% done, currently looking for student to work on it)
• Contribution Suggestions:
  • Finish D-Scanner integration of dmdlib
  • need scoping information exposed from compiler
  • need more information exposed / exposable in the library
  • be able to modify AST nodes (almost ready)
• Walter says this is tough task and like converting progressively a combustion engine car to an electric car.

Talk "Stack Memory is Awesome!" by Dennis Korpel

Webfreak's summary:

• Introduction to memory allocations
• Stack memory (adding / subtracting stack pointer)
• Heap memory (complex management, dynamic freeing)
• Dynamic data in stack, although limitations:
  • limited size (cache especially)
  • need static size (alloca not recommended)
  • limited lifetime
• How to best use in D:
  • DIP1000: (Stack Don't Crack 64)
    • scope - makes variables unable to escape { blocks }
    • general rules: distinction if types have pointers, operators are ignored for lifetime checking
    • return scope: inout of lifetime: scope in, scope out; non-scope in, non-scope out
    • ref: has implicit lifetime (global)
    • return ref: applies to ref parameters: local variable in, scope out; global variable in, global lifetime out
    • problem: scope is a variable storage class, not a type constructor
    • doesn't work well with classes, since this is not ref
    • classes
    • class constructors need to be marked scope
    • return scope == return ref + scope, everything else like scope return == ref + return scope
      • ERRATUM from @Dennis: Showing once again how confusing the syntax is: It's exactly the other way around. _return scope has priority in that order, everything else like scope return == return ref + scope
    • templates and auto functions infer lifetimes
    • implementation diverts from DIP text
    • return will apply to first ref parameter, if returning void
  • tempCString
• list of broken things in implementation and PRs for DIP1000 fixing them

p0nce's summary

• this talk = basically the history of DIP1000.
• Performance often memory-bound.
• Stack memory is 1mb default on Windows, 8mb default on Linux.
• Stack has a guard page to segfault the MMU.
• more stack variables doesn't add any time, just larger subtract to stack pointer
• Limitations of stack-memory:
  • Limited size
  • Must know size upfront, or at least an upper-bound (which is bad for cache)
  • Local lifetime only
• Talk explains DIP 1000.
• Show example of @safe stack-allocated string concatenation
• "return scope is the inout of lifetimes"
• scope, return scope, return ref are inferred, sometimes need to just use auto
• 146 open issues for DIP1000 (!), it has much evolved.
• Shouldn't be possible to slice a local array without scope control.
• DIP1000 hard to get, Walter jokes that DIP 1000 should be obvious to the casual observer.
• The long march towards DIP1000 enabled, bit of a rant tone about the extent of the Bugzilla and PR warzone.
• @live called a "bad deal for now" since it doesn't make more things @safe.
• Plee for true fixes instead of surface fixes.

Personal take-away: well I will continue to avoid DIP1000 for now, until made default I guess.

Talk "Simple @safe D" by Robert Schadek

Webfreak's recollection

• Manual memory safety is not the goal of D.
  • We have a GC for most things.
• Perspective on removing things instead of adding more:
  • No DIP1000, DIP1021, DIP1035 - disable pointers in @safe instead / make them @trusted.
  • No user defined @safe containers that behave like built-ins.
  • No manual memory management in @safe.
• Use ref / out instead of pointers.
• Use Nullable!T for optional value.
• Avoid assert + in / out / invariant contracts
  • since they are left out with -release.
• Need better template constraints for multiple different possible paths.
• For many overloads, bundle all things into a single implementation function.
  • Use static assert instead of template constraints there.
  • Also alias types in these static asserts for better readability.
• Can create a generic wrapper with T... that auto-assigns all the parameters to the matching types on the arguments struct
• Avoid nested functions with implicit context.
  • Put it outside, with all needed parameters, also unittestable.
• Avoid nested imports (put them globally).
  • May be slower when they were in templates though, since templates delay import resolving.
• "Please don't add tuple".

p0nce's recollection:

• Subtitle is "How to make enemies quickly" :)
• Starts directly in medias res, into the middle of a rant.
• What does return ref even means?
• Attacks DIP 1035 and DIP 1000 as useless.
• What if we remove stuff instead? a gracious lack of St Exupery quote for when perfection is achieved. Thanks for that!
• Proposes to use out, ref instead of scope pointers and scope ref.
• Quizz about address of @property should return? Robert says should be an error, do not choose.
• Reference to Scott Meyers immortal talk's "the last things D needs is a person like me". I was thinking about this just before Robert bring that up.
• Robert thinks we are going down the complexity road quickly.
• "You have to have a toilet, but you don't put it in your living room" when talking about scope and @safe.
• Why not disallow & in @safe?
• Atila says the talk has some good ideas, and to wait for his own talk...

Talk "Getting from C to D without Tripping" by Steven Schveighoffer

p0nce's notes:

• Steven teaches kids to program.
• Ported Raylib because kids are interested in graphics and games.
• Maintains raylib-d because original maintainer disappeared => still the best way to find a maintainer :)
• Very interesting effort here: https://github.com/schveiguy/draylib with superbly usable ports already.
• Automation is paramount to port large C to D, even when using c2d.
• Introduces a new tool, cpptool.

Personal takeaway: Directly impacting my work. If only because some of the files translated are interesting. I've converted huge amount of C code to D, and it's a limitation. Steven can convert much more than that way. He's a master C-to-D converter, the likes of which we haven't seen since Dennis and ketmar.

Webfreak's notes:

• DStep for automatic translation of C APIs.
• Use D features to improve binding usage and safety:
  • operator overloading for arithmetic things
  • wrap abstractions
  • add UFCS
  • use overloads
  • use strings
• Porting
  • copy C code into D, try to build
  • compile, fix, add more, repeat
  • use ctod to start off much quicker
  • use dstep to link remaining C code during translation
  • cpptool can automatically expand broken macros with gcc, clang and msvc + has some extra options
  • expand the API to include more D features

Talk "D Code Generation, OpenAPI, and Integrating Services with REST" by Vijay Nayar

Webfreak reporting:

• Auto generated D web APIs using OpenAPI
• Swagger for auto-generated web docs.
• Define APIs as big structured JSON document.
• Presentation shows how its built and some basic examples.
• Can be used to tie together programming languages in a big system.
• Can use mixin templates to avoid code duplication / boilerplate with OpenAPI metadata.
• Also auto generate getters/setters, auto-generate builder
• Use static foreach to do this repeatedly.
• Iterate over FieldNameTuple / Fields to auto-generate builders for types.
• D Project: openapi-client.
• Outputs code suitable for vibe.d by default.
• Future plans: add D support to openapi-generator, add OpenAPI annotations for vibe.d.

Dconf Day 2

"Creating Self-Evident Code with D" by Walter Bright

Webfreak's remarks:

• Avoid negation.
• Avoid casts.
• Linear control flow (left to right, top to bottom).
• Make I/O (e.g. files and environments) a task of the caller instead of the implementation.
• avoid mixing && and ||, especially with negation
  • !(a || b) rather than !a && !b.

p0nce's remarks:

• Bit of advice like Uncle Bob, such as:

    doA(); 
    doB();
    doC();

  being readable, and in my opinion Clean Code is an underrated classic.
• Point about the double-negation (and triple-negation) in English just emphasizing the negation instead of being a flip-flop. That always confuses me.
• D "attribut soup" does reduce the amount of comments needed, for all its faults.
• Line things up. I started doing more of that recently and it does make things easier!
• Walter trying to use more positive wording in general, not just in code.

"Hipreme Engine: Bringing D Everywhere" by Marcelo Mancini

Webfreak's remarks:

• Talks about Hipreme Engine.
• WebAssembly
  • prior work: underrun
  • prior work: emscripten-d
  • Dylan's LWDR
  • adr's webassembly runtime (contributed to and fixed issues)
  • avoid JS bridge for performance critical code (it's slow)
  • playable result: https://hipreme.itch.io/hipmatch3
• Compile time reflection for metadata such as shader uniform names.
• Metaprogramming to automatically generate bindings to Java side (JNI).
• Just regular interfaces are useful as well.
• Intel VTune Profiler can be used for profiling.
• OOP doesn't need to be slow in D.
• Created a project generator to start out with project .template as well as auto-installing dependencies.

p0nce's remarks:

• Project started with the difficult task of being for multiple platforms.
• Particularly difficult platforms: Xbox S and Android, and most of all WebAssembly.
• Using only D would be a problem and impractical, such as for Android.
• C "not really supposed to be used" on Windows in Marcelo's opinion.
• Not many people seems to be using WASM with D.
• WASM vs JS bridge is slow.
• Completely avoided the C stdlib in WASM target.
• WebASM need a list of files to access in advance, which complicates things.
• Lots of UDA uses.
• Praises interfaces and declarative design for portability
• Beginner uses really serviced well with the project helper. This is something that is often overlooked.
  • Must restrict compiler versions because can't test it all.
• I can empathize with the Linux rant.
• Overall massive amount of work.

Impressive stuff as expected. I'll note that I tested WASI a bit more recently and with some WASM runtimes, you can access files from D with WASI calls and hence libc ports will start to work. Either it's something to be implemented in a druntime, or to link with a WASM libc.

"A Semester at University: Teaching Software Engineering" by Mike Shah

Webfreak's notes:

• From the perspective of a C++ professor.
• Disproportional large time use in teaching C++ (debugging and reteaching C++).
• Students learning curve hard, especially clawing through syntax vs building software.
• Saw much potential in D, since it had a lot of ecosystem things from early on, even if rough around the edges.
• Various universities have been teaching D already.
• D has good potential to scale throughout the university curriculum, which makes this a great choice for universities.
  • Can teach it from basics all the way to systems programming and embedded and such.
• Good tool for teaching:
  • Can use @safe, makes interesting discussion in class on writing safe software.
  • Can use pointers still (when to use them and when to not use them).
  • etc..
• Choosing a tool is not a popularity contest
• Problems for Students:
  • Initial struggles finding specific documentation
  • Different platforms (Mac intel, Mac arm, Linux, Windows)
    • lldb vs gdb
  • Learning how to rely on documentation and the spec when tutorials don't exist (good skill to learn though)
• Creating more video resources
• Encourages D community to review code on camera / livestream, etc.
• Useful D things:
  • rdmd for quick prototyping
  • better error messages than C++
  • GC as well as manual memory management + trade-offs
  • low barrier of entry to interfacing with C libraries
  • networking with std.socket
• Students were excelling far beyond previous semesters
• "Worst student project using DLang was on par (or better) than the best project in the combined three iterations of <professors's course> in C++"
• Professor recommends D as teaching tool inside universities.

p0nce's notes:

• Interestingly, students did already love the replaced C++ course.
• C++ actively worsening teaching experience
  • Students stuck in syntax-hell Well I've seen the exact same thing with new programmers being taught Ocaml as first language. You could tell it was a syntax course instead of a programming course.
• Describe own students as "pragmatic", was worried to disservice them by teaching less popular language.
• Many talks over the years by professors hint at D being a good first programming language.
• No more than 1.5% of students heard of D before being taught.
• Students had to built a multiplayer Paint application.
• Huge productivity success for the course, with much exceeded expectations for projects.

Interestingly like in the past at DConf, when a professor speaks its students also get to speak as speakers. Here, likely the best students of this course though.

"A Semester at University: Teaching Software Engineering" but from the students perspective.

Webfreak's notes:

• Initial reactions:
  • First thoughts (what is D? where is it used?)
  • Hesitations (never heard about D before class, realizing it's a small community)
• Students favorites:
  • Dlang Tour (by far)
  • Being able to write unittests
  • Forums was good (but may contain outdated information)
  • Ali's Book for in-depth information
  • Video tutorials, especially for beginners
  • GC
  • Different paradigms (OOP, imperative, functional)
  • Interop with C
• Mixins seem to spark imagination / feel powerful to use in the future
• Excited from initial experiences
• Student projects
  • Networked paint program
  • Used SDL at the start
  • Used GtkD later
  • Ran into issue: unable to embed SDL window in GTK on Mac
    • caused them to redo the SDL part in GtkD
  • Like std.socket : SocketSet, for simple rapid development
  • Went with simple client-server architecture
  • CI/CD setup
    • auto-formatting
    • unittests
    • coverage
    • ddocs
    • artifacts for all platforms
    • dub package (3 sub-projects: client, server, common)
    • unittests with unit-threaded
    • problem with coverage not combining into one file
    • docs with harbored-mod
    • no cross-platform binaries, problems with GtkD
  • Conclusions
    • overall very enjoyable
    • nice syntax and more expressive than other languages
    • good error messages
  • Room for improvement:
    • documentation / tutorials
    • DUB:
      • pros:
        • easy package management
      • cons:
        • documentation
    • came in with Java-style module declarations (module my.mod.Classname;) which caused issues until halfway in the project
    • GtkD documentation not that great
    • Lack of tooling and packages on DUB
  • Good for software class: some tools not being as engineered as in other languages makes you learn the specifics more

p0nce's notes:

• As expected, the students do things that we professionals struggle to do, like setting up a proper CI or use code coverage :)
• The students especially enjoyed dub, rdmd, message-passing(!), the error messages and of course mighty Dlang itself.
• Often point of comparison is Python. Anything students do with D, the Python experience is a kind of benchmark.
• Students avoided @safe, local imports, templates, mixins... and DIP 1000 which looks correct in a time-constrained project, gotta spent that learning budget adequately. All features that don't completely help you deliver value quicky, if I may :).
• They wished for more examples and documentation:
  • With the precision that examples need to come with a "why" and not just code.
  • Got lot of use of the GTKd coding blog.
  • Want more Youtube videos.
  • Want more ecosystem things.

I'm a tiny bit sad they didn't mention d-idioms or the DIID articles, noone cares but me yet I made that as a time-constrained teaching resource.

Talk "If I Cannot Dissuade You from Using Atomics, at least Do It Safely" (Roy Margalit)

• This seems to be a presentation of the various memory models and fences of atomics. And, uh, I didn't really watched.

Personally not interested in ramping up my use of atomics, these days I'm only using full Sequential Consistency usually.

Talk "Taming the Snakes" (Ikey Doherty)

p0nce's notes:

• My laptop sound is a bit broken, so I hear only 30% of what is going on.
• Super fun presenter.
• Ikey is making a Linux distribution
  • Focusing on how the distribution is built
  • Nothing much new has happened apart from flatpack.
• Along the demo someone says it is like Nix. This is like "Nix done right"
• Uses YAML "to keep the devops employed" :)
• Builds a package on stage
  • this automatically "splits" package, not sure what this is
• This is how I think a jaded packager should look and talk.
• I don't get what's going on at all, sounds like packagey packager business.
• Impressive Linux setup. In particular I'm jealous of the coloured bars of Ikey tooling. What D library does that?
• Ikey regrets replacing exceptions with error types, that didn't work.
• "Rewrite it in Rust" conversation at work, D held.
• Was surprised that a D program can fork(). It does work.
• Lots of code on screen. More code than in all other talks
• Looks like massive amount of work for a worthy goal, one that I know nothing about.

Talk "The Multiplix Kernel: OS Development with D" (Zachary Yedidia)

• Multiplix is a small kernel for research purpose, ARMv8 and RISC-V supported.
• Some kernel structures easier to write vs Rust (such as linked lists).
• To make a kernel = use QEMU, and make your custom empty object.d and work from there.
• Use volatileStore to write to memory-mapped devices.
• Kernel is -betterC, no classes, no module constructors.
• This presenter understands GCC-style inline assembly(!)
• Casually introduce a build system called Knit
  • more like Make and can do incremental at the object file level, using D header.
  • less useful for heavy template and inlined code
• Code here: https://github.com/zyedidia/multiplix
• Multiplix will be a test-bed for Lightweight Fault Isolation.
• Question: "How does Knit deal with inlining? Could be in inconsistent state."
  • no answer given.

Personal takeaway: I'll note that each year has more RISC-V than the last, and that I should probably try that more.

Hipreme's commentary: For me the notable presentation was from Zachary, he really explained something so hard like bare metal and it made me feel like it was pretty easy.

Talk "The Neat language" (Mathis Beer)

• Neat is a language heavily inspired by D.
• Macros instead of CTFE.
• LLVM and C backend.
• immutable by default, non-nullable objects by default, named tuples.
• Less depth of features than D.
• Can demo ideas for D.
• D should copy:
  • lambdas in Neat are just expressions
  • native sumtypes
  • "packages" instead of includes (?)
• Showcase list comprehensions as a macro.
• DMD could copy being more "pure" in compilation, to leverage multicore.
• Neat's various SSA IR are immutable, the AST also => everything cachable and parallel.
• Showcases very fast rebuild with file watch and the compiler staying in memory, on a raylib program.
• Sumtypes are cool, you can always define a type that's implicitely convertible from other types.
• Type of return 5; is bottom, not int
• D doesn't have "packages". Emphasizes that D can't "really" (correctly) cache dub package builds because it's always dependent on the include graph. To have a .a file lying in a cache folder that's actually reusable between builds, you need "packages" like neat has, ie. conceptually isolated bundles of code at the language level
  • packages are first-class object in the language, with namespaced names. Resonates a bit with Atila's talk that comes after.
• Like C++, Neat lambdas are values.
• regret RC in Neat and it brings suffering regularly, but the reasons for RC remain valid, if very very annoying.
• Showcase quasiquoting in a macro to implement a foreach vs doing it in the compiler
  • easier to do AST lowering with macros.
• Showcase a bit more integrated DSL, a bit like Nim vs D string mixins
• Encourages people to go make compilers(!)
• Question: Performance of afore-mentionned parallel builds?
  • No big programs written yet, expect 2x speedup.
  • Doing a complete unittest build of the compiler and the stdlib is sped up 2x by threading.

Talk "You're writing D wrong" (Atila Neves)

• Talk says it will be opinionated
  • I think the topic is information-hiding and API design for large scale D programs.
• Those rules not-universal, just how he goes about.
• Refactoring is key:
  • Else the code is probably dead.
• "The API is paramount, the implementation is absolutely not"
  • I entirely agree with this.
• "Stop writing classes"
• private everywhere.
• Explicit API design vs adhoc.
• "Don't test private functions"
• "D packages are like OOP hierarchies"
• Too many imports stinks.
  • Use local imports.
• "Stop caring about endianness"
• You can often replace auto by const or scope
  • You don't care about the actual type, but its API.
• Proposed unittest to be @safe pure by default.
• "Don't write for loops".
• main should be mostly empty.
  • Put argument parsing in a run function instead.
• "Don't write complicated CI configurations"
• You can replace scope(exit) with RAII wrappers.
• Don't write getters and especially not setters.
• Use immutable instead of shared if you can.

Talk "Internationalization with gettext" (Bastiaan Veelo)

• Presentation of gettext library, which is 33 years old.
• And how to use a similar thing in D with the gettext DUB package:
  • minimally invasive
  • functionally on par with GNU gettext
  • low barrier for entry
  • translator friendly

Talk "The QUIC protocol in D" (Vlăduț Chicoș)

• Vlăduț implements QUIC for D.
• QUIC is replacement by TCP.
• QUIC used by about 7.4% of websites right now.
• Stream multiplexing, prioritization.
• Implemented in userspace on top of UDP:
  • Simpler to update.
  • Everything is encrypted.
  • Guarantees order data.
• This implementation is I/O free, provided by user:
  • Deals with connections, datagrams.
• Question: can I use it right now?
  • Not finished yet.

LIGHTNING TALKS

1st mini-talk

• Created a large group of D programmers in Brazil.
• Teacher, uses graphics programming for students.

2nd mini-talk "Fibercursion"

• Seems to reimplement recursion but with Fiber
• https://github.com/bostikforever/FibeRcursion
• I haven't understood much to be honest.

3rd mini-talk "LDCLint"

• LDC plugin for "post-semantic analysis".
• Empty declarations, unused variables, redundant assignment.
• This is an WIP linter.

4rd mini-talk "Untitled" with Robert Schadek

• Isn't aware he registered for a lightning talk.
• Actual benefit of immutable is not that great.
• Using Nullable!T is also quite odd.
• Puts comma in front of lines. We are all wrong to do otherwise!
• "tabs are still better than spaces".
• Question: "How do you get so wrong?" :)
• Sounds is quite low I don't hear much. Actually my JACK is 95% broken so it's really hard to take useful Dconf notes out of home. Sorry for this, watch the real talks!

5th mini-talk "Data Exchange with ATD" by Gregoire

• Works for Ahrefs, which sells data it crawled on web.
• an Ocaml shop, ReasonML frontend.
• Use ATD language, a data type definition protocol.
• To build the Yep search engine, they move one component from C++ to D
• They translate type definition from OpenAPI ATD spec to D, that will be opensourced eventually
• Question: "Which one is better, D or Ocaml?" => they disagree on this, depending on who works with what.

6th mini-talk: Stand-up by Chris

• Series of programming jokes and aphorisms. Volume low here and broken so I don't hear so much. Probably very fun.
• "If I join the infrastructure channel, the frontend channel, and the database channel, does that make me a full Slack developer?"
• Probably plenty of good ones.

7th mini-talk "Building DMD" by Dennis Korpel

• Is DMD still easy to build?
  • It used to require Digital Mars's make.
• Now DMD built with a build.d script.
• Why not dmd -i instead? Let's try.
  • Managed to reduce to a 3 liner script.
  • Not building at same speed exactly but close.
• Shouldn't be hard to add dub build now!
• Question: "Why so much drama around DUB?"
  • Dennis see some issues in DUB.

8th mini-talk by Atila Neves

• Seems to be about a build system and DUB.
• Not hearing much at all, sorry.
• Projector is glitching fancy graphics before next talk.

9th mini-talk by Lucas and Philip

• They make distributed database / filesystem.
• Their questions answered in 4 min in Discord, by the library maintainers, pretty cool to have that in D.
• "Discord = great place to get help", says Steven.

Talk "A beginner's journey with AI in D" (Murilo Miranda)

• AI is mostly statistics, sometimes a bunch of if statements.
• Fell in love with D, using mighty arsd libraries.
• First experiments: A* algorithm, OCR program
  • Made own training set for OCR.
• Made a framework where you draw the network with mouse and and press ENTER to generate source code for it.
• Made a color classifier (!?)
• Train network on CPU on garbage computer all day because budget computers.
• "Try to learn the intuitive part before learning the math behind it"
• Shows an unexpected rdmd/dmd -i user interface with sound
• Shows an interface to indeed create a neural network and export to D.

Really cool talk, should re-watch this at normal speed.

Talk "A beginner's journey with AI in D" (Max Haughton)

• Talk is about what can we get from LLM.
• LLM = most interesting for non-programmers (even transformative), and for students cheating in homework = Number 1 usecase.
• GPT4 is best model, need feedback to write D code => But this feedback can be the error messages of the D compiler.
• Trying to use it to translate C macros and C code:
  • Somewhat successful, feedback needed.
  • Could hook it by making dpp and dstep more interactive?
• lama.cpp much easier to use from D, it is regular C library instead of (captive) web API

Panel "Ask us anything!" with Walter Bright, Átila Neves, Mathias Lang, Dennis Korpel, Saeed Sabeti, Mike Parker

• Question: "What arena should D focus on?"

  Walter Bright: Pretty clear direction: cleaning up must not be done at the cost of breaking people's code. We want to be like C. We're gonna stop forcing people to upgrade their code. Focus on fixing bugs.

• Question: "When will ImportC be ready?"

  Walter Bright: Kinda blocked by weird extensions, like GCC allowing statements inside expressions. C extensions gonna be a constant problem, but the coverage we support will be improving.

• Mike: We've been coached by Saeed on IVY, you can ask any question to him.

• Walter Bright: We've been focused on the IVY, hence why we chose more stability for now.

• Question about .di, Walter and Rikki disagree on right approach for shared libraries that "just work".

• Question: "Will D be @safe by default?"

  Walter: Would break everything. Maybe editions.

  Word "editions" said several times in answers in this panel, not sure it will happen though.

• Question: "Will slices be proposed in C standard?"

  Walter: Never raised an "official" C proposal; but was said the committee was considering a proposal.

• Question: "Will D grow bloated if we don't ever remove features?"

  Walter: C took 30 years before deprecating features. We don't want someone that uses a library on DUB to fail to compile. We just want to stop that.

  Atila: Obviously is a tradeoff, with complexity in the compiler vs supporting legacy.

• Question: "What do you think is the main thing that blocks the ecosystem?"

  Matthias: Needs more ecosystem size, and also Phobos lacks a few basic tools: deserialization, XML... Need to add things in Phobos.

  Atila and Walter: More blogs, more articles. Mention D, but without being obnoxious. Like, interesting things that just happen to be in D.

• Question: "How much DMD needs to be refactored to be able to be packagized?"

  Walter: is cutting down the number of imports. In DMD every module imports every other modules, getting there.

• Question: "Will you share your IVY statements?"

  Mike: Yes for the DLF. DLF has an IVY, but each person also has its IVY statement too. We're going to use that to prioritize along with different IVY. It's a tool to evaluate what the priorities are.

  Walter: I was surprised by the diversity of motivations. I didn't know why people worked on D. Could help assign tasks.

  Mike: we're learning to ask people what there interests are, and how they are aligned. Should make us more able to deal with contributors.

  Saeed: We took a long time to find the IVY. What is the D language about when you dig deep? There is some sort of mindset or principle that is behind it. The core value that pushed Walter to create this language. That's why it took long sessions to find. D as a language is just a tool to move to a grand vision, what is that vision?

  Walter: Admits fundamental failure of not asking "what do you want to work on?" precedently.

  Saeed: All of us go in life from point A to B, because something motivates us. Knowing what that is gives a foundation of understanding what other persons are motivated to do. Certain people doing certain tasks is going to move closer to where they want to be in life.

• Question: "Any excess bureaucracy you've found?"

  Saeed: I haven't been involved in that level of detail, I'm in a low resolution involvement.

  Atila: Well, helped me realize what I didn't want to do.

• Question: "What will we do to achieve more of our goals?"

  Atila: Take care about what could go wrong, think about what we can do or can't do.

  Dennis: We've already been doing editions somewhat with -preview, but unsuccessful making users adopt the switches, hidden in command-line.

  With editions, you just annotate the module and can work with other editions in theory.

• Question: "What happened to std.v2?"

  Atila: Need more work first. std v1 doesn't even exist yet and there will be no v2 until then.

• Question: "What will the new non-breaking policy harm?"

  Walter: @safe by default, can't make that change without breaking things.

• Question: "What to remove then?"

  Walter: I want to remove complex numbers support. Anyone using it? Asks the room. No reaction. It's probably dead already.

  Me thinking: it's been more than a year we complately replaced complex numbers at least for D audio people that I know, and very happy with it! Please burn the last remnants!

  Walter: I think IVY has potential to make us more successful as a language.

  Mike & Walter: and it has improved our relationships. D Core team aligned on this and IVY.

• Question: "Are we ready to discard DIP freeze?"

  Mike: end of the year probably.

  Walter: There will always be bugs, something wrong etc. Right now we can't entertain adding stuff to language rather than fixing stuff.

• Question: "Do we all have to be in the IVY thingy?"

  Saeed: No. IVY stands for "Ideal Version of Yourself". But as people we've multiple layers, and we're multiple people at the same time, so you will have an IVY by "aspect" eventually. Why not a family IVY statement? The idea is to help you take decisions.

  Without such a direction, the issue is that you may well reach goals one by one, and goals need to move in a direction. Else that's never fulfilling.

  Mike: The D community at large doesn't have to care.

• Walter: I don't see -betterC as balkanizing the language, it's a subset. Want code to be usable for both? Do it in the BetterC subset.

• Amaury: Additions can also make breakage, such if you sprinkle @nogc you cannot pass callbacks anymore etc. All these changes are positives, but can also break code. Can't accumulate tools if they break too much.

  Walter: Well, need to upgrade the tools? Can't really see any way out.

  Amaury: C++ does bundles of breaking changes, that's better.

  Mathias: With editions, we'd like to do that.

• Question: "Where do you want to see the project evolve in 5 years?"

  Mike: we're gonna talk about that more.

  Robert: it should be difficult to take a ticket to Dconf, because of a packed room.

  Walter: World domination!

  Ethan: New speakers in all slots at DConf.

  Walter: I'd like D to be a money-making machine, a secret weapon for organizations that use it.

  Mike: I'd like to see more Youtube activity.

Takeaway: I admit this year was the first year I was invited to a Dlang Core Meeting, after 8 years of full-time D business. Was really nice to see the interest and wondered what caused so? Also felt positive about D more than usual after seeing Dconf talks, seeing how contributors wants and needs are going to be more catered to, and the Core team in agreement.

return scope == return ref + scope, everything else like scope return == ref + return scope

Showing once again how confusing the syntax is: It's exactly the other way around:

return scope has priority in that order, everything else like scope return == return ref + scope

Okay, fixed.