Eul – The language
eul.im
eul.im
dyld: Library not loaded: libnanovg.a
Referenced from: /Applications/eul.app/Contents/MacOS/./eul
Reason: image not found
Weirdly, `otool -L eul` tells me that eul links against no dynamic libraries whatsoever (not even libSystem) and `otool -l eul` backs this up. I'm really curious how Eul managed to have zero dynamic library dependencies in the Mach-O headers and yet clearly still depends on them (especially because on macOS you must link against libSystem or you can't even make syscalls).https://github.com/eul-im/eul/issues/83#issuecomment-3844554...
eul only supports twitter, slack and skype atm and the rest say they're coming later in march. The roadmap shows may-june.
Do you know how often, if ever, Apple ever changes the syscall table other than to add to it?
> Do you know how often, if ever, Apple ever changes the syscall table other than to add to it?
I don't know, but I'm pretty sure the answer is something other than "never".
That said, these functions look pretty impure.
> functions are pure.
I think you need to reconsider what pure means
- integration with C libraries
- overhead similar to C
- more productive than C
- "Variables are immutable by default, globals are not allowed, functions are pure."
That does sound an awful lot like Rust, at least if we kind of squint our eyes at the purity requirement :) I wonder if the original author considered it?
True, though several people are now working on compiler performance.
> and although debatable, I would say that "Simplicity" is not one of Rusts many virtues.
I've found that Rust seems as simple as it can be given the problem it's solving. For instance, lifetimes and borrow checking aren't trivial, but I have a hard time thinking of a simpler abstraction that has the same safety and performance properties.
Another way to look at it: C is "simpler", in some ways, but it pushes the corresponding complexity into the heads of developers and the code of helper/wrapper libraries and tools.
That said, I don't think Rust is that complicated - it's just that a lot of the concepts it uses are unfamiliar to a lot of people and 'best practices' are not always set in stone because of that, which causes confusion - that's more of a maturity thing than anything else. Contrast with C++ (or C# or Java) which certainly is a complex language, but people aren't that confused by it because there are a wealth of books which prescribe the best ways to do things in any given scenario.
- Variables aren't immutable by default, but neither are they mutable by default.
- Globals are discouraged.
- Nim compiles to C so integration with C libraries is easy and overhead is also similar to C.
- Productivity is subjective but I'd say it's significantly more productive than C.
- Despite going through a C compiler the compilation is still incredibly fast.
-`const` for declaring immutables, `var` for mutables, do what you want.
-Use globals if you want, or don't.
-Can directly import C headers, generally no need to write bindings.
-Personally I've found it significantly more productive
-Compiles fast, but lets be fair, people only bring this up because C++ and Rust are the outliers here by compiling so slowly.
Other noteworthy features:
-Standard library is completely optional.
-No default allocator.
-Comptime functionality instead of macros.
- Many apps for Elementary and other Gnome platforms are written in it
- oop
- properties/automatic getter,setter
- for each loops
- closures
- reference counting
- great compatibility with Gnome things
- interoperable with c
GTK example (from german wikipedia):
using Gtk;
int main (string[] args) {
Gtk.init (ref args);
var window = new Window ();
window.title = "A simple GTK+ Program";
window.set_default_size (300, 50);
window.position = WindowPosition.CENTER;
window.destroy.connect (Gtk.main_quit);
var button = new Button.with_label ("Click me!");
button.clicked.connect (() => {
button.label = "Thanks!";
});
window.add (button);
window.show_all ();
Gtk.main ();
return 0;
}
https://en.wikipedia.org/wiki/Vala_(programming_language)
https://wiki.gnome.org/Projects/ValaEul: fn
Come on, it should be "fun".
Aside: This is 64-bit. Is there a 32-bit version?
Current state of eul app also hinting that most likely nothing of value would be lost if this language won't be open-sourced.
[0] - https://github.com/eul-im/eul/issues/45#issuecomment-3356427...
> Variables are immutable by default, globals are not allowed, functions are pure.
This is a huge non-sequitur.