New Elixir 1.12 – The developer’s point of view | Hacker News Reader

New Elixir 1.12 – The developer’s point of view

bartoszgorka.com

197 pointsclessg25 comments

The Elixir core team has been knocking it out of the park recently with features that developers actually care about, especially the developer experience like the IEx shell and error reporting. These things might not impact existing projects much per se, but this is a huge deal when new developers are learning the language and the ecosystem.

I've been pretty interested in programming language research and development. Elixir is a neat case: it's extremely practical, but it makes use of some less-than-mainstream features quite prominently. (Extensive pattern matching and full-blown AST-based macros come to mind immediately.)

Is there anyone doing research on these kinds of ancillary features? Like, what makes a language worth using? What kinds of tools are most important for developers to have? Just curious.

Wouldn't those things depend heavily on what is being developed?

For many things I’m sure. But I bet there are some general good principles.

Mix.install is super great for me. Personally I vastly prefer Elixir to Python for basic personal scripting stuff so being able to pull in dependencies in a single file is nice. Before I'd been using escript to turn mix projects into a single executable which is pretty inefficient

Is there a wrapper for the interactive `iex` shell with bells and whistles (colors, better autocomplete, etc.) like `ptpython` for `python`?

The autocomplete has gotten pretty good, and I suspect the new Mix.install stuff should make it better. You also can colorize it to your liking[1].

[1] https://stackoverflow.com/a/37911985/1521117

You can configure things directly with an `.iex.exs` file and the IEx.configure/1 function.

https://hexdocs.pm/iex/IEx.html#configure/1

One of the cool things you can do with `Mix.install` is enable the use of Hex packages in Livebook [0]. I’m excited to use this to start writing some rich documentation for our Phoenix app at work, as well as for some other projects I’m working on.

[0] https://github.com/elixir-nx/livebook

I'm a huge fan of Erlang and Elixir, but everytime I need to write a cross platform command line tool, I always have to look at Go or Rust. Is building release better now with Elixir? Can I run `mix release` and get a single binary file that I can run on any platform?

To my knowledge, unlike Golang, `mix release` doesn't let you compile for any OS + architecture from any OS + architecture.

Yep, you have to build for the architecture you're planning to deploy on.

BEAM code should be portable but the runtime is not.

There’s a couple of approaches to this problem under development:

1. Bakeware “bakes” your application together with the entire Erlang/OTP/Beam/Elixir stack into a single binary. Given the “batteries included” philosophy of OTP, these binaries end up being fairly large, but it works: https://github.com/bake-bake-bake/bakeware

2. Lumen compiles Elixir, Erlang and friends into WASM. This will in time enable small fast cross-platform static binaries, but it is not done yet: https://getlumen.org/

Last time I checked on Elixir, it seemed like people used Phoenix to pretty much do anything useful with it. Is that still the case?

Knowing the number of people doing IoT stuff with nerves, i highly doubt it is still the case.

I'm hoping Nx gains a good bit of traction in the ML space, too.

Several fintech companies use it to power core logic, with or without phoenix, so it's used for general purpose computing where speed, resiliency, and parallel execution are important. I've seen hints that people are using it to run crypto trading bots, but idk how common that really is.

I think a few companies use Elixir to power their web crawling/scraping tools. This makes intuitive sense as a good candidate for the process supervisor and parallel work architecture OTP encourages.

Nerves (embeddable Elixir) has come a long way. I switched to Nerves for some Raspberry Pi projects and the amount of time I waste dealing with hardware/config has gone to nearly zero. I am a hardware novice and was able to setup flashing firmware over-the-air updates to the Pi with very little effort. I'm sure the companies that use Nerves in production have more to say about it.

I'm not very tuned into the updates to Scenic, a project for display/UI on embedded screens, but it looks like they've hit some big release/stability milestones.

Phoenix is the way to go for web interfaces, and is an excellent toolset, so alternatives haven't been demanded. For more lightweight http people usually reach for Plug, a key building block of Phoenix, if you won't need the full bird.

> I think a few companies use Elixir to power their web crawling/scraping tools.

What do they use for headless browser scraping? I tried Hound a few months ago, but it seems too geared towards testing to be used more generically. We ended up just using Oclif and Puppeteer for scraping via NodeJS.

Might fall into the same category as Hound but Wallaby exists and works.

Otherwise have you heard of Crawley?

I heard of Crawley and thought it only did HTTP-based crawling, but now I see it has a browser rendering option via Splash[0] that looks like it'd fit the bill. Thanks!

(Also had issues configuring Wallaby to be used outside of testing)

[0] https://splash.readthedocs.io/en/stable/api.html

> if you won't need the full bird.

Never heard this phrase before, but I like it.

I guess it depends on your definition of useful. I've been using it since 1.4 to do things like:

- PBX configuration (e.g. dialplan and routing)

- email monitoring (e.g. monitor multiple email accounts and multiple folders on those accounts)

- interacting with API's (e.g. creating a supervision tree that has multiple API accounts making requests)

- processing huge CSV files in chunks and storing them in a database

Of course you can add Phoenix on top of these to make them more useful.

I’m writing a gameserver in it using Elixir without Phoenix. I’m using cowboy (erlang webserver) for websockets and redis for persistence.

You can pretty easily opt-in on specific phoenix libraries one by one and pick any you like and omit those you don’t.

The “phoenix app” type stuff is just a convention over configuration thing, but unlike something like Rails, it’s perfectly doable to pick and choose the libraries you want and install these later when you need them, or remove them when you don’t.

The functional approach to Phoenix makes it really easy to substitute things without breaking other things.

You don't have to use phoenix at all for most things, but if you're speaking HTTP, you may as well.

Reply on news.ycombinator.com