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

[pouya1dev]

On Friday, 21 August 2026 at 19:05:25 UTC, user1234 wrote:
> 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.

I agree with you, it really makes things easier with an 
intermediate language like LLVM, and LLVM is also used in big 
compilers like LDC. But it's also hard to learn because it's an 
intermediate language and it's made for compilers to write, not 
humans. But it makes sense to learn it because of its great power.