#dlang — Public Fediverse posts

Недавно достиг первого результата в SDL GPU: потестировал меши, трансформации, постпроцессинг свечения - простой, но зрелищный эффект, текстуры и прочее элементарное.

Вышел регулятор Уатта из эпохи паровых машин. Механизм ходит не слишком ровно, но я доволен. Хотя бы что-то движок уже показывает.

Есть некоторые проблемы производительности при смешивании старого SDL_Renderer и нового API.

https://www.youtube.com/shorts/wX5A2W_oJI4

#dlang #sdl #enginedev #graphicsprogramming #программирование #ит

Попытка оптимизировать техноблог, обходясь лишь видеоплощадками - с треском провалилась. Трудоёмкость экспериментов создаёт перерывы в видео, нужно место для девлогов. Приземляемся в Mastodon обратно.

Фиксируем результат весны 2026. Лучше развился инфоотсек: почти выстроен прототип GUI-тулкита на #SDL (SDL_Renderer + Cairo) и #Dlang. Но SDL GPU в SDL3 заставляет погружаться в 3D. Весной вспоминал OpenGL, аналогией портируя в SDL GPU и HLSL.

#enginedev #graphicsprogramming #программирование #ит

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 #フラクタル図形

The latest and greatest: BindBC-bgfx 1.0 is coming out very soon! It features a new API based on bgfx’s C++ API with some slight tweaks to make it match the D style better, so it should be a lot nicer to use than before! :) and yes, it’s still auto-generated so it has full documentation!
I’ve already converted one of my projects to using it and I’m excited to see everyone else getting to try it!

#bindbc #dlang #foss #bgfx #programming #programminglanguages

The latest and greatest: BindBC-bgfx 1.0 is coming out very soon! It features a new API based on bgfx’s C++ API with some slight tweaks to make it match the D style better, so it should be a lot nicer to use than before! :) and yes, it’s still auto-generated so it has full documentation!
I’ve already converted one of my projects to using it and I’m excited to see everyone else getting to try it!

#bindbc #dlang #foss #bgfx #programming #programminglanguages

#OpenD is a fork of #D by Adam Ruppe, et al 😥:

https://forum.dlang.org/thread/beykokf[email protected]?page=1

https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_01.html

https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.html

It doubles down on the #GarbageCollection. 😐

#DLang #GC #ProgrammingLanguages

I’ve been needing something akin to, what I now know to be Java’s ExecutorService, but in my language of choice - D! So I decided to go about it and implement it.

I’ve written it in such a manner such that is is extendable and new providers (job runners, think “pooled threads”, “serial runners” and so on) can be plugged in easily. For the initial proof of concept I created a SequentialProvider which just consumes tasks and executes them on a single thread in serial, next up is the thread pool version which I will get around to soon enough.

It’s really been fun to actually play with meta-programming more in D - I had to this time as I had to be able to make using this library as pleasant as possible as I require it for a project of mine - and I don’t want any hassles.

So there ya go!

https://deavmi.assigned.network/blog/guillotine/

#threading #executors #futures #dlang

A mix of neat and not-so-neat stuff 🫤:

“10 Features Of D That I Love”, Bradley Chatha (https://bradley.chatha.dev/blog/dlang-propaganda/features-of-d-that-i-love/).

Via HN: https://news.ycombinator.com/item?id=44445877

On Lobsters: https://lobste.rs/s/msjy28/10_features_d_i_love

#Programming #D #DLang #ProgrammingLanguages #Syntax #Listicle #Raves

I spent a year of my life making an ASN.1 compiler in D

https://bradley.chatha.dev/blog/dlang-propaganda/asn1-compiler-in-d/

#HackerNews #ASN1Compiler #DLang #Programming #YearOfCode #TechJourney

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

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