
Why am I interested in Elixir? - muhic
http://underjord.io/why-am-i-interested-in-elixir.html
======
nickjj
I'm currently building a video course hosting platform with Elixir / Phoenix
and all I can really say is this has been the nicest tech stack I've ever used
in 20 years of web development.

IMO it really does feel like you get the best of everything (developer
productivity, developer happiness, great language for creating maintainable
code, OTP and the BEAM bring a lot to the table, it's memory efficient,
tracing code without a ton of experience is very doable, it's fast as balls
and Phoenix channels / LiveView is a great abstraction on websockets). I find
myself fist pumping all over the place as I make progress towards this app
while learning as I go.

I don't think I've liked a technology this much ever and I'm honestly
surprised it's not already more popular than it already is. I've been around
for the release of a lot of major frameworks and technologies (Rails / Django,
Node, Go, etc.). Nothing has impressed me this much. It truly feels like it's
a zero compromise environment to write code in and I hope I can still be using
it in 10+ years.

~~~
oftenwrong
Are there no bad parts?

~~~
Thaxll
\- deployment is terrible like really bad

\- average performance ( like 10x slower than Java even worse for CPU
intensive tasks )

\- dynamic language ( this is the worst part ), working on large code base
means problems ahead

\- lot of features from BEAM / OTP that are not that useful and done better on
modern cloud platforms ( Kubernetes for instance does a lot of similar things
but better and more flexible, apply to any languages ) People like to talk
about hot code update which imo is a terrible idea, you should have a proper
CI/CD pipeline to do that and not rely on dangerous features like that.

\- lack of ecosystem / libraries

\- it's FP, I count that as a personal cons

~~~
innocentoldguy
Regarding Elixir being a dynamic language, I've programmed in Java, C#, and
other strongly typed languages as well as Ruby, Python, Elixir, and other
dynamic languages since the mid 90s. Throughout my entire career, I cannot
think of a single time when I've thought, "It would be so much nicer if this
language was statically typed." It just hasn't ever been an issue for me.

If typing is something you really want to catch at compile time, and pattern-
matching and guards aren't enough for you, you can always define Dialyzer
specs and run Dialyzer during your build process. I'm currently working on an
Elixir codebase that does this, but I've worked on others that don't, and I
haven't seen much of a difference either way. Personally, I think strong
typing is overrated.

~~~
porker
Not to mention that for a decade and more, HN was full of "dynamic languages
are the best! Who needs types! Dynamic FTW!" comments and articles. It wasn't
fully accurate, and neither is the about-face to "Types FTW! Typing is the
best thing ever!".

I have come to enjoy the more self-documenting nature of static typing (in PHP
of all languages). Yesterday I worked on a legacy project with no typing, and
to determine what was passed to an untyped method (with no documentation)
required running the interactive debugger and inspecting what was passed in
different scenarios...

------
anthony_doan
My current side project is in Elixir/Phoenix and it's sweet. Currently on 1.8.

I'm hoping to move to 1.9. The language just fit my ideology better, Jose
Valim just stated that the language is mostly complete. All major planned
features are completed unless something come up. The language isn't bloated,
it's small and sweet, and it doesn't go out of the way to add random
unnecessary features to the core.

I was fullstack since ~2008 and it is becoming pretty hard to be fullstack
when frontend moves too dang fast for me. So the pace of Elixir and Phoenix is
amazing. I know these two technology are relatively new but compare to its
peers it's boring tech; as in it's battle proven and it's not going to
radically change that often (at least not for the sake of hype or reinventing
the wheel).

The community over at elixirforum is nice. There seems to be quite a few
camps. The ones that stands out to me are the web dev and embedded camps.

~~~
TylerE
The important thing to add here is that since it has powerful, hygienic,
macros, there is nothing stopping you (or library writers) from adding new
constructs and abstractions with zero runtime performance hit.

------
enraged_camel
My startup uses Phoenix, along with a Vue front-end. The combo is an
_absolute_ joy to use. The benefit that has had the most business impact for
us so far is developer productivity.

A couple of months ago we met with a prospective client to discuss their use
cases and conduct requirements gathering. They really liked what we showed
them, but the CFO wanted a dashboard that displayed the data in the app in a
specific way. We shook hands, told them we would contact them soon, and parted
ways. It was around 9 AM when we stepped outside the client's office and got
back in our cars.

By 5 PM that evening, we had a stunning, fully functional dashboard built and
deployed to the demo environment. It utilized a few new database tables that
aggregated data, some data processing done by Elixir, passing that data to the
Vue front-end and displaying it using Charts.js and a few other UI libraries.

