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

[pouya1dev]

On Saturday, 22 August 2026 at 07:17:52 UTC, pouya1dev wrote:
> 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.

To be honest, I’m currently working on a comprehensive 
application for both Windows and Linux that serves as a 
full-fledged code editor for Eko, with community features powered 
by something like Supabase. It will also allow users to switch 
between Eko versions directly from the app, without having to 
manually download and install different versions from GitHub.