Every single macOS download I've tried of Eul has been completely broken. It simply won't launch. Doing so from the Terminal gives the following output:

  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).

You need to unpack it via upx first. Then you'll be able to see the shared library dependencies with `otool`.

there is a libnanovg.a homebrew formula for now.

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.

You can make syscalls with inline assembly (SVC 0x80).

Not on macOS. macOS does not guarantee syscall compatibility between OS versions. The only supported mechanism for invoking syscalls is via libc.

You can do it, it’s how libsystem does it. A lot of AppStore apps use it for jailbreak testing too, e.g. testing sandbox integrity, or to call ptrace with PT_DENY_ATTACH. Apple lets these apps pass review and onto the AppStore.

Do you know how often, if ever, Apple ever changes the syscall table other than to add to it?

libSystem is provided by Apple. The fact that libSystem does it does not mean you can do it without libSystem, as libSystem is the one and only supported way to do this.

> 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".

I'd love to hear more. Maybe I'm a bit confused: the documentation says that functions are pure, and then the example functions look like they are full of side-effects. Does anyone have a good explanation of how purity and effects work in Eul?

It doesn't answer your question, but the language shown on the page is called "lang" -- eul is an application that "lang" was invented to write. eul itself is a multi-protocol desktop messaging client.

That said, these functions look pretty impure.

Cool little language, but

> functions are pure.

I think you need to reconsider what pure means

is the only relevance of that touhou meme that it uses the word "pure"?

Normally I think "rewrite it in Rust!" comments are annoying, but in this case the author's requirements sound pretty relevant:

- 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?

On the other hand, Rust definitely does not have "Fast compilation", and although debatable, I would say that "Simplicity" is not one of Rusts many virtues.

> On the other hand, Rust definitely does not have "Fast compilation",

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.

I think it's one of these things where C is 'simple' but using it often isn't. Taken to the most absurd extreme, Brainfuck is even simpler. So I'm not sure that simplicity is necessarily a virtue in a programming language.

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.

I'll repeat what a lot of other people have said on this one. I think Rust puts the vast majority of its complexity up front, so that you have to deal with it even in toy programs. However, once your toy program is working, it can expand into a real program without uncovering bugs or running into a lot of new complexity. C on the other hand, can make toy programs appear simple. However, there can be a lot of undefined behavior in those programs, which will turn into serious bugs as the programs get more interesting. I like this article for talking about some of those cases: https://blog.regehr.org/archives/1520

Since we're suggesting alternatives already I would like to throw Nim into the mix.

- 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.

If we're playing "recommend a language", I'll mention my personal favorite: Zig.

-`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.

If we're playing "languages that compile to C" I'll add Vala.

- 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/Vala

I'll second Zig. I tried Rust and it was just too much overhead for me. I felt immediately comfortable with Zig, and focused on the task at hand. I hope it gets more traction and more people work on it. I will when I'm competent enough!

Go: func

Eul: fn

Come on, it should be "fun".

Maybe they want to allow for user-defined fun?

If the language was really cool, you could override the keyword anyways.

Weird, the linux link on the front page of this website gives a 404

This works: https://github.com/eul-im/eul/releases/download/v0.34/eul_li...

Aside: This is 64-bit. Is there a 32-bit version?

It sounds interesting. Is the language open-sourced?

> The language will be open-sourced later in 2018.

Given the relationship between eul author and deadlines it won't happen in 2018. Author also promised to open-source eul itself at first but last statement is "I'm not 100% sure it's going to be possible."[0]

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...

how is it pronounced? Like Euler?

> Safety

> Variables are immutable by default, globals are not allowed, functions are pure.

This is a huge non-sequitur.