Hacker News Reader

Couldn’t agree more. Learning Elixir completely changed the way I think about programming problems.

The downside is that it raises your awareness of deficiencies in other languages that you never really noticed before.

I would really like to try Elixir or Erlang, but the learning curve seems steep and I haven't heard much in the way of specifics to justify why it would be a good time investment (just "supervisor trees are the shit!" and "functional languages are great!"). I'm particularly wary of dynamic languages; I program in Python and JavaScript all day, but I use Go and TypeScript in my spare time and find myself both more productive and more confident that my code works as intended. I'm aware that Elixir has some sort of optional typing, but the vibe I get is that few really use it and it's not very practical. I would be really interested to hear someone speak to these concerns.

That’s asking for a very detailed reply, but since you already work with Go let me just share the comparison that I wrote up not too long ago.

https://www.brightball.com/articles/comparing-elixir-and-go

That is just the summary link that includes a link to the original article I wrote for Codeship as well as the big discussion from when it hit HN.

The HN discussion, especially, was great.

You sound like you have similar tastes to mine. If so, I'm guessing Scala.js's slow compiles and heavy output size is an annoyance. Check out BuckleScript/ReasonML. Reason provides a new syntax for OCaml, in a way like what Elixir does for Erlang. Compile times are instant (I'm not exaggerating ... much), type system and inference are powerful (more than Scala), and output is extremely minimalistic ES5.

> I'm guessing Scala.js's slow compiles and heavy output size is an annoyance

Compared to BuckleScript, sure, but that's an extreme outlier, near instantaneous whole project (wtf) compilation times with tiny output is most definitely not the norm.

As a Scala.js user that is also subjected to the Angular/Ionic/Webpack world, the former is very fast, as in, 1-2 seconds incremental compilation, whereas the latter is a lumbering beast, often taking over 10 seconds for "live reload" for even the simplest of changes.

In terms of output size, yes, there is the Scala collections "tax" (@150KB), but thereafter the bang-for-buck factor pays off -- all the power of Scala with minimal increase in bundle size.

Well, sometimes you can't avoid it :-) But since you mentioned live reload, BuckleScript now also has instant live reload via a WebSocket connection to the browser: https://bucklescript.github.io/blog/2018/07/17/release-4-0-0...

>Javascript

I’ve been working in Node for a few years now, on a project that suffers a lot of warts from adopting Node early and not benefitting from the wisdom of the group.

Something I didn’t know about myself as a full stack developer is that I work on UI because I like human factors, and I work on backend because I like solving architectural or data problems and sometimes I’m just tired of writing Javascript.

Trying to homogenize everything at work removes a vey important pressure relief valve, both for individuals and team dynamics.

I figured this out about a year ago and if not for major life events I’d be out there somewhere writing Elixir or Rust or Scala code.

ES6 and beyond has some things worth experiencing so I’m focusing on that as much as I can. Just a few more months and I can pivot outta here.

Have you tried python/ Django?

I haven't used elixir but I my productivity with Django is much bigger than when compared with other solutions like php, node, java/spring, c#.net etc.

I am talking about good ol' traditional web apps, no fancy spa stuff where I can use Django in all its glory: cbvs, forms, admin, auth and the huge package ecosystem.

Give it a try if you haven't, even just the Django tutorial should give you a hint of the productivity enchantment you'll have!

One thing that plagues us about async Python in production is the propensity for a single synchronous call to bring down a server. The problem tends to be difficult to debug since it often manifests itself in timeouts for requests that aren't actually issuing the blocking request, but for which can't be serviced because the event loop is blocked nonetheless. It's also easy to add bugs in async code (e.g., forgetting to 'await' and getting back a promise instead of a response object). Of course, we could stick with sync Python, but that has lots of other problems (namely it's difficult to pack Python server processes onto hosts with passable efficiency).

Elixir and Go just skirt these problems altogether because all I/O is async under the hood (no need for "await" keywords), and both languages support efficient concurrency and parallelism. One process can fully utilize a host.

Of course, this doesn't speak to the quality of available web frameworks, which may or may not matter for your application.

Not a Python dev but I worked a lot with Ruby performance a lot for the past few years.

Do you really need async IO? Even at Google scale[1] it's kinda a waste of time for web/job servers and only required for proxying etc. The overhead of threads is massively overstated [2]

Ruby scales a long way using Puma or Phusion Passenger with one process per core (just like NodeJS) and adding threads until you hit CPU saturation. Python must have something similar?

