home.social

#dlang — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #dlang, aggregated by home.social.

fetched live
  1. I made a thingy! It's just a silly little hex dump utility function in #dlang. It can take ubyte[]s and also structs, and outputs to a File (stdout by default). By default it looks just like xxd, but it's really flexible thanks to the optional options struct and can be made to look exactly like od and hexdump (maybe).

    It's available at https://archive.md/FGHMu and https://web.archive.org/web/20260813121955/https://termbin.com/pz7kz

    Sorry, I don't have a long-format blog yet...

    I bet there's probably something like it in the standard library or on DUB, and I'm aware that something similar can be made with a single for loop and ~4 SLOC but oh well... I still made it x3

    If you don't happen to like my coding style: just imagine that I'm actually programming in a language called "xD" and I'm following all of the proper style conventions.

    #Dlanguage #dlang #programming #art

  2. I made a thingy! It's just a silly little hex dump utility function in #dlang. It can take ubyte[]s and also structs, and outputs to a File (stdout by default). By default it looks just like xxd, but it's really flexible thanks to the optional options struct and can be made to look exactly like od and hexdump (maybe).

    It's available at https://archive.md/FGHMu and https://web.archive.org/web/20260813121955/https://termbin.com/pz7kz

    Sorry, I don't have a long-format blog yet...

    I bet there's probably something like it in the standard library or on DUB, and I'm aware that something similar can be made with a single for loop and ~4 SLOC but oh well... I still made it x3

    If you don't happen to like my coding style: just imagine that I'm actually programming in a language called "xD" and I'm following all of the proper style conventions.

    #Dlanguage #dlang #programming #art

  3. surprised Walter Bright didn't get a mention, seems to me he had something to do with how early c++ "just spread" #dlang

  4. surprised Walter Bright didn't get a mention, seems to me he had something to do with how early c++ "just spread" #dlang

  5. surprised Walter Bright didn't get a mention, seems to me he had something to do with how early c++ "just spread" #dlang

  6. surprised Walter Bright didn't get a mention, seems to me he had something to do with how early c++ "just spread" #dlang

  7. surprised Walter Bright didn't get a mention, seems to me he had something to do with how early c++ "just spread" #dlang

  8. During the pandemic lockdowns, I did the first "Ray Tracing in One Weekend" book in D (#dlang).

    raytracing.github.io/

    I thought it'd be fun to continue with the second book. I now wasted so many hours trying to get this working again (both on macOS and a Linux container) that it's probably quicker to rewrite it in another language and forget about D. Shame.

  9. During the pandemic lockdowns, I did the first "Ray Tracing in One Weekend" book in D (#dlang).

    raytracing.github.io/

    I thought it'd be fun to continue with the second book. I now wasted so many hours trying to get this working again (both on macOS and a Linux container) that it's probably quicker to rewrite it in another language and forget about D. Shame.

  10. During the pandemic lockdowns, I did the first "Ray Tracing in One Weekend" book in D (#dlang).

    raytracing.github.io/

    I thought it'd be fun to continue with the second book. I now wasted so many hours trying to get this working again (both on macOS and a Linux container) that it's probably quicker to rewrite it in another language and forget about D. Shame.

  11. During the pandemic lockdowns, I did the first "Ray Tracing in One Weekend" book in D (#dlang).

    raytracing.github.io/

    I thought it'd be fun to continue with the second book. I now wasted so many hours trying to get this working again (both on macOS and a Linux container) that it's probably quicker to rewrite it in another language and forget about D. Shame.

  12. During the pandemic lockdowns, I did the first "Ray Tracing in One Weekend" book in D (#dlang).

    raytracing.github.io/

    I thought it'd be fun to continue with the second book. I now wasted so many hours trying to get this working again (both on macOS and a Linux container) that it's probably quicker to rewrite it in another language and forget about D. Shame.

  13. @soulsource it’s worse than that. Non-destructive moves, while definitely an improvement on the semantic horror of auto_ptr, force us to have objects with an “empty” state, repeating the billion dollar mistake again and again… Rust is so much better in that respect that it isn’t funny

    Self-referential legacy objects could probably even have been made movable by introducing something akin to D’s post-blit operator (but for moves)

    #cplusplus #rust #dlang

  14. @soulsource it’s worse than that. Non-destructive moves, while definitely an improvement on the semantic horror of auto_ptr, force us to have objects with an “empty” state, repeating the billion dollar mistake again and again… Rust is so much better in that respect that it isn’t funny

    Self-referential legacy objects could probably even have been made movable by introducing something akin to D’s post-blit operator (but for moves)

    #cplusplus #rust #dlang

  15. @soulsource it’s worse than that. Non-destructive moves, while definitely an improvement on the semantic horror of auto_ptr, force us to have objects with an “empty” state, repeating the billion dollar mistake again and again… Rust is so much better in that respect that it isn’t funny

    Self-referential legacy objects could probably even have been made movable by introducing something akin to D’s post-blit operator (but for moves)

    #cplusplus #rust #dlang

  16. @soulsource it’s worse than that. Non-destructive moves, while definitely an improvement on the semantic horror of auto_ptr, force us to have objects with an “empty” state, repeating the billion dollar mistake again and again… Rust is so much better in that respect that it isn’t funny

    Self-referential legacy objects could probably even have been made movable by introducing something akin to D’s post-blit operator (but for moves)

    #cplusplus #rust #dlang

  17. @soulsource it’s worse than that. Non-destructive moves, while definitely an improvement on the semantic horror of auto_ptr, force us to have objects with an “empty” state, repeating the billion dollar mistake again and again… Rust is so much better in that respect that it isn’t funny

    Self-referential legacy objects could probably even have been made movable by introducing something akin to D’s post-blit operator (but for moves)

    #cplusplus #rust #dlang

  18. Juan Vazquez and Cameron Cunning rejoin the show to discuss how we fared with the 2025 Advent of Code competition.

    straypointers.com/e/s4e01.htm

  19. So thinking about asyncronous programming again and how I probably need to ditch #dlang's GC if I want performance and then it hit me:

    Why tf is std.socket.Socket an heap-allocated, gc'd class to begin with?!?!

    It dosn't uses syncronized that would require a classes monitor, nor does it hold any significant amount of data.

    • a socket_t (fancy 32-bit fd)
    • a ushort-enum for the address family (16-bit)
    • and an bool under windows, which in an asyncronous context we could remove since all will always be non-blocking

    So in sum it holds 48-bit of data, while an pointer on modern systems will always be 64-bit (classes are always pointers / by ref in dlang).

    Sure, it "uses" inheritance for 2 wrapper types TCPSocket and UDPSocket, which dont actually do anything other than pre-filling the type/protocol arguments in the constructor, which dont even survive after the call to socket(2)...

    Is the std really that badly engineered at times or am I going crazy???

    #dlang #programming #development #async #networking #garbagecollector

  20. So thinking about asyncronous programming again and how I probably need to ditch #dlang's GC if I want performance and then it hit me:

    Why tf is std.socket.Socket an heap-allocated, gc'd class to begin with?!?!

    It dosn't uses syncronized that would require a classes monitor, nor does it hold any significant amount of data.

    • a socket_t (fancy 32-bit fd)
    • a ushort-enum for the address family (16-bit)
    • and an bool under windows, which in an asyncronous context we could remove since all will always be non-blocking

    So in sum it holds 48-bit of data, while an pointer on modern systems will always be 64-bit (classes are always pointers / by ref in dlang).

    Sure, it "uses" inheritance for 2 wrapper types TCPSocket and UDPSocket, which dont actually do anything other than pre-filling the type/protocol arguments in the constructor, which dont even survive after the call to socket(2)...

    Is the std really that badly engineered at times or am I going crazy???

    #dlang #programming #development #async #networking #garbagecollector

  21. So thinking about asyncronous programming again and how I probably need to ditch #dlang's GC if I want performance and then it hit me:

    Why tf is std.socket.Socket an heap-allocated, gc'd class to begin with?!?!

    It dosn't uses syncronized that would require a classes monitor, nor does it hold any significant amount of data.

    • a socket_t (fancy 32-bit fd)
    • a ushort-enum for the address family (16-bit)
    • and an bool under windows, which in an asyncronous context we could remove since all will always be non-blocking

    So in sum it holds 48-bit of data, while an pointer on modern systems will always be 64-bit (classes are always pointers / by ref in dlang).

    Sure, it "uses" inheritance for 2 wrapper types TCPSocket and UDPSocket, which dont actually do anything other than pre-filling the type/protocol arguments in the constructor, which dont even survive after the call to socket(2)...

    Is the std really that badly engineered at times or am I going crazy???

    #dlang #programming #development #async #networking #garbagecollector

  22. So thinking about asyncronous programming again and how I probably need to ditch #dlang's GC if I want performance and then it hit me:

    Why tf is std.socket.Socket an heap-allocated, gc'd class to begin with?!?!

    It dosn't uses syncronized that would require a classes monitor, nor does it hold any significant amount of data.

    • a socket_t (fancy 32-bit fd)
    • a ushort-enum for the address family (16-bit)
    • and an bool under windows, which in an asyncronous context we could remove since all will always be non-blocking

    So in sum it holds 48-bit of data, while an pointer on modern systems will always be 64-bit (classes are always pointers / by ref in dlang).

    Sure, it "uses" inheritance for 2 wrapper types TCPSocket and UDPSocket, which dont actually do anything other than pre-filling the type/protocol arguments in the constructor, which dont even survive after the call to socket(2)...

    Is the std really that badly engineered at times or am I going crazy???

    #dlang #programming #development #async #networking #garbagecollector

  23. So thinking about asyncronous programming again and how I probably need to ditch #dlang's GC if I want performance and then it hit me:

    Why tf is std.socket.Socket an heap-allocated, gc'd class to begin with?!?!

    It dosn't uses syncronized that would require a classes monitor, nor does it hold any significant amount of data.

    • a socket_t (fancy 32-bit fd)
    • a ushort-enum for the address family (16-bit)
    • and an bool under windows, which in an asyncronous context we could remove since all will always be non-blocking

    So in sum it holds 48-bit of data, while an pointer on modern systems will always be 64-bit (classes are always pointers / by ref in dlang).

    Sure, it "uses" inheritance for 2 wrapper types TCPSocket and UDPSocket, which dont actually do anything other than pre-filling the type/protocol arguments in the constructor, which dont even survive after the call to socket(2)...

    Is the std really that badly engineered at times or am I going crazy???

    #dlang #programming #development #async #networking #garbagecollector

  24. Currently working (again) on my async framework in #dlang

    I need to say coming back to #dlang after a extensive while of #rust coding, I do miss a lot of features of rust already (tho it's nice for once not fighting against the borrow checker or some strange tokio bugs), like choice-types, pattern matching and traits.

    Tho it's nice to just have an decent gc and not the need of wrapping everything in `Arc<RefCell<Box<T>>>` /s

    Got plenty of ideas for my async framework after working with tokio (and reading parts of it and mio).

    #coding #programming #development #async #eventdriven

  25. Currently working (again) on my async framework in #dlang

    I need to say coming back to #dlang after a extensive while of #rust coding, I do miss a lot of features of rust already (tho it's nice for once not fighting against the borrow checker or some strange tokio bugs), like choice-types, pattern matching and traits.

    Tho it's nice to just have an decent gc and not the need of wrapping everything in `Arc<RefCell<Box<T>>>` /s

    Got plenty of ideas for my async framework after working with tokio (and reading parts of it and mio).

    #coding #programming #development #async #eventdriven

  26. Currently working (again) on my async framework in #dlang

    I need to say coming back to #dlang after a extensive while of #rust coding, I do miss a lot of features of rust already (tho it's nice for once not fighting against the borrow checker or some strange tokio bugs), like choice-types, pattern matching and traits.

    Tho it's nice to just have an decent gc and not the need of wrapping everything in `Arc<RefCell<Box<T>>>` /s

    Got plenty of ideas for my async framework after working with tokio (and reading parts of it and mio).

    #coding #programming #development #async #eventdriven

  27. Currently working (again) on my async framework in #dlang

    I need to say coming back to #dlang after a extensive while of #rust coding, I do miss a lot of features of rust already (tho it's nice for once not fighting against the borrow checker or some strange tokio bugs), like choice-types, pattern matching and traits.

    Tho it's nice to just have an decent gc and not the need of wrapping everything in `Arc<RefCell<Box<T>>>` /s

    Got plenty of ideas for my async framework after working with tokio (and reading parts of it and mio).

    #coding #programming #development #async #eventdriven