Elchemy – write type safe Elixir using Elm-like syntax | Hacker News Reader

Elchemy – write type safe Elixir using Elm-like syntax

wende.github.io

142 pointsmethyl56 comments

Love the concept.

But please don't use fonts with ligatures in code snippets on the homepage. Especially when these code examples are actually screenshots which people can't copy.

Ligatures may be "obvious" to developers already familiar with the syntax of the language, but can make things very confusing for beginners, esp. in FP languages that lean heavily on operators etc.

I am really glad that the docs/roadmap etc. are on Github. Github is really the gold standard when it comes to programmer friendly aesthetics.

Maybe this isn't targeting new users, then.

His preferences supersede your sensibilities since its his website, don't you think?

Parent did say “please”.

I never said he was rude!

You can politely ask the wrong questions sometimes.

Meh. You can reasonably expect someone interested in this project would have at least some passing understanding of functional programming, if not the niche of programming Elm and Elixir are trying to fill. In which case arrows and lambdas should be fine. Even if you're a C++ developer, you've seen arrows drawn in some capacity, I can't imagine what confusion using an arrow could possibly cause.

The confusion, which may not apply for a savvy developer, would arise from somehow believing that the unicode arrow (→) is being used and not the hyphen-greater-than-sign (->) arrow.

How hard is it to look it up if you find yourself willing to learn the language? I have a hard time seeing this as anything other than an insignificant nit-pick.

That's a good idea. I've never thought about it this way Thank you for a valuable input

Why would this target Elixir instead of Erlang or BEAM byte code directly?

Putting a language on top of a language on top of a language does not seem that smart to me.

Yeah I would expect to see it compile to bytecode. It seems pretty wild to transpile to a language to compile to bytecode to run in a vm when there is already bytecode and a vm to execute against.

Transpiling is common in js only because there isn't/wasn't a standard like webasm.

Similarly, despite the existence of LLVM and the simplicity of the various assemblies, tons of languages target C, mostly to facilitate easier interop with native libraries and because pretty much everything has a C compiler. Perhaps there were similar reasons to compile to Elixir, but I honestly can't think of any. It might just be for faster compiler development, at least until the featureset of Elchemy begins to significantly diverge from that of Elixir.

From the FAQ:

Do I need to have Elm installed to compile my .elm files with Elchemy?

Elchemy uses Elm to typecheck your program. It is possible to use it without Elm on your machine, while it's not advised.

So it seems that it literally transpiles Elm syntax to Elixir, the type safety relies on Elm apparently.

Targetting BEAM directly should be possible in the future, to me it looks like an attempt to save a lot of time to make Elm suitable on the server side.

This. There's no need to rebuild everything from scratch and fail due to too much to do. If the project grows more we can think about going low level. However, right now we can use everything that Erlang has, everything that Elixir has and most of what Elm has. It's a huge time and effort saver

I mean if their goal is to get Elixir developers interested then I think that it satisfies.

First of all thanks for all the interest and a good question! While obviously it would be possible to compile directly to Erlang, or even to Core Erlang it would just add a lot of additional work to do. Elixir adds a phenomenal amount of functionality that made making Elchemy easier. And thanks to building it on such a high level we can leverage most of the Elm tooling goodness as well as Elixir's. Another very important factor is familiarity. People much rather like an environment they already know and it would be silly to try to recreate things like Mix or ExUnit yet again. Another important aspect is the familiarity of the output. Elchemy's priority is producing fully readable Elixir code, which not only adds another layer for learning the language's characteristics as well as a 'belt and braces' for experimenting with it in existing projects - the time cost of removing Elchemy from a project written in it is way smaller than rewriting the logic from scratch

awesome - thanks for the reply. Makes sense. I work with elixir full time and the type-safety bugs me. I'll check this out when I can find some time.

Elixir has Doccomments, meaning it checks the code in your comments for correctness. You get tests without writing them and your comments won't get stale. Three birds one stone.

Or if you’d rather have typeclasses: https://github.com/purerl/purescript

Purescript by example[1] is the most approachable introduction to Functional programming that I have seen (yet).

Even if you don't intend to ever use Purescript itself for application development, the book is worth a read, as an introduction to FP concepts, especially if you are coming from a Javascript/Web-dev background.

[1] https://leanpub.com/purescript/read

You got me interested but the link barely worked on my iPhone...

I largely agree, but it's not without its warts :) https://github.com/paf31/purescript-book/issues/99

It’s also a bit out of date, but nobody’s perfect. :)

Elchemy looks fantastic, especially if you have some frontend in Elm already or you use it in Node microservices. The only thing concerns me that it won’t get enough traction and support and will eventally get abandoned, so here’s some Q’s.

1. What’s the genesis of this project?

2. Do you use it internally, is it backed by any company?

3. Is it already handling some production code?

Thanks!

Hi there, First of all, thank you for the post! It really made my day to see us land on HN I'm glad you like the idea. About the traction, I think I've got a mentality that makes it a little bit more bearable - even if it turns out nobody wants to use the project, I know I will so I'll always try to develop it and spend at least a weekend on it from time to time.

Regarding the questions: 1. It's quite a long story which I'd be willing to tell one day, maybe at some conference. Basically, the idea started from 'typed elixir' which was a small POC project of mine. The Idea was to introduce type inference and annotations using only Elixir's macro system. It had a type inference algorithm I wrote in Prolog (to this day I'm still amazed how easy this language made it) and a bunch of hacky macros. However, after about half a year into development, I realized it's not a project that can be done singlehandedly and that there is simply too many compromises and hackishness to it. Half a year later on a LambdaDays 2016 conference in Kraków, Poland during a rather boring talk I've wrote a simple transpiler of Elm to Elixir as a joke just to find an entertainment. But the longer I developed the joke to more apparent it started to be it's actually something completely doable and with a great potential value.

2. Unfortunately no, not yet. It is being developed by me and sporadically by two other members of my company, but it's in no way supported by any big player. We'd love to get an interest like that though. If by any means some company representative is reading that and considering, please don't hesitate to mail me!

3. Depends on what we mean by production - is it running as a node of a huge Erlang system? - no, and probably won't be for some time. It's still a relatively young project with a lot of space to develop, it is slowly approaching maturity though and I think after we introduce an official way of handling side effects it's going to get much more traction. If the question is of "Is there anything big written already in Elchemy?" then kind off. I'm pretty sure that the biggest project written in Elchemy today is... Elchemy itself. Being self-hosted was very important to me and it is even a part of the CI pipeline right now. The moment of it being able to compile itself and execute in Elixir was a huge milestone in the development and a definite point in time when the project stopped to be just a Proof of Concept. We are currently working on a demo game written in Elm on the frontend and Elchemy on the backend. Its purpose is to demonstrate the maturity of the project, but also pinpoint some possible shortcomings that we might have missed. That's the main reason for starting the Elchemt DevBlog on Medium (https://medium.com/elchemy) to share on the progress and possibly discuss different choices we still have to make

As it's already becoming quite long-ish feel free to join our Gitter chat (https://gitter.im/elchemy-lang/Lobby) or to mail me!

Cheers

This is awesome and important work! I hope that this project can move independently of Elm's development once it gets enough interest though.

We are hoping for that as well. Elm although making an amazing foundation might cause problems in future when introducing backwards incompatible changes for instance. We are trying to keep the safe distance from Elm development not to be too tightly coupled, but still making use of the awesome stuff Elm's team is doing

Looks like your playground is based off Ellie, which is a great choice. However, it seems that there is an issue with downloading the Elm compiler. I'm getting a network failure from ellie's CDN(NAME_NOT_RESOLVED).

Other than that, thank you for this, it is super interesting to me as I am a huge fan of both languages, and lack of type safety has always been my only misgiving with Elixir/Erlang. I'll have to take a spin this weekend.

Sometimes the CDN is acting naughty

That's true. The idea of how Ellie was brought to life is outstanding. Huge shoutout to Luke Wetsby for letting us use his codebase for Elchemy

Feel free to share your thoughts and concerns on GitHub or by email! We'd love to hear your opinion and concerns

<3 thanks

fwiw the latest release moved the compiler back to the server. the ghcjs stuff proved too difficult to deliver a good experience to everyone. a naughty cdn was just one of many woes.

Looks like it's targeted more towards the Elm crowd with npm install instructions than the Elixir crowd with no hex/mix install method.

Elchemy creator here. Quite the opposite to be honest. I come from Elixir background. It's just that npm is much more reliable when it comes to global system-wide installations

Are you saying Mix/Hex is unreliable or are you saying npm is on more machines globally?

He's talking about installing a package globally on your system. That's the -g flag

Hex has global commands as well

There's no real advantage in having a global command when the command doesn't make sense outside of a project folder

So I'm confused, is Elchemy its own language that compiles to Elixir? Or a way to add static types to existing Elixir code?

The former. It is a language almost identical to Elm that compiles to a readable Elixir output. It has all of Elm's advantages - the type system, readable error outputs. On top of that, you can use all of Elm's tools like editor plugins or elm-format so there is no 'reinvent the wheel' syndrome

What would be interesting is to have a subset with managed side effects and purity elixir i.e. something like Elm does at the frontend, the Elm experience is amazing and what annoys me in erlang is having too much effects around

"Beautiful and fully readable output code"

beautiful ... ? readable ... ?

neither ... yes

Great name!

As someone who writes Erlang for a living, I highly recommend rust as a well typed alternative to Erlang, that still keeps all of the things that make Erlang great. I do love Erlang, but working on a large codebase can be frustrating when nothing is speced or commented, and even when it is speced it’s usually part of a gradually typed codebase with very non descriptive types.

Could you elaborate on why you find Rust to be an alternative to Erlang? For me at least, most of the draw of Erlang has nothing to do with the language, and everything to do with BEAM/OTP and the surrounding architecture, which (as far as I'm aware) Rust does not provide an alternative to in any shape or form.

So Rust does not include built in abstractions/frameworks for building distributed systems, but I count that as a good thing. OTP can scale well under certain conditions. But it can also require rewriting supervision, servers, and other core pieces of OTP, which is a huge pain. BIFs can be slow or have wonky behavior, NIFs are dangerous but necessary when Erlang is too slow. When a language gives you prebuilt abstractions it can be a really good thing if they're the abstractions you need, and really bad if your requirements don't line up well, or you're coloring outside the lines in terms of scale or design. It can also be painful to introspect the BEAM to collect metrics and understand message queue pressure on a node. I'm so glad I get to work on Erlang rather than many of the other toolkits that are out there for building big distributed backend systems, but if I was going to start over again it were my choice I would choose Rust and build the right abstractions, the right protocols, and have total control over my system to make tailored performance trade-offs, and do it in a type safe environment, or I would use a third party distributed systems library like bifrost if my project was small. When I said all the things that make Erlang great, I mean pattern matching, FP, a focus on safety and reliability, and a really knowledgeable community. I'm kind of over BEAM/OTP at this point, but that's just my opinion, for the projects I'm working on.

Couldn't you use Erlang/OTP for the main parts of the system and for the performance critical parts that Erlang isn't great for (like crunching numbers) you can use something like Rustler to be build a safer NIF? https://github.com/hansihe/rustler

Interesting! I haven't seen this, but it looks really exciting. I may have to bring this up at work!

It sounds like you just don't like BEAM/OTP, then. :) I don't know if I would make a sweeping recommendation for Rust as an alternative to Erlang based on that, though, as I would imagine it would take a TON of work to replicate OTP in Rust.

I guess I'm just looking partly for something different. I've been doing Erlang for a few years now, and it's just the devil I know. :) I think Rust could really take off with more support, but I think Erlang will always be niche. I'd rather see people write more Rust.

Same feeling here. I used to work in Erlang on daily basis - now Elixir. And although I'm not a big fan of its syntax (Erlang looks more readable to me) the tooling and the amount of love from Elixir's community is immense

I've never had a chance to play with Rust yet. I'll definitely give it a shot someday

In my opinion, the best example of how typed languages make it more manageable is Elchemy's codebase itself - which is written in Elm and compile itself. The type system saves us from a huge amount of runtime errors and allows us to sleep at night after a recent release. Most of the time when something goes wrong it's about the parts written in bash or Elixir

I've never had a chance to play with Rust yet. I'll definitely give it a shot someday

The comparison of Rust with Elm and F# in this article really clicked for me:

https://www.chriskrycho.com/2018/exploring-4-languages-start...

I always thought of Rust as similar to Go, but now I think more of it like an ML descendant with C'ish syntax. There's more to it though, Rust is more low-level than languages in the ML family and can often provide the same abstractions without hight costs in performance.

Can you recommend a good web framework/micro-framework?

I was using actix-web, but last I heard it has to many unnecessary `unsafe`s.[0]

[0] https://www.reddit.com/r/rust/comments/8s7gei/unsafe_rust_in...

For a Rust web framework I would recommend rouille.[0] Mature, stable and zero unsafe.

[0] https://github.com/tomaka/rouille

The author is responding and taking care of many of them. I’m confident this is a temporary issue, or at least it seems like it’s going correctly to me.

Oh, cool. Good to know

Rocket is fast and high quality. I’ve gotten impressive latency numbers in my benchmarks. http://rocket.rs/

What about OTP?

It's the first big library that we'll be porting after coming up with a final version of the effects system

Inception.

Reply on news.ycombinator.com