Eko: New Programming language write entirely in D (Feedback welcome)

[user1234]

On Friday, 21 August 2026 at 18:39:00 UTC, pouya1dev wrote:
> On Friday, 21 August 2026 at 18:12:23 UTC, pouya1dev wrote:
>> On Friday, 21 August 2026 at 17:54:32 UTC, user1234 wrote:
>>> On Friday, 21 August 2026 at 17:01:13 UTC, pouya1dev wrote:
>>>> Thank you very much. I will definitely look into the 
>>>> examples you provided.
>>>
>>> I forgot to mention a few several ones. Notably styx-lang. 
>>> You also have two alternatives D front-ends written 
>>> themselves in D. You see it's a classic to write programming 
>>> languages. A bit like game engines.
>>>
>>> Recently we also had an annouce about someone using D to 
>>> write a scripting engine but it was AI slop (Kite), so the 
>>> topic was a bit delicate if you see what I mean.
>>>
>>> There is also one that was made for a game engine, I remember 
>>> a conversation with the author on IRC but I cant find any 
>>> official annouce RN.
>>
>> Thanks again. These examples will help me a lot. And it's 
>> really interesting that D has a long history of writing 
>> interpreters or compilers. To be honest, D is really one of 
>> the best options for this because it's both simple and has 
>> built-in functions unlike C. But C is also a good option and a 
>> very classic option in the programming community. I have a 
>> plan not to write my entire language based on D. Because it 
>> will be significantly more dependent and a bug in D might 
>> break my language. (Of course the D team is always working 
>> hard to develop and improve D) and I wish Eko would be 
>> self-hosted.
>
> For example, I started writing an assembler for eko in the Nim 
> language. Because Nim has a syntax similar to Python and is 
> compiled, it is easier to understand and faster to write.
> And there is a library like ```nifasm```, using which you no 
> longer have to define the binary manually for, for example, 
> ```mov``` And you create a variable as a buffer and use 
> ```emitMov``` to create the binary and store it in this buffer.

I see, you're mentioning the intermediate representation here. So 
there can be atomic `mov` or `mov`es that are more like `memcpy`, 
with eventually the postbliting problem, when it's about copying 
a user type, that, let say, contains interior pointers.

> I think the hardest part for me was creating the elf.

Indeed emitting object files, such as elf, requires a certain 
amount of work (instruction set, sections, static ctors, etc.). 
Not to speak about the debug infos. Toward this problem here I've 
chosen LLVM.