[1] https://www.slideshare.net/e456/tyma-paulmultithreaded1 [2] https://eli.thegreenplace.net/2018/measuring-context-switchi...

> One thing that plagues us about async Python in production is the propensity for a single synchronous call to bring down a server.

Probably need a better framework. I've never had such a problem come up unless I was trying to be clever and not use an established framework.

You don’t understand the problem you’re criticizing. If you’re using an async web framework like aiohttp and something in the depths of one of your routes does sync IO, it will block your event loop. Nothing clever required.

There isn’t a web framework that I’m aware of which magically makes all sync requests async.

Funny that you insult me and then backup my vague comment with more specifics. My point is that you need to be aware of what is blocking all the way down, all frameworks you are using. It is possible, maybe not magical or trivial, to making everything async.

Please don't assume you know what someone understands. Try asking questions when comments seem vague or stupid like mine did.

> There isn’t a web framework that I’m aware of which magically makes all sync requests async.

Waitress gets part of the way there. IIUC Request/response is done via asyncio but the actual web app part uses a thread so you can't accidentally block the whole thing.

Interesting. I wonder how it manages the threading with the GIL and all that.

Thread per request works because the GIL is released during blocking IO. You only need one process per core and each process runs multiple threads. It saves a massive amount of RAM compared to trying to cram 50 (g)unicorns onto a server.

Of course, I have used Django (and I still do for data-heavy applications). Python and ruby are quite similar syntactically, but very different philosophically. This is beautifully elaborated on this page here: https://rubyonrails.org/doctrine/ and hence my preference for Ruby over Python. Not saying python is bad at all, just that I only have specific use cases I like to use Python for, mostly stuff that needs Pandas.

I've written some rather large python apps with Django and Flask. I'd never voluntarily choose it again over Elixir/Phoenix. (Only if there was heavy numerical processing or something of the sort where a library like Pandas would be necessary.)

Working with Elixir/Phoenix is a far superior experience in nearly every way for web/api IMO.

I made nearly all of my money with Phoenix and Django in 2018 so I'm probably not biased. For projects that can run on a single machine I'd say that Phoenix is slightly better than Django but Rails is much better than both of them. Metrics: ease of development, developer happiness, ease of debugging, ease of deployment, framework coherence (Django is almost not a framework compared to the other two), the ORM, the underlying language.

Phoenix wins on parallel jobs because thanks to Elixir it doesn't need ActiveJobs or Celery. Django doesn't win on anything IMHO, except maybe the ease to create an admin CRUD (but Rails has a gem for that.)

To add another tool I used, even Django would win against server side JavaScript. I'm using that only in special cases and for demos, because so many more people knows it than other languages.

Considering yours and the other answers I'll definitely give elixir a go. This isn't very easy when you are fully productive with a different tool (Django in my case) and you have projects with expected deadlines...

I'm mostly convinced to take the red pill thought! Can you recommend any good elixir/phoenix learning resources?

Now that I mentioned learning resources I think that you should agree that this is a point where Django wins: Its documentation and learning resources!

I learned Elixir and Phoenix on their web sites. Deep links to the starting points.

https://hexdocs.pm/phoenix/overview.html

https://hexdocs.pm/phoenix/Phoenix.html

https://elixir-lang.org/getting-started/introduction.html

https://elixir-lang.org/docs.html

If you buy books, look at https://elixir-lang.org/learning.html

You should probably start with Elixir but you can do as I did with Ruby/Rails, start with the framework and learn the language as you need it. If you do, in the case of Elixir you'll probably be puzzled by all the Supervisor and Gen* stuff based on OTP. Hint: GenServers are more or less objects with their own CPU https://hexdocs.pm/elixir/GenServer.html#content and Supervisors are kind of a systemd internal to the language.

Here is a tutorial that might help you in your first approach to Phoenix (a web framework akin to Rails/Django): https://lobotuerto.com/blog/building-a-json-api-in-elixir-wi...

I have used Ruby, Python and Node. Built Angular and React apps using Typescript, Coffeescript, Babel. I haven't tried Elixir, but I tried Clojure. It took me sometime to learn the ways of Clojure but now I feel nothing can make me more productive. I simply cannot even think about going back to writing imperative/OOP code and working with no REPL. Clojure makes sense to me today, but if for some reason it stops making sense I honestly can't think of an alternative.