I sent a quick email to the CFO with the URL. He responded ten minutes later
with, "holy cow, why didn't you show this during our meeting if you had it
already?!" :)

We are meeting with them again later this month, hopefully to sign them on as
a client.

(For reference, I've used Rails and ASP.NET with C# before Elixir, along with
JQuery back in the day, and then a bit of React. Can't speak about other
frameworks and languages.)

~~~
GordonS
FWIW, I feel like I he this kind of productivity with server-side rendered
ASP.NET Core web apps.

Something that is great about .NET is the available tooling - the debuggers in
both Visual Studio and Rider are amazing, and it's difficult to imagine living
without them.

AFAIK, you're relegated to rather primitive "println debugging" with Elixir -
has this been an issue for you in practice?

~~~
OvermindDL1
> AFAIK, you're relegated to rather primitive "println debugging" with Elixir
> - has this been an issue for you in practice?

Not at all. The traditional BEAM way of debugging is the tracing modules. For
little things an `IEx.pry()` is often good enough though.

~~~
GordonS
> _The traditional BEAM way of debugging is the tracing modules_

Excuse my ignorance, but by "tracing modules", do you mean "println
debugging"?

I had a quick look at IEx.pry(), which at a glace I think gives you a repl at
a given breakpoint? It looks like it also requires you to instrument your code
with breakpoints, which TBH feels a bit ugly (but could presumably be solved
with the right IDE)

------
neya
I just finished writing my own in-house static site builder in Elixir. I come
from the Ruby land. If you thought Ruby was awesome, then you would LOVE
Elixir. I was hesitant at first, thinking "not another language.." but once I
gave it a shot, I stopped looking back.

I'm an individual consultant with a very small team. Without Elixir, many
projects that I've finished in weeks would have taken me months. This is a
seriously under-rated language that would make you wonder why didn't you give
it a shot earlier. It's that good.

My static site is now way faster than Jekyll or Middleman. I didn't re-write
it for speed, speed was just a nice side-effect. I wrote it mostly for the
language's flexibility.

With Ruby, which Middleman and Jekyll both use, you need to think in the
traditional OOP way and sooner or later, you will hit the limits of the
language itself. Whereas, with Elixir, everything is taken care of by guards.
This is really one of the nicest codebases I've ever written in a while. This
is in comparison to my earlier codebase which was written in Ruby, and I had
to do all sorts of things like install a library to make the language more
scalable. That was the ugliest hack I've ever done. [1]

Imagine, a Wordpress clone, only it runs on your computer and generates static
files (this was my goal) but, written in less than a month by one person,
working a full time job, with the same fit and finish of Wordpress.

Elixir is amazing.

[1] [https://github.com/aetherknight/recursive-open-
struct](https://github.com/aetherknight/recursive-open-struct)

~~~
js2
> My static site is now way faster than Jekyll or Middleman.

What? You mean the generation step is faster?

~~~
neya
Yes. Correct.

------
c4po
We are building a sales automation app using Elixir and Vue.

Our dev team seem really happy with this tech stack.

Productivity is awesome - we are four months in and already have similar
functionality to a (sort of) competitor that has spent several years on their
dev. This is the first dev project I have experienced where we are ahead of
our planned milestones. Got to find some more features to quickly add!

My original concern was getting hold of developers as Elixir lacks the pure
numbers of people that other server environments enjoy, but this has not been
an issue. If anything we have got more senior devs then we would otherwise be
able to get as they are excited to be able to use Elixir. Oskar in Poland and
Dan in London, hats off, you are awesome!

Not sure if I agree with others that the broader environment is underdeveloped
- yes there may be less versions of the same thing compared to a large
JavaScript framework, but what is there is absolute quality.

Only (small) gripe is that Elixir is not a fast language. At one stage I
thought this was going to be a real issue, but great support from the
community and improved understanding on how to do things the Elixir way (let
it fail!) seems to have resolved this for us.

~~~
nickjj
> Only (small) gripe is that Elixir is not a fast language.

Which is interesting because Elixir isn't well known for being super fast when
it comes to CPU bound tasks, but for a lot of semi-CPU intensive things you'd
end up doing in a web app, it's still very very efficient.

For example I wanted to generate 5,000x 19 random character discount codes and
my first attempt took 730ms to generate the codes while being a complete
newbie to the language and cobbling together Enum.reduce / Enum.random while
concatenating strings. Within an hour of asking if someone had a better way of
doing it, I got multiple solutions from community members that were able to
produce the same results in 25ms while still having very readable code
(arguably more readable than my original implementation), and even one person
came up with a solution to do it in 3ms.

It's almost hard to imagine being in a position in a web app where 3ms would
be considered too slow to generate 5,000 unique discount codes with a custom
character set.

~~~
sprite
Would love to see the 3ms solution. Post a gist if you have it available.

~~~
nickjj
Sure. Here's a gist with 3 versions (original, the 25ms version and the 3ms
version):
[https://gist.github.com/nickjj/99ea84f460f41dae4139d0610ce80...](https://gist.github.com/nickjj/99ea84f460f41dae4139d0610ce8030c)

The reason I didn't use the 3ms version was due to it having too many concepts
that are unknown to me. At the end of the day I would still need to maintain
the code and the 25ms version is a lot easier to change (for me at least).

But, if I had very strict time requirements, I could just drop in the 3ms
version at any time to get the speed boost which I think is reasonable. I only
need to bring in the operational complexity when the demand calls for it.
Otherwise the more human readable version is fast enough for my use case.

~~~
dnautics
I suspect the 3ms version is still hamstrung by the system rng :) I might try
to make it even faster if you don't mind!!

