Re: Experimental builds for Euphoria 4.2
- Posted by ghaberek (admin) 2 months ago
- 1063 views
For me it's mainly the fact that pre-compiled euc didn't work on my Linux distro
I'm curious which distro you're using as I'm hoping to cover "most" cases without having to provide bespoke hand-crafted builds to everyone.
and all the attempts to build Euphoria 4.1 from source have failed
You need a working translator to build "from source" since all of the front end is written in Euphoria. So if euc doesn't work for you, building new binaries won't either.
Now euc works correctly, but the performance of final executables is not what I expected. Some programs run five times faster that interpreted by eui and some only two.
Some empirical measurements and examples would be very helpful here. Nobody wants to lose performance and it's entirely possible I, or someone along the way, goofed something up. Or we're fighting some kind of change or regression in GCC.
It's a shame that OpenEuphoria can't compete with languages like Nim, V or BaCon.
What's a shame is that the Euphoria code we're building today is largely the same as it was twenty years ago. Nim and V were started in 2008 and 2019 respectively, and they both have had the benefit of a "clean slate" design based on modern principles and technology at that time. BaCon, despite being from the dark ages, has seemingly advanced in step with modern technology, probably by keeping pace behind GCC.
If you want to see Euphoria get back into the ring with modern languages like Nim, or V, or Zig, or Rust, or Python, or Go, or Swift, or Ruby, and so on... then I implore you, please put together some code tests that demonstrate your concerns so we can actively test against it. Euphoria certainly can compete, but it's been sitting on the bench for years. Let's change that.
-Greg
