4 ms·
I'm glad Bakeware is applying brainpower to the entry point problem for simple scripts. I'm currently learning Elixir and the biggest initial hurdle was how to
by sergiomattei 5y ago
I'm glad Bakeware is applying brainpower to the entry point problem for simple scripts.
I'm currently learning Elixir and the biggest initial hurdle was how to actually create an application. Most tutorials teach you through iex but rarely how to actually write a running program or library.
Things like "mix run" wouldn't work until I created an app with mix new, then I had to visit the rabbit hole of genservers and supervisors, etc...
It's a little complex for beginners and could use some polishing. I can't say that I truly understand it still.
- dudul 5y agoI remember being a reviewer for an Elixir book where the first chapter was listing the pros and cons of Elixir, and one of the cons was: it's kind of hard to manage deployment of Elixir applications. My feedback was "hum, that's kind of a turn off for someone trying to learn the language/tech no?" I think the community has been looking for something for a while now and is iterating (too?) quickly. There was erlang releases, there was distillery, now it's elixir releases. There are different ways of configuring in production. It goes a little too fast to keep up with to be honest.
- dnautics 5y agotoo fast? I was using Elixir releases two jobs ago.
- 1_player 5y agoIt took me 1 hour to convert a production app from Distillery to native releases when Elixir 1.9 released 2 years ago. And deployment in 2021, whatever the language, is best served with containers. Elixir is not harder to deploy than a Django or Node app. In fact, releases and post-deploy ops are pretty well documented: https://hexdocs.pm/mix/Mix.Tasks.Release.html https://hexdocs.pm/mix/Mix.Tasks.Release.html Phoenix also has an example multi-stage Dockerfile which is fine for 99% use cases: https://hexdocs.pm/phoenix/releases.html https://hexdocs.pm/phoenix/releases.html
- dnautics 5y ago> And deployment in 2021, whatever the language, is best served with containers. ...in 2020 I deployed to bare metal servers. Mix released a gzip to S3 and pulled the artifact down, systemctl restart dnautics_service. You're making me feel like some sort of dinosaur.
- bfbelmont 5y agoBare Metal / Containers / VM It's all about managing your dependency chain, and how much variation of environment you're willing to accept. You don't need to feel like a dinosaur if what you're doing is principled and reasonable. There's no one size fits all.
- dnautics 5y agoHaha we bought these servers for 5k, very op, but since we had a rack full of HW (that this one blade was managing) anyways, the server price/power consumption for a 1U was a drop in the bucket. Very strange world. I think the server was at 10% CPU consumption, and we didn't bother doing the erlang "turn off IO polling for modern cloud operating systems" option.
- deleted 5y ago[deleted]
- aparks517 5y agoDon't let the kids get you down. My deployment scripts look something like this: rsync --rsync-path=/usr/bin/openrsync -r --delete config lib mix.exs mix.lock priv server:my_project ssh server "tmux respawn-window -t my_project:1 -k" It's only weird if it doesn't work, right?
- daniellarusso 5y agoI also use tmux as part of my deploy process. ;)
- deleted 5y ago
- pmontra 5y agoIt's going fast because the original ways were (euphemism) sub optimal. Example: compiling configuration into a release was clearly wrong based on my experience with other languages. A small mistake and another run through CI/CD with production down vs edit a configuration file and restart? Ouch. Maybe inevitable with a lot of servers but very wrong for a single server application.