~~~
nickjj
Sure, go nuts. Feel free to ping me on Twitter at @nickjanetakis and / or
reply here if you can improve it.

------
thibaut_barrere
The Elixir ecosystem offers a lot of interesting things. I'd like to underline
those:

\- LiveView (which I use in production & have recommended for upcoming
projects too) is a complete game changer, not because it allows to remove
javascript, but because it removes a boundary (between the client & the
server), making development & maintenance much faster since you only have one
layer, and also making very rich features easier, because you can remain
stateful during the processing (if you have interactive rich UIs with e.g.
file upload & processing then live reporting as you process the file, this
will remind you of desktop programming, in a good way)

\- While the initial setup of apps can be a bit cumbersome to my taste (like
the SwitchTower period of Rails - e.g. you'll need a build server or a Docker
image typically), the mental model of programming is quite simple in a lot of
cases afterwards. I would say that junior developers can be onboarded quite
easily (I'm starting to train some), and maintenance is quite sweet at this
point.

I can warmly encourage you to try Elixir out (a nice way to get started by the
way is to code ExUnit tests to try out the language, see
[https://github.com/thbar/elixir-
playground/blob/master/test/...](https://github.com/thbar/elixir-
playground/blob/master/test/koans_test.exs) as a boilerplate to get started).

~~~
hellofunk
I can't tell what your description of LiveView is suggesting, I will need to
read about it, sounds interesting. Is it like a codebase that is implicitly
split on a back-end and a browser, without the need to write JavaScript?

~~~
cuddlecake
Phoenix LiveView is basically server side rendering in real time.

The user's actions are sent to the Backend via WebSocket, and the Backend
rerenders (parts of) the view and sends them to the user.

~~~
jacobush
But ... why? Sends it back as ... HTML?

~~~
lawik
Not really, the frontend caches the static parts of the template and the
backend only needs to resend the dynamic, changing, parts.

So "Welcome to $mysite, $username." would initially send the full rendering
but if the data changes it would only send "Hacker News,lawik" over the wire.
Somewhat simplified.

This covers it quite well:
[https://www.youtube.com/watch?v=8xJzHq8ru0M](https://www.youtube.com/watch?v=8xJzHq8ru0M)

------
dkulchenko
All the backend code for my current startup is in Elixir (switched from Ruby,
my previous love).

Elixir/Phoenix/Ecto are an absolute joy.

It took a bit to get used to immutability and FP but it feels so "cozy", for
lack of a better word, to know exactly what my code is doing and to not be bit
by obscured mutability and magic anymore.

~~~
GordonS
From your comment I gather you're new to FP. Same here, but with around 20
years of OO experience, I really struggle to understand what idiomatic FP code
should look like - was wondering how you'd coped on that front?

~~~
1_player
I don't have a direct answer to your question, but once I've played with
Elixir a bit a couple years ago on simple projects, the whole FP paradigm
clicked, and now I'm writing Elixir full time and immutability/functional
programming has become second nature. Everything's just a matter of
transforming data from one shape to another.

------
kuzee
Coming from Ruby and Python and a bit of node, Elixir encourages a really
convenient mental model for thinking about small and large parts of your app
in the same way. Net result is fewer bugs created, easier to write tests so
you write more, and easy to debug when they do happen. And because of the
fault tolerance, most production bugs are so transient they're not causing
problems. I've run several small webapps with a few thousand users and the
maintenance is minimal because of how solid the language is.

------
SLIB53
Elixir is great. It's the most fun I've had programming. I wrote Erlang for a
little more than a year, and I grew to like the idea, but found it hard to
work with. Elixir is bringing me back around.

------
wmock
My experience with Elixir has been great but one area of improvement is
debugging. Maybe it's because I'm so used to using something like Chrome's
developer tools, but I wish there was something as easy to use for setting
breakpoints and inspecting the environment. Would love to know how others are
debugging currently!

~~~
kace91
During a recent developer meetup in my country, I went to an elixir workshop
where the host (an independent consultant) confided in us that several of her
main clients had asked her to not reveal that they use elixir - they're
apparently so happy with their choice that they treat it as a competitive
advantage and claim to use a different stack when asked by competitors.

I can't know for sure if she was bluffing, but the idea really was interesting
enough to make me wonder.

Edit: sorry, this was supposed to be a top level comment.

~~~
lawik
I've heard that a few times now, so I'm not sure if its a sort of community
marketing meme or an actual truth. And I'm in the community :P

------
spraak
Has anyone who previously preferred static typing converted (at least for
certain projects) to using Elixir? I won't even put plain Node into production
anymore, TypeScript at the minimum, but otherwise OCaml or Go.

~~~
_asummers
Came from Java. Was an adherent to static typing everything. Dialyzer via
Dialyxir is imperfect but helps you bridge the gap, especially with the error
message improvements available via my Erlex library. You can turn on an
optional Credo rule to require @specs for every public function, and adapt the
rule trivially to require on private functions. Dialyxir is notably imperfect,
but it catches a surprising amount of bugs, especially with some of the
optional flags.

~~~
pavel_lishin
> _Dialyzer via Dialyxir is imperfect_

Imperfect is putting it lightly. I loathe it. Aside from useless errors
("here's what the success typing looks like! Ignore the any()s, and fix it!
But I won't tell you what's _wrong_!"), it doesn't run against tests (which
bit my ass in production last month due to some return values being ignored,
and only actually matched in tests.)

> _especially with the error message improvements available via my Erlex
> library_

My interest is piqued. Does it help unfuck Dialyzer error messages?

~~~
verttii
I agree, Dialyzer is just... horrible. It' hard to find anything good to say
about it, unfortunately. Not that it's a trivial problem to solve, I get that.

~~~
PopeDotNinja
As someone who quite likes dialyzer, it is most certainly not optimized for
user experience :P

------
kureikain
Elixir is a language that I can very productive in day one. Only Ruby+Go
enable me to be productive like that. Lot of people get turn down by so many
thing in Elixir like OTP and other cool stuff that you never used and think
it's complex.

I literally learn it on the job.

Lack of typing is the biggest issue for me, but pattern matching enable to get
the shape of object and to a certain extent and I'm quite sasitify with it.

------
colinramsay
Where are people getting their documentation for Phoenix? The stuff on the
website is awful for grasping the bigger picture and how the parts of Phoenix
combine. It gave me the impression of being an immature version of Rails when
I tried it recently which doesn’t gel with the attitude people seem to have of
it.

~~~
lawik
I would say Phoenix doesn't attempt to be quite as magical as Rails and
Django-style frameworks. It is a bit more explicit and as such hopefully
easier to follow. The goal doesn't seem to be Rails for Elixir but rather that
every new backend language needs a good web framework or it may be dead in the
water.

As someone suggested, check out the Hex docs. That is where you get the better
in-depth stuff and API reference. I've found the Getting started-stuff very
helpful but also a bit limited in scope.

~~~
mercer
I've found that it really helps to start with the high-level overview of
Phoenix if you don't have experience with 'Railsy' frameworks.

Then look at the 'magic' bits. <app_name>_web.ex is an important one, and the
view/template distinction can be a bit confusing at first.

From there I suppose endpoint.ex covers pretty much all the rest of it (and
then hands things off to router.ex).

With Rails I was always uncomfortable that I couldn't quite follow or
understand the path taken through my codebase, but with the exception of a few
'magic' things, Phoenix is wonderfully transparent in this regard.

------
prodiguy89
I'm currently working on my side project the backend for which I've chosen
elixir to go with. Looking at performance and long term maintainability, it
doesn't seem to be a sucker like rails.

No magic, no hacky patterns. No mess like the one you see with Node. For what
it does the platform is hella stable. I drifted towards Go for a little bit
but man, code in Go felt too verbose with weird patterns. Go is a solid
platform as well. But it's not just my cup of tea for web apps right now.

Scalability is in reach if you need it. Hell, even if you need ridiculous
background job processing power, use OTP already. And I forgot, liveView is
also rock solid. Honestly, if anyone would ask me what the best platform for
web apps right now is, I'd just say Phoenix/Elixir.

~~~
AlchemistCamp
I really, really enjoyed Rails when I discovered it and I still like it for
some quick prototypes. Since finding Elixir, I haven't ever wanted to maintain
a Rails app again, though.

The immutability and the lack of magic you mention are probably the two main
reasons Elixir projects are easier to jump into. Even when macros are
involved, you can still scroll to the top of the file, look at line with "use"
or "using" in it and know exactly what is affecting your module.

With a lot of other languages, it's completely unknowable from inside one file
to know where or if external metaprogramming is affecting your module.

------
philsnow
The most interesting part of Nerves for me isn't rpi/embedded/resource-limited
environments, but rather the ability to remove most/all of the security
surface area of the userspace (say, in the cloud).

~~~
lawik
Oh yeah, that is an interesting thought. I've considered that too. Didn't
cover it in the post because it isn't quite the focus of Nerves and I already
had a lot to say.

I've seen a few different nerves-systems targeting AWS EC2. Have you tried
doing anything in particular with it?

------
anm89
I will definitely be aiming to make my next career move to somewhere where I
can be using as much elixir as possible.

------
SteveMorin
Great language and importing other technologies though NiF to integrate c and
rust (wrapping c or not) with Elixir. My old company build many systems on it
and hope another will in the future.

------
xutopia
Elixir has a lot going for it nowadays! My side projects are all using Elixir
in some way nowadays.

------
SMFloris
Elixir is an absolute joy to use. I love to use it whenever I can and coming
from Erlang, boy its a step up!

It's just the Phoenix framework for which the initial setup of the project
generator feels so opinionated. You have no options, no way to make a template
for the generator. Phoenix's LiveView is a great feature and I want to use it.
It's just Phoenix itself that feels off for me, not as straightforward as it
should be. Does anyone else get this feeling?

~~~
narrowtux
You can still make a phoenix project without the generator.

I agree though that phoenix feels almost a little too heavy and opinionated.

------
benmmurphy
coming from erlang elixir is much nicer than that. exunit is miles ahead of
eunit and i feel like that would be enough to convince me to switch.

the with syntax is nice and helps to deal with early exit on errors but still
feels a bit awkward compared to imperative control flow.

like you can do something like this in an imperative language:

    
    
        foo, err = func()
        if err != nil {
          return nil, Err("bad")
        }
        bah, err = func2(foo)
        if err != nil {
          return nil, Err("blah")
        }
        return bah
    

whereas in elixir you have to do something like the following in order to
avoid the nesting of doom:

    
    
        with {ok, foo} <- func() |> Error.or({:error, "bad"}),
             {ok, bah} <- func2(foo) |> Error.or({:error, "blah"}), do
          bah
        end
    

like the with blocks kind of work until you have to transform the errors you
receive then you need helper functions. if you are just doing static
transforms like above it is not too bad but it starts to get hairy if you want
to transform based on the returned error or variables in the function. whereas
the imperative style you can inline your error handling logic nicely into the
function.

for example what if i want to log something on the error path that includes
some contextual information and custom formatting. probably, the easiest way
is going to be to use with() and pipe to a custom function that triggers on
the error path to do the logging because the code is going to start getting
really messy. whereas if i was writing it imperatively i could just inline the
logging statement most of the time because it is just a few lines of code.

    
    
        foo, err = func()
        if err != nil {
          return nil, Err("bad")
        }
        bah, err = func2(foo)
        if err != nil {
          Logger.error("err: " + err + " when processing: " + foo.name)
          return nil, Err("blah")
        }
        return bah
    

like i feel this is a bit messy but maybe it is actually not that bad:

    
    
        with {ok, foo} <- func() |> Error.or({:error, "bad"}),
             {ok, bah} <- func2(foo) |> Error.or_else(fn err ->
               Logger.error("err: " <> err <> " when processing: " <> foo.name)
               {:error, "blah"} 
             end), do
          bah
        end

~~~
pmontra
The idiomatic way to do that is to match errors in the else branch of the with
statement.

I've been using Elixir and Phoenix for a customer for a couple of years. It's
ok to great, especially when spawning jobs, with some stains.

I'm not a great fan of the with syntax. I wish they implemented it as a native
statement of the language instead of as a macro. In that way they probably
could let us write the same code inside and outside a with, instead of having
to transform = into <\- and add a comma.

But the worst offenders are GenServers. They should really have the syntax of
OO classes instead of the incomprehensible handle* functions. After all that's
what they are, objects with their own CPU. (Remember Armstrong about Erlang
being the only true OO language?)

By the way, that would make it easier to code, to understand and to migrate
people from imperative languages.

~~~
sb8244
I think one of the big points about being a true OO language is that the only
way to talk to a process is via message passing. To me, the handle concept
makes sense when you consider that it's handling a message in its mailbox.

~~~
pmontra
Yes, I see that but it's an unnecessary complication. All I want to do client
side is calling Module.func() and GenServer side I wish I could only def
func() instead of all those incantations.

Furthermore GenServers mix client side and server side code in the same
module. It's very confusing even after years. It's one of the most unpleasant
coding experience of the decade for me.

On the other side I'd steal Elixir's pattern matching implementation and add
it to every language. It's everywhere in Elixir and IMHO it's its strongest
point.

~~~
mercer
I think Dave Thomas has a bunch of comments on the elixir forums, and perhaps
blog articles and videos too that express a similar problem with GenServers.
might be interesting to look those up.

IIRC, one approach he encourages is to at the very least keep most of your
logic in a separate module rather than have just a GenServer module that
contains a bunch of regular functions and a bunch of handle_<x> functions
(which is kind of idiomatic, or at least what I've always been taught).

That said, it's been a while since I followed this discussion so I'd be happy
to be corrected.

EDIT: calling a 'public' function in a GenServer and having a handle_<x>
function actually deal with it does seem to have an explicitness about it that
I think I like. Learning about processes and how they work, I imagine I
might've gotten confused if a seemingly normal functional call somehow
magically handed things off to a different process.

------
allanmacgregor
Great write up, Elixir definitively deserves all the attention is getting and
likely more. I recently helped my team so solve a huge blocker on a project,
we had to create a few proxies to handle large amounts of data.

With very little effort or development time we where able to put together a
highly scalable solution that is robust and very low maintenance.

------
aloukissas
Spot on! I recently wrote a blog how we've been super happy with
elixir/phoenix at AgentRisk: [https://blog.agentrisk.com/how-having-a-non-
typical-tech-sta...](https://blog.agentrisk.com/how-having-a-non-typical-tech-
stack-actually-helped-us-get-better-candidates-77d12a7796d4)

------
etxm
Big fan of elixir, FP was something to get used to, but feels so much easier
to reason about now that I’m used to it.

------
Fishysoup
What are its promising uses outside of web development? From the little I've
seen it looks like a beautiful functional programming language, but I'm not
even tangentially involved in web development.

~~~
brentjanderson
* Hardware, from arduino and raspberry pi to embedded chips ([https://nerves-project.org/](https://nerves-project.org/)) * Multimedia streaming ([https://www.membraneframework.org/](https://www.membraneframework.org/)) * Financial services backend (divvy) * IoT ([http://farm.bot](http://farm.bot))

The erlang Vm’s roots go back to telephony switches, so there are many cases
beyond web.

------
ggregoire
People preferring static typing, what's your opinion about Elixir? Do big
projects become difficult to reason about and maintain like with Python and
friends?

------
trevor-e
Is it possible for someone to create a statically typed language that works on
OTP/BEAM, or for an existing language to interface with them somehow?

I tried learning Elixir a while back and just couldn't get myself to like the
syntax/ergonomics. It seems like most of the benefits people list for Elixir
are actually attributed to BEAM, not the language itself.

~~~
alskdj21
You could look into Gleam [1] and Alpaca [2].

[1] [https://gleam.run](https://gleam.run)

[2] [https://github.com/alpaca-lang/alpaca](https://github.com/alpaca-
lang/alpaca)

------
_pmf_
I really, really wish Elixir/OTP/BEAM would take hold in the soft real time /
large embedded space. Such a nice fit.

------
navyad
I am learning Elixir and build small library with it. Looking to integrate the
Phoenix sometime near. I have asked feedback for this project on elixirfourm
or on its slack channel. And people have been nice and helpful.

[https://github.com/navyad/moviematch](https://github.com/navyad/moviematch)

