#dlang — Public Fediverse posts

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

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

New #blog post arrives!

I discovered that, unlike what the documentation says, you in fact do not need GDC to bootstrap GDC.

https://briancallahan.net/blog/20260713.html

#Unix #compiler #compilers #gcc #llvm #clang #gdc #d #dlang #linux #bsd #freebsd #openbsd #netbsd #dragonflybsd #illumos #dmd

New #blog post arrives!

I discovered that, unlike what the documentation says, you in fact do not need GDC to bootstrap GDC.

https://briancallahan.net/blog/20260713.html

#Unix #compiler #compilers #gcc #llvm #clang #gdc #d #dlang #linux #bsd #freebsd #openbsd #netbsd #dragonflybsd #illumos #dmd

New #blog post arrives!

I discovered that, unlike what the documentation says, you in fact do not need GDC to bootstrap GDC.

https://briancallahan.net/blog/20260713.html

#Unix #compiler #compilers #gcc #llvm #clang #gdc #d #dlang #linux #bsd #freebsd #openbsd #netbsd #dragonflybsd #illumos #dmd

New #blog post arrives!

I discovered that, unlike what the documentation says, you in fact do not need GDC to bootstrap GDC.

https://briancallahan.net/blog/20260713.html

#Unix #compiler #compilers #gcc #llvm #clang #gdc #d #dlang #linux #bsd #freebsd #openbsd #netbsd #dragonflybsd #illumos #dmd

New #blog post arrives!

I discovered that, unlike what the documentation says, you in fact do not need GDC to bootstrap GDC.

https://briancallahan.net/blog/20260713.html

#Unix #compiler #compilers #gcc #llvm #clang #gdc #d #dlang #linux #bsd #freebsd #openbsd #netbsd #dragonflybsd #illumos #dmd

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

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

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

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

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

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

https://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.

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

https://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.

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

https://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.

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

https://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.

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

https://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.

Simulation instabilities can be beautiful

#recreationalprogramming #dlang #raylib

Simulation instabilities can be beautiful

#recreationalprogramming #dlang #raylib

Simulation instabilities can be beautiful

#recreationalprogramming #dlang #raylib

Simulation instabilities can be beautiful

#recreationalprogramming #dlang #raylib

Simulation instabilities can be beautiful

#recreationalprogramming #dlang #raylib

hell yeah, writing docs

#programming #dlang

hell yeah, writing docs

#programming #dlang

hell yeah, writing docs

#programming #dlang

hell yeah, writing docs

#programming #dlang

hell yeah, writing docs

#programming #dlang

@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

@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

@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

@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

@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

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

#rust #elixirlang #dlang #Aoc2025 #AdventOfCode #programming

https://straypointers.com/e/s4e01.htm

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

#rust #elixirlang #dlang #Aoc2025 #AdventOfCode #programming

https://straypointers.com/e/s4e01.htm

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

#rust #elixirlang #dlang #Aoc2025 #AdventOfCode #programming

https://straypointers.com/e/s4e01.htm

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

#rust #elixirlang #dlang #Aoc2025 #AdventOfCode #programming

https://straypointers.com/e/s4e01.htm

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

#rust #elixirlang #dlang #Aoc2025 #AdventOfCode #programming

https://straypointers.com/e/s4e01.htm

D言語の更新まとめ 2026年1月版（dmd 2.112.0）
https://qiita.com/lempiji/items/7ba90329faad243335ee?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items

#qiita #dlang #まとめ #コンパイラ #dmd

D言語の更新まとめ 2026年1月版（dmd 2.112.0）
https://qiita.com/lempiji/items/7ba90329faad243335ee?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items

#qiita #dlang #まとめ #コンパイラ #dmd

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

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

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

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

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

1.26次元の図形?! ~フラクタル図形の次元を計算してみる~
https://qiita.com/zushi_ryota/items/d198dc7282183eefc1b3?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items

#qiita #dlang #フラクタル図形

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

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

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

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

Advent of Code solutions in D for days 1 through 5

#dlang #coding #programming #AdventOfCode #AdventOfCode2025

https://github.com/jimlawless/aoc2025

Advent of Code solutions in D for days 1 through 5

#dlang #coding #programming #AdventOfCode #AdventOfCode2025

https://github.com/jimlawless/aoc2025

Advent of Code solutions in D for days 1 through 5

#dlang #coding #programming #AdventOfCode #AdventOfCode2025

https://github.com/jimlawless/aoc2025

Advent of Code solutions in D for days 1 through 5

#dlang #coding #programming #AdventOfCode #AdventOfCode2025

https://github.com/jimlawless/aoc2025

Advent of Code solutions in D for days 1 through 5

#dlang #coding #programming #AdventOfCode #AdventOfCode2025

https://github.com/jimlawless/aoc2025

Advent of Code 2025 - Day 1 solutions in D :

https://github.com/jimlawless/aoc2025/tree/main/day_01

#AdventOfCode #AdventOfCode2025 #coding #programming #dlang

Advent of Code 2025 - Day 1 solutions in D :

https://github.com/jimlawless/aoc2025/tree/main/day_01

#AdventOfCode #AdventOfCode2025 #coding #programming #dlang

Advent of Code 2025 - Day 1 solutions in D :

https://github.com/jimlawless/aoc2025/tree/main/day_01

#AdventOfCode #AdventOfCode2025 #coding #programming #dlang

Advent of Code 2025 - Day 1 solutions in D :

https://github.com/jimlawless/aoc2025/tree/main/day_01

#AdventOfCode #AdventOfCode2025 #coding #programming #dlang

Advent of Code 2025 - Day 1 solutions in D :

https://github.com/jimlawless/aoc2025/tree/main/day_01

#AdventOfCode #AdventOfCode2025 #coding #programming #dlang

2025年 D言語まとめ
https://qiita.com/lempiji/items/3576e2851d27c2715f97?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items

#qiita #プログラミング #dlang #まとめ #プログラミング言語