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.
- 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.
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
andref
not meaning the same, especially withdelegate
s. @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.
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.
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 outref
: has implicit lifetime (global)return ref
: applies toref
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 likescope 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 likescope return == return ref + scope
- ERRATUM from @Dennis: Showing once again how confusing the syntax is: It's exactly the other way around.
_
- templates and
auto
functions infer lifetimes - implementation diverts from DIP text
- return will apply to first
ref
parameter, if returningvoid
tempCString
- DIP1000: (Stack Don't Crack 64)
- 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 theinout
of lifetimes" scope
,return scope
,return ref
are inferred, sometimes need to just useauto
- 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.
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
.
- No DIP1000, DIP1021, DIP1035 - disable pointers in
- 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
.
- since they are left out with
- 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.
- Use
- 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 ofscope
pointers andscope 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...
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
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 forvibe.d
.
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:
being readable, and in my opinion Clean Code is an underrated classic.
doA(); doB(); doC();
- 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.
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.
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..
- Can use
- 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
vsgdb
- 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.
- 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.
- 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
- pros:
- 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
- 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.
- 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.
- 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.
- 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.
- 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, notint
- 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 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
byconst
orscope
- 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.
- Put argument parsing in a
- "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 ofshared
if you can.
- 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
- 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.
- Created a large group of D programmers in Brazil.
- Teacher, uses graphics programming for students.
- Seems to reimplement recursion but with Fiber
- https://github.com/bostikforever/FibeRcursion
- I haven't understood much to be honest.
- LDC plugin for "post-semantic analysis".
- Empty declarations, unused variables, redundant assignment.
- This is an WIP linter.
- 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!
- 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.
- 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.
- 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.
- Seems to be about a build system and DUB.
- Not hearing much at all, sorry.
- Projector is glitching fancy graphics before next talk.
- 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.
- 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 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.
Okay, fixed.