3 ms·

Been running our tech stack on Elixir for the last 3 years. I'm the owner of a small e-commerce company where I'm the only tech person (and also the ceo so I ca

Been running our tech stack on Elixir for the last 3 years. I'm the owner of a small e-commerce company where I'm the only tech person (and also the ceo so I can only spend 20% of my time on tech). Why I love it: - The mental model just clicks for me. The syntax is really simple and the semantics are consistent. There is no abstraction. It's all about processing data. - The REPL (IEX) is way more than a REPL. It's "you inside your running program". You can poke around your code, draft it, debug it, right there. You can fire it on prod to understand a bug. Or use LiveBook, think of it like the Elixir version of Jupyter notebooks that can connect to your application. - Real life performance is great, not because of speed but because of concurrency. - The whole developer experience is great. Mix (the build tool, dependency manager, etc.) is simple, awesome. Dependencies are really rarely an issue. - It's rock solid. In 3 years, I never had one downtime. - LiveView is a god send. Not having to switch language for UI work is amazing, performance is great, and it's server side HTML which is amazing for SEO. My website is 99 on lighthouse without any crazy work. - You need heavy computation and performance on some parts? Use rust, via rustler. - You need to scale to multiple servers? It is distributed. Already. Just make sure to not have anti-patterns in your code. - But the real kicker it's in its power due to the OTP platform. I think it's quite complex to grasp how much it's powerful when you haven't experienced it. Need to batch insert statements or rate limit api calls to a 3rd party service who can only accept one call per second per channel? A working simple solution is only 20 lines of code. Need to launch many different workflows running concurrently, keeping their state, recovering when crashing? 100 lines. The exciting developments: - Elixir NX ecosystem (NX, Bumblebee, etc): running and training AI models directly in Elixir, in a distributed way. - Liveview Native and Elixir Desktop: two big initiative to bring Elixir to Desktop and Mobile applications. - Gradual Typesystem. Jose Valim, the creator of Elixir, is working on that right now. I really liked the approach of set-theoretic types and the pragmatism of the approach. Hopefully it will be released in the not too distant future. The "to improve": I have the feeling that the platform (OTP) being the killer app per se of Elixir, the whole marketing of the ecosystem if 100% targeted towards developers. Which is good in many ways. But for the ecosystem to grow I think more initiatives towards business-type applications would be welcome. By example, there is only a few payment gateways libraries existing which is for me a sign of the lack of business audience. Conclusion: Elixir made me a better developer, but most importantly a really productive one.

anoy8888 3y ago
Some dumb questions: for liveview web / liveview native, is it possible to save rendered code offline and every time it connects to server , it will first check a defined version number ,if the version changes , it will update the code. If the the version is the same or if there is no internet connection, it will use stored code. Perhaps Elixi can be used this way for offline apps while maintaining the dynamic server rendering feature
- abrookewood 3y ago
  I don't think that would work - with Liveview the code is on the server and only the rendered HTML (or the dynamic changes) are sent to the client. Based on what you are suggesting, you'd need JS to to the processing or maybe WASM.
- julienmarie 3y ago
  In the context of LiveView Native / Desktop the renderer is in the client. So this part is ok. The tricky part is that Elixir is compiled, and liveview templates are not "files" but functions. From here you have two choices: - You create a set of primitives (blocks), and the layout/arrangement of these primitives is configurable via a config map. - Or you do a hot-code reload: Call an api, check if new code is available, fetch it, compile it (Code.compile_string), load it (:code.load_binary ), swap it for long running processes ( GenServer.code_change callback by example ), and remove old code ( :code.purge ) The first solution is safer. The second solution is a kind of black magic and you would need a way to authenticate de source code before compiling.
sodapopcan 3y ago
This is very inspiring. I'm in a similar situation! I'm also the only tech person for a small ecomm company, I'm just not the owner :) I obviously have lots of questions but biggest one that relates to other convos I had on HN recently: did you use an off-the-shelf ecomm solution or roll your own?
- julienmarie 3y ago
  It started with an off the shelf solution initially, but it didn't scale. I replaced 90% of it with our Elixir solution. The remaining 10% is the one that takes the longer to kill!

anoy8888 3y ago

Some dumb questions: for liveview web / liveview native, is it possible to save rendered code offline and every time it connects to server , it will first check a defined version number ,if the version changes , it will update the code. If the the version is the same or if there is no internet connection, it will use stored code. Perhaps Elixi can be used this way for offline apps while maintaining the dynamic server rendering feature

abrookewood 3y ago
I don't think that would work - with Liveview the code is on the server and only the rendered HTML (or the dynamic changes) are sent to the client. Based on what you are suggesting, you'd need JS to to the processing or maybe WASM.
julienmarie 3y ago
In the context of LiveView Native / Desktop the renderer is in the client. So this part is ok. The tricky part is that Elixir is compiled, and liveview templates are not "files" but functions. From here you have two choices: - You create a set of primitives (blocks), and the layout/arrangement of these primitives is configurable via a config map. - Or you do a hot-code reload: Call an api, check if new code is available, fetch it, compile it (Code.compile_string), load it (:code.load_binary ), swap it for long running processes ( GenServer.code_change callback by example ), and remove old code ( :code.purge ) The first solution is safer. The second solution is a kind of black magic and you would need a way to authenticate de source code before compiling.

sodapopcan 3y ago

This is very inspiring. I'm in a similar situation! I'm also the only tech person for a small ecomm company, I'm just not the owner :) I obviously have lots of questions but biggest one that relates to other convos I had on HN recently: did you use an off-the-shelf ecomm solution or roll your own?

julienmarie 3y ago
It started with an off the shelf solution initially, but it didn't scale. I replaced 90% of it with our Elixir solution. The remaining 10% is the one that takes the longer to kill!