> Elixir has drastically improved my productivity, and you get to find errors in compile time, leading to much, much better quality, reliable code.

Interesting, I haven't seen that as a strong point for Elixir.

Granted I'm comparing it to Haskell and Rust which really give you errors in compile time. They aren't very popular for web dev though and compared to the other languages you list I guess I can see where you're coming from.

Relative to Ruby it's a lot better without sacrificing the rapid prototyping. If you need real correctness then Haskell and Rust are in a class of their own, but they'll never be as fast for hacking (although admittedly Rust has a high ceiling). I think the magic of Elixir is the happy middle ground where you get more correctness than a multi-paradigm highly dynamic language like Ruby with minimal overhead, and then you strengthen the operational story with a deeply embedded crash-and-restart tooling from Erlang/OTP encouraging less statefulness and easier recovery by design across the board.

Relative to Ruby it has more upfront checking of some things. In Elixir, calling a function that doesn't exist or with the wrong number of arguments is something that will error out at compile-time; with Ruby, you don't find out until you run the code with the bad call.

I agree, though, that compared to Haskell and Rust it doesn't give you much. Dialyzer is (intentionally) a fail-open checker that doesn't allow expressing generics; I've had a rough time getting it to tell me my code is wrong. Credo is (intentionally) just a style linter. "Just let it crash" isn't useful when you're talking about code that is going to break because of its structural incoherence (a class of errors type-checker are good at catching), and not because of transient errors in external dependencies.

Elixir doesn't do type-checking by default, but you can rather easily get it to enforce that records must specify certain fields on creation. Other things, like setting up the optional typechecker (Dialyzer) and writing type specifications for your code, take a bit more effort but do help find problems.

Im new (1yr or so) to elixir, never really believed in dialyzer, but a few weeks ago I noticed my vscode started dialyzing my code in real time and it's caught several errors that would have been hard to catch, and whatever vscode plugin I'm using makes it hard to not write typespecs.

Dialyzer really gives you what you put into it. It never false-positives (by design), even while working with limited information, so if you're not writing typespecs, there's only so much it can do.

If, though, you make a habit of writing typespecs for everything, and defining domain-specific types rather than relying just on the primitives, it can get you surprisingly far.

It'll never be as powerful as Haskell or Idris, but it's absolutely a tool all Elixir (and Erlang) developers should be using.

Also, if anyone ever wants an easy way to contribute to open-source Elixir, just start running Dialyzer on popular projects. Every warning that pops up will be a bug, and often they'll be easy to fix.

Ah, you're probably using the ElixirLS extension, IIRC it has an auto-setup process for Dialyzer when it first gets installed. After that one-time setup it continuously typechecks open projects.

I think Rust will get there if you look at say Rocket app and compare to say express app it's about the same amount of code and equally readable but with obvious benefits that Rust has.

Rust is a really fantastic language but trivial examples can be misleading. We run a Rust app in production at ChartMogul.

Real life Rust business logic is much, much gnarlier than in a GCed language like JS. You need to manage memory so you need to deal with references and deref, lifetimes, Box, Cell, ARC etc.

For an open source example of what kind of complexity arises in real life check out crates.io: https://github.com/rust-lang/crates.io/blob/363b9e036b2ba5d8...

Wow. Coming from a C++ background, why is it necessary to first dereference, then reference again? That is, `&foo`? And why is triple dereferencing needed? There are some `&foo`. I thought I had read somewhere that Rust does auto-ref/auto-deref...

> why is it necessary to first dereference, then reference again?

This is a conversion; * calls the Deref trait. This is used by smart pointers to return the type inside the smart pointer, so for example, Box<T> is kinda like uniq_ptr<T>. So if foo is a Box<T>, then * foo is a T, and & * foo is a &T. Does that make sense?

> And why is triple dereferencing needed?

This can happen in generic contexts, sometimes, you end up with a &&String, so if foo is one of those, * foo is a &String, * * foo is a String, * * * foo is a str, and & * * * foo is a &str. (HN formatting does not like this, haha)

That's what's happening here.

> I thought I had read somewhere that Rust does auto-ref/auto-deref...

Only for method calls, that is, foo.bar() will attempt to auto ref/deref foo.

It's not really using web framework right ? For many web apps the business logic is pretty much manipulating DB state.

Getting data from the request to the DB requires dealing with all those memory management issues. The Rust compiler is amazingly helpful but the complexity is still there.