Distributing an Eiffel compiler
19 views
Skip to first unread message
Ulrich Windl
Aug 19, 2026, 1:41:07 PM (7 days ago) Aug 19
to Eiffel Users
Hi!
During today's lunch break I was thinking why popular Linux distributions lack an Eiffel development environment, and I wondered what might change it.
First there is the licence that may prevent inclusion with the OS. You easily get compilers for C, C++, Objective-C, FORTRAN, Rust, etc. you get Java, Scheme, Perl Phyton, Ruby, R, etc. Is it just a more favorable license?
Some people are restricted to a text terminal interface, so development should be usable with text-only tools also.
Finally I was thinking about modularization of the Eiffel programming environment. Like separating the pure compiler, bas libraries and runtime, adding extra libraries and graphical IDE. Having a tool like Rust's "cargo" that can easily create, compile and run projects from the command line would be nice for people that prefer or are restricted to a text environment.
These are just my thoughts. Sometimes it's easier to deploy a language when it's part of an operating system distribution (and the distribution takes care of bugs and security issues). For me it would be easier to https://sbr5vjid0jgmce4q.myfritz.net:40262/nas/filelink.lua?id=099a0cf907ef1b41
external systems reachable via an RDP "jumphost" and connect via SSH to the final host. Not much fun, also because RDP over UDP occasionally drops key events or delays them at another time, causing unwanted key repeats. I feel like having time -traveled back to 1992 or even worse ☹️
And IMHO any Eiffel runtime that lacks an automatic garbage collector is academic at best, but unusable for real-life applications.
BTW: I think it was around 1986 when Niklaus Wirth had reported about Oberon using a 32bit architecture that has "such a huge address space" that will never be exhausted (sorry, I can't remember the exact details). OK, at that time a computer with 4MB RAM was a big server... 😉
Ulrich
During today's lunch break I was thinking why popular Linux distributions lack an Eiffel development environment, and I wondered what might change it.
First there is the licence that may prevent inclusion with the OS. You easily get compilers for C, C++, Objective-C, FORTRAN, Rust, etc. you get Java, Scheme, Perl Phyton, Ruby, R, etc. Is it just a more favorable license?
Some people are restricted to a text terminal interface, so development should be usable with text-only tools also.
Finally I was thinking about modularization of the Eiffel programming environment. Like separating the pure compiler, bas libraries and runtime, adding extra libraries and graphical IDE. Having a tool like Rust's "cargo" that can easily create, compile and run projects from the command line would be nice for people that prefer or are restricted to a text environment.
These are just my thoughts. Sometimes it's easier to deploy a language when it's part of an operating system distribution (and the distribution takes care of bugs and security issues). For me it would be easier to https://sbr5vjid0jgmce4q.myfritz.net:40262/nas/filelink.lua?id=099a0cf907ef1b41
external systems reachable via an RDP "jumphost" and connect via SSH to the final host. Not much fun, also because RDP over UDP occasionally drops key events or delays them at another time, causing unwanted key repeats. I feel like having time -traveled back to 1992 or even worse ☹️
And IMHO any Eiffel runtime that lacks an automatic garbage collector is academic at best, but unusable for real-life applications.
BTW: I think it was around 1986 when Niklaus Wirth had reported about Oberon using a 32bit architecture that has "such a huge address space" that will never be exhausted (sorry, I can't remember the exact details). OK, at that time a computer with 4MB RAM was a big server... 😉
Ulrich
Eric Bezault
Aug 19, 2026, 3:28:17 PM (7 days ago) Aug 19
to eiffel...@googlegroups.com
Hello,
About the license concern, ISE Eiffel can be used with the GNU license
(although the version of the tool will be one year older, but unless
one wants to use constructs not in the standard yet, it does not really
matter). And Gobo Eiffel can be used with the MIT license.
About the availability of a command-line Eiffel compiler, ISE Eiffel
can be used that way, using `ec` or `ecb` from the command-line instead
of EiffelStudio. True, it is distributed with the graphical environment
and one cannot install the command-line compiler separately. But with
Gobo Eiffel you can do so: `gec` is a command-line compiler, and one
has to install the VS Code extension separately in order to use it from
a graphical environment.
About Rust's cargo, I'm not familiar with this tool. Here is what one
can do with Gobo Eiffel though:
- Download and unzip the Gobo package. No need to set any
environment variable, but for convenience you might want
to add the bin/ folder to your $PATH. That's is, you can
now use the Eiffel compiler.
- Your first hello world program:
$ gec --init --compile --run hello_world
This generates a HELLO_WORLD class and its ECF file (--init),
compiles it (--compile) and executes it (--run). These 3 options
can be used separately.
About garbage collector, both ISE Eiffel and Gobo Eiffel have a GC.
They also both support SCOOP (which removes the need to program
directly with threads/mutex/etc. in the same way GC removes the
need to program directly with malloc/free).
Both ISE Eiffel and Gobo Eiffel support the ECMA standard. And
Eiffel classes and ECF files written with ISE Eiffel can be used
as-is with Gobo Eiffel, and vice versa.
--
Eric Bezault <er...@gobosoft.com>
Eiffel expert - available for freelance work
https://www.gobosoft.com
About the license concern, ISE Eiffel can be used with the GNU license
(although the version of the tool will be one year older, but unless
one wants to use constructs not in the standard yet, it does not really
matter). And Gobo Eiffel can be used with the MIT license.
About the availability of a command-line Eiffel compiler, ISE Eiffel
can be used that way, using `ec` or `ecb` from the command-line instead
of EiffelStudio. True, it is distributed with the graphical environment
and one cannot install the command-line compiler separately. But with
Gobo Eiffel you can do so: `gec` is a command-line compiler, and one
has to install the VS Code extension separately in order to use it from
a graphical environment.
About Rust's cargo, I'm not familiar with this tool. Here is what one
can do with Gobo Eiffel though:
- Download and unzip the Gobo package. No need to set any
environment variable, but for convenience you might want
to add the bin/ folder to your $PATH. That's is, you can
now use the Eiffel compiler.
- Your first hello world program:
$ gec --init --compile --run hello_world
This generates a HELLO_WORLD class and its ECF file (--init),
compiles it (--compile) and executes it (--run). These 3 options
can be used separately.
About garbage collector, both ISE Eiffel and Gobo Eiffel have a GC.
They also both support SCOOP (which removes the need to program
directly with threads/mutex/etc. in the same way GC removes the
need to program directly with malloc/free).
Both ISE Eiffel and Gobo Eiffel support the ECMA standard. And
Eiffel classes and ECF files written with ISE Eiffel can be used
as-is with Gobo Eiffel, and vice versa.
--
Eric Bezault <er...@gobosoft.com>
Eiffel expert - available for freelance work
https://www.gobosoft.com
Alejandro Garcia
Aug 19, 2026, 4:53:56 PM (7 days ago) Aug 19
to eiffel...@googlegroups.com
There is also GNU Eiffel / liberty eiffel
https://www.gnu.org/software/liberty-eiffel/
Since it is GNU-approved, an Eiffel compiler could theoretically be included in many GNU/Linux distributions.
It's just a matter of finding a maintainer committed to making that happen.
For me personally, I'm more in favor of the approach taken by Finnian outlined in his article:
https://www.eiffel.org/blog/Finnian%20Reilly/2026/05/finding-billion-user-project-eiffel-how-dbc-catches-security-flaws-rust-misses
my summary:
Let's create a kille-app, ie. a software so compelling that makes people want to buy a computer just to run it.
What VisiCalc and Lotus were for the PC.
But for Eiffel.
I'm working on my own version of that idea: RESTLY a library to create and consume microservices directly in Eiffel.
https://www.gnu.org/software/liberty-eiffel/
Since it is GNU-approved, an Eiffel compiler could theoretically be included in many GNU/Linux distributions.
It's just a matter of finding a maintainer committed to making that happen.
For me personally, I'm more in favor of the approach taken by Finnian outlined in his article:
https://www.eiffel.org/blog/Finnian%20Reilly/2026/05/finding-billion-user-project-eiffel-how-dbc-catches-security-flaws-rust-misses
my summary:
Let's create a kille-app, ie. a software so compelling that makes people want to buy a computer just to run it.
What VisiCalc and Lotus were for the PC.
But for Eiffel.
I'm working on my own version of that idea: RESTLY a library to create and consume microservices directly in Eiffel.
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/77a2c403-0d92-4e48-a23e-50a49b9be123%40gobosoft.com.
Alejandro García F. (elviejo)
https://elviejo79.github.io
Too brief? Here's why! https://www.emailcharter.info
EOM – End Of Message. The whole message is in the subject don't need to open it.
NNTR – No Need To Respond. Help cut down on all those “cool” and “thanks” emails.
SINGLE SUBJECT. Send one email for one topic, this makes replies easy..
CLEAR CALL TO ACTION: Ask for some specific result very clearly.
https://elviejo79.github.io
Too brief? Here's why! https://www.emailcharter.info
EOM – End Of Message. The whole message is in the subject don't need to open it.
NNTR – No Need To Respond. Help cut down on all those “cool” and “thanks” emails.
SINGLE SUBJECT. Send one email for one topic, this makes replies easy..
CLEAR CALL TO ACTION: Ask for some specific result very clearly.
Eric Bezault
Aug 20, 2026, 3:50:08 AM (6 days ago) Aug 20
to eiffel...@googlegroups.com
Hello,
I did not mention Liberty Eiffel because:
- it does not seem to be actively maintained (10 commits between
January and August 2025, and no commit since then).
- the current mailing list is for users of EiffelStudio, and
Liberty Eiffel does not support the ECMA standard, and therefore
cannot compile Eiffel programs written by users of EiffelStudio.
For example, if your RESTLY library is written with EiffelStudio
you won't be able to use it with Liberty Eiffel, and vice versa.
--
Eric Bezault <er...@gobosoft.com>
Eiffel expert - available for freelance work
https://www.gobosoft.com
> software/liberty-eiffel/>
> www.eiffel.org/blog/Finnian%20Reilly/2026/05/finding-billion-user-
> project-eiffel-how-dbc-catches-security-flaws-rust-misses>
> Eric Bezault <er...@gobosoft.com <mailto:er...@gobosoft.com>>
> a23e-50a49b9be123%40gobosoft.com>.
>
>
> Too brief? Here's why! https://www.emailcharter.info <http://
> emailcharter.org>
> users+un...@googlegroups.com>.
> CALFgaYBB5ELRj%2BTypnO2xFCRPuMfmBsQ54A2CRma%3D020WSJTAw%40mail.gmail.com
> <https://groups.google.com/d/msgid/eiffel-users/
> CALFgaYBB5ELRj%2BTypnO2xFCRPuMfmBsQ54A2CRma%3D020WSJTAw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
I did not mention Liberty Eiffel because:
- it does not seem to be actively maintained (10 commits between
January and August 2025, and no commit since then).
- the current mailing list is for users of EiffelStudio, and
Liberty Eiffel does not support the ECMA standard, and therefore
cannot compile Eiffel programs written by users of EiffelStudio.
For example, if your RESTLY library is written with EiffelStudio
you won't be able to use it with Liberty Eiffel, and vice versa.
--
Eric Bezault <er...@gobosoft.com>
Eiffel expert - available for freelance work
https://www.gobosoft.com
On 19/08/2026 22:53, Alejandro Garcia wrote:
> There is also GNU Eiffel / liberty eiffel
> https://www.gnu.org/software/liberty-eiffel/ <https://www.gnu.org/
> There is also GNU Eiffel / liberty eiffel
> software/liberty-eiffel/>
>
> Since it is GNU-approved, an Eiffel compiler could theoretically be
> included in many GNU/Linux distributions.
> It's just a matter of finding a maintainer committed to making that happen.
>
> For me personally, I'm more in favor of the approach taken by Finnian
> outlined in his article:
> https://www.eiffel.org/blog/Finnian%20Reilly/2026/05/finding-billion-
> user-project-eiffel-how-dbc-catches-security-flaws-rust-misses <https://
> Since it is GNU-approved, an Eiffel compiler could theoretically be
> included in many GNU/Linux distributions.
> It's just a matter of finding a maintainer committed to making that happen.
>
> For me personally, I'm more in favor of the approach taken by Finnian
> outlined in his article:
> https://www.eiffel.org/blog/Finnian%20Reilly/2026/05/finding-billion-
> www.eiffel.org/blog/Finnian%20Reilly/2026/05/finding-billion-user-
> project-eiffel-how-dbc-catches-security-flaws-rust-misses>
> Eiffel expert - available for freelance work
> https://www.gobosoft.com <https://www.gobosoft.com>
>
>
>
> On 19/08/2026 19:40, Ulrich Windl wrote:
> > Hi!
> >
> > During today's lunch break I was thinking why popular Linux
> distributions lack an Eiffel development environment, and I wondered
> what might change it.
> > First there is the licence that may prevent inclusion with the
> OS. You easily get compilers for C, C++, Objective-C, FORTRAN, Rust,
> etc. you get Java, Scheme, Perl Phyton, Ruby, R, etc. Is it just a
> more favorable license?
> > Some people are restricted to a text terminal interface, so
> development should be usable with text-only tools also.
> > Finally I was thinking about modularization of the Eiffel
> programming environment. Like separating the pure compiler, bas
> libraries and runtime, adding extra libraries and graphical IDE.
> Having a tool like Rust's "cargo" that can easily create, compile
> and run projects from the command line would be nice for people that
> prefer or are restricted to a text environment.
> >
> > These are just my thoughts. Sometimes it's easier to deploy a
> language when it's part of an operating system distribution (and the
> distribution takes care of bugs and security issues). For me it
> would be easier to https://sbr5vjid0jgmce4q.myfritz.net:40262/nas/
> filelink.lua?id=099a0cf907ef1b41 <https://
>
>
> On 19/08/2026 19:40, Ulrich Windl wrote:
> > Hi!
> >
> > During today's lunch break I was thinking why popular Linux
> distributions lack an Eiffel development environment, and I wondered
> what might change it.
> > First there is the licence that may prevent inclusion with the
> OS. You easily get compilers for C, C++, Objective-C, FORTRAN, Rust,
> etc. you get Java, Scheme, Perl Phyton, Ruby, R, etc. Is it just a
> more favorable license?
> > Some people are restricted to a text terminal interface, so
> development should be usable with text-only tools also.
> > Finally I was thinking about modularization of the Eiffel
> programming environment. Like separating the pure compiler, bas
> libraries and runtime, adding extra libraries and graphical IDE.
> Having a tool like Rust's "cargo" that can easily create, compile
> and run projects from the command line would be nice for people that
> prefer or are restricted to a text environment.
> >
> > These are just my thoughts. Sometimes it's easier to deploy a
> language when it's part of an operating system distribution (and the
> distribution takes care of bugs and security issues). For me it
> would be easier to https://sbr5vjid0jgmce4q.myfritz.net:40262/nas/
> sbr5vjid0jgmce4q.myfritz.net:40262/nas/filelink.lua?id=099a0cf907ef1b41>
> > external systems reachable via an RDP "jumphost" and connect via
> SSH to the final host. Not much fun, also because RDP over UDP
> occasionally drops key events or delays them at another time,
> causing unwanted key repeats. I feel like having time -traveled back
> to 1992 or even worse ☹️
> >
> > And IMHO any Eiffel runtime that lacks an automatic garbage
> collector is academic at best, but unusable for real-life applications.
> > BTW: I think it was around 1986 when Niklaus Wirth had reported
> about Oberon using a 32bit architecture that has "such a huge
> address space" that will never be exhausted (sorry, I can't remember
> the exact details). OK, at that time a computer with 4MB RAM was a
> big server... 😉
> >
> > Ulrich
> >
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to eiffel-users...@googlegroups.com
> <mailto:eiffel-users%2Bunsu...@googlegroups.com>.
> > external systems reachable via an RDP "jumphost" and connect via
> SSH to the final host. Not much fun, also because RDP over UDP
> occasionally drops key events or delays them at another time,
> causing unwanted key repeats. I feel like having time -traveled back
> to 1992 or even worse ☹️
> >
> > And IMHO any Eiffel runtime that lacks an automatic garbage
> collector is academic at best, but unusable for real-life applications.
> > BTW: I think it was around 1986 when Niklaus Wirth had reported
> about Oberon using a 32bit architecture that has "such a huge
> address space" that will never be exhausted (sorry, I can't remember
> the exact details). OK, at that time a computer with 4MB RAM was a
> big server... 😉
> >
> > Ulrich
> >
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to eiffel-users...@googlegroups.com
> To view this discussion visit https://groups.google.com/d/msgid/
> eiffel-users/77a2c403-0d92-4e48-a23e-50a49b9be123%40gobosoft.com
> <https://groups.google.com/d/msgid/eiffel-users/77a2c403-0d92-4e48-
> eiffel-users/77a2c403-0d92-4e48-a23e-50a49b9be123%40gobosoft.com
> a23e-50a49b9be123%40gobosoft.com>.
>
>
>
> --
> Alejandro García F. (elviejo)
> https://elviejo79.github.io <https://elviejo79.github.io>
>
>
> --
> Alejandro García F. (elviejo)
>
>
> Too brief? Here's why! https://www.emailcharter.info <http://
> emailcharter.org>
> EOM – End Of Message. The whole message is in the subject don't need to
> open it.
> NNTR – No Need To Respond. Help cut down on all those “cool” and
> “thanks” emails.
> SINGLE SUBJECT. Send one email for one topic, this makes replies easy..
> CLEAR CALL TO ACTION: Ask for some specific result very clearly.
>
> open it.
> NNTR – No Need To Respond. Help cut down on all those “cool” and
> “thanks” emails.
> SINGLE SUBJECT. Send one email for one topic, this makes replies easy..
> CLEAR CALL TO ACTION: Ask for some specific result very clearly.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to eiffel-users...@googlegroups.com <mailto:eiffel-
> You received this message because you are subscribed to the Google
> Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> users+un...@googlegroups.com>.
> CALFgaYBB5ELRj%2BTypnO2xFCRPuMfmBsQ54A2CRma%3D020WSJTAw%40mail.gmail.com
> <https://groups.google.com/d/msgid/eiffel-users/
> CALFgaYBB5ELRj%2BTypnO2xFCRPuMfmBsQ54A2CRma%3D020WSJTAw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Finnian Reilly
Aug 20, 2026, 5:44:24 AM (6 days ago) Aug 20
to eiffel...@googlegroups.com
my summary:
Let's create a kille-app, ie. a software so compelling that makes people want to buy a computer just to run it.
What VisiCalc and Lotus were for the PC.
But for Eiffel.
I'm working on my own version of that idea: RESTLY a library to create and consume microservices directly in Eiffel.
Hi Alejandro
I am glad other people are thinking about how to make an Eiffel killer-app. If we all start projects like this perhaps one of us will get lucky and put Eiffel back on the map. Claude AI suggested these other projects as well if anyone would like to try.
Of course it doesn't have to be security orientated, it could simply be a compelling app no one has thought of before. But I would suggest security orientated apps play to Eiffel's strengths in the same way as they do to Rust's rigorous memory management.The criteria — widely deployed, logic-error CVE history, no Rust rewrite, achievable scope, specification-driven domain, permissive licence — can be applied systematically.
libyaml is a C YAML parser with a CVE history that includes integer overflows and heap corruption. YAML is widely used in configuration files across the DevOps ecosystem. It is small — comparable to libexpat in scope. No serious Rust rewrite exists as a drop-in replacement.
A DNS stub resolver is another candidate. DNS resolution is specification-driven, security-critical, present on every networked device, and the existing C implementations have accumulated significant CVE histories. A clean Eiffel implementation with formal contracts on the packet parsing logic would be compelling.
A JSON parser is a smaller scope project — potentially appropriate as a learning exercise or proof of concept before tackling a full XML parser. JSON's grammar is simpler than XML's, the CVE surface is smaller, but the ecosystem is enormous and a well-packaged Eiffel JSON library with Python bindings would get immediate traction.
The important principle is that each project should follow the same pattern: C-compatible interface where applicable, contracts derived from the specification, CVE regression tests as the correctness baseline, and a Python binding as the community-facing distribution channel.
By coincidence I recently started listening to a critique of microservices as an architecture from Karell Ste-Marie, a retired CTO.
https://www.youtube.com/watch?v=6e9B7q3gvYY
Wondering how a microservices advocate would respond to his critique.
best of luck with your project
Finnian
To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CALFgaYBB5ELRj%2BTypnO2xFCRPuMfmBsQ54A2CRma%3D020WSJTAw%40mail.gmail.com.
-- SmartDevelopersUseUnderScoresInTheirIdentifiersBecause_it_is_much_easier_to_read (Eiffel = Security by Contract + C Speed)
Reply all
Reply to author
Forward
0 new messages