I've been working full-time remotely for past 5 years and tried many cities to live in. I feel like it might come down to personal preferences but I noticed a pattern in where I felt the best.
London, Berlin, Chicago, Frankfurt, Bologna and Neapol would definitely take the bottom of my list. They are crowded, expensive and people are absolutely tired of tourists. Not to mention that all of them have some nasty places you wouldn't want to end up in by mistake and get mugged.
The top ones however would be in the order from least to most recommended: Ann Arbour (MI), Bari (IT) and my absolute Italian gem: Macerata. It's a 4k people historic city filled mostly with students. People rarely speak English and it doesn't make it any harder to make friends. Everyone welcomes you with his arms wide open and the city is lively. The food is absolutely amazing but that's Italy for you in general.
As a side note I'm Polish and in my mid twenties, I was born in Kraków so I skipped this city as it'd be hard for me to be objective about it.
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
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
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
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
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
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