dyld: Library not loaded: libnanovg.a
Referenced from: /Applications/eul.app/Contents/MacOS/./eul
Reason: image not found
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.
- 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.
- 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.
> functions are pure.
I think you need to reconsider what pure means
Eul: fn
Come on, it should be "fun".
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...
That said, these functions look pretty impure.
Aside: This is 64-bit. Is there a 32-bit version?
> Variables are immutable by default, globals are not allowed, functions are pure.
This is a huge non-sequitur.
