Ask HN: Who is not betting on Elixir and why not?

69 点作者 techiferous将近 8 年前

It's easy to find people talking about why they took the gamble to switch to Elixir. I'm interested in those who have tried out Elixir in production (or a serious prototype, not just dabbling) and then decided not to use it. Why not?

19 条评论

bjz_将近 8 年前

I'm a bit biased in my development perspective and a bit jaded with the state of back-end development, but here goes:I've done a decent amount of Elixir in prod over the last year and a bit and I've found the lack of a decent, modern static type system pretty frustrating. I love the idea of failing fast, but most of the time we're throwing 500s from trivial developer mistakes (and yes, we do TDD). Lazily evaluated libraries like Streams or Ecto.Multi explode in weird, non-local ways because the types are not checked at the call-site, making refactoring and iterating a chore.I have tried out Dialyzer, but it lacks many things you would expect from a modern type system (eg. parametric polymorphism). While experimenting with it I've been able to get it to accept trivially broken programs without complaint, which means I've never been really be sure it's got my back, so have given up on it. And yes, this is with the flags ratcheted to their highest settings. Not to mention all the third party libraries who forget to keep their typespecs up to date.I realise designing a type system that can handle hot-reloading in a cluster is still an open problem (interesting work in progress on this front though), but most folks aren't really at the scale where that is a problem. They'd probably be far better served using a more traditional deployment process while getting the immediate benefits of the improved iteration speed, refactoring confidence, and data modelling that languages with modern type systems provide. The front end is beginning to 'get it' with the likes of Typescript, Flow, Elm, Reason, Purescript, etc, and I can only hope that their good work and excitement will eventually flow back to us on the back-end...

评论 #14939658 未加载

评论 #14937601 未加载

评论 #14936242 未加载

tatersolid将近 8 年前

Coming from the banking industry, nobody looks at using unproven languages or frameworks unsupported by a large community or major vendor. If you "guess wrong" on a language you're looking at a multi-million dollar rewrite down the road which is an unacceptable risk. It's also very difficult to find staff or contractors who are familiar with new or unpopular tech. Basically any industry that deals with "real money" or "life and death" intentionally does not follow developer fads.

评论 #14935682 未加载

评论 #14935687 未加载

评论 #14935622 未加载

评论 #14935655 未加载

评论 #14941061 未加载

评论 #14935639 未加载

whitepoplar将近 8 年前

I love elixir, but it's just a language. There are other great languages, too. Use what fits your brain. Don't listen to what others carry on about. The only downside I can see for me is that there are fewer, less battle-tested libraries available as compared to, say, ruby. The most unexpected benefit of getting into elixir has been the community--it's a positive place to be, and I feel it has made me a better, more confident programmer. <3

评论 #14941044 未加载

atombender将近 8 年前

As someone who spent a long time in Ruby land, the last thing I want right now is another dynamically typed language.I'm a big fan of Erlang and OTP, and really wish for that style of concurrency, failure tolerance and distributed computing. For me, the lack of static typing in Elixir struck me as a missed opportunity from the outset. The Ruby-like syntax isn't enough to change the game for me (I find it significantly less attractive than Ruby, but that's not important), even with macros.Since I don't use Elixir, the above isn't necessarily a criticism of it -- I'm sure it's great. Just not for me.Go is what I'm using now, and I've been playing with Rust and will probably start using that when I have a new project. I've been using Haskell for some side projects. I like OCaml a lot, but I won't touch it until multicore support lands and matures. For web projects, my plan is to transition everything from JavaScript to TypeScript, precisely for the type system.No more dynamically types languages except for scripting.

jesses将近 8 年前

Deployment is by far the biggest pain point I've seen in new Elixir developers. Developers use Mix in development, but then build releases using Distillery for production. There are a few gotchas and pitfalls that almost everyone falls into when using Distillery like using `System.get_env` and forgetting `server: true` in their `prod.exs`. Hot upgrades can also be a source of a lot of confusion. Configuring distributed clustering in production can be tricky especially if you're running on Docker/Kubernetes/etc.That said, I built <a href="https://gigalixir.com" rel="nofollow">https://gigalixir.com</a> to try and help with some of these issues and improve the deployment story for Elixir.

Sailias将近 8 年前

We are using Elixir in production for a site with traffic that can spike in a short period of time.Elixir has helped us reduce our costs by 1/3 and improve our API response times from 50ms to 5ms. (Ruby -> Elixir)Using erlang/Elixir processes forced us to reevaluate the way we handle state and were able to find many ways to optimize.I believe our code is now more organized, extensible and powerful. Our infrastructure is also more complicated, but much more fault tolerant as we have fallbacks for fetching data etc.Deployment was pretty terrible but a simple scaleable solution with AWS is build with a docker container, push to ECS and launch ECS + ElasticBeanstalk and you're good to go.

hawkice将近 8 年前

All my new server-side code is in Go (where all my old code was in Elixir) because I wanted something I could build locally and deploy easier. The deployment story for elixir is... substantially worse than ideal, for, seemingly, no reason at all. At the time I was writing the deployment scripts, not only was the hot-code-replacement not going to work, even AOT compiling to .beam files was broken, with multiple 3rd party tools not helping.

评论 #14935686 未加载

aczerepinski将近 8 年前

We wrote a few small services in Elixir at work and I loved it. I had been using it at home and reading all the books, and would have been happy to commit 100%.However, I don't think anyone else was getting excited about Elixir, or more broadly about functional programming. When it came time to choose a stack for a much bigger project, Go won out. The only specific complaint about Elixir I'm aware of is that ramp up time would be too long every time we bring a new dev onto the project. In hindsight I don't think Go is any different in that regard. A Ruby/JS dev either needs to learn pattern matching, macros, list comprehensions, and a bit of OTP for Elixir, or they need to learn static typing, pointers, goroutines, and idiomatic error handling for Go.Personally, I'm happy either way. I'd still probably choose Elixir if it were my choice to make, but I'm loving Go too.

tmorton将近 8 年前

I'm pretty strongly on the Elixir train, but here's where I see its greatest weakness:On many platforms, the best practice is to have stateless application servers, with separate stateful data stores. On the other hand, the big advantages of Erlang/Elixir are in managing state along with your application logic.In a vacuum, that can be a big win. But I'm worried that the advantages are not enough to overcome the weight of tooling, services, and best practices built around the stateless model. For example, Heroku explicitly tells you to avoid application state, and Docker is built around a destroy-and-rebuild ethos.For my project, Elixir/Phoenix is great as a "better Rails", but I know I'm only scratching the surface of the platform's strengths.

评论 #14935906 未加载

albertgoeswoof将近 8 年前

99% of software developers haven't heard of elixir

评论 #14935953 未加载

评论 #14935577 未加载

thesmallestcat将近 8 年前

Erlang and Elixir are both fine languages, but the BEAM is slow and not suitable for anything computationally intensive. Extending your program whether via NIFs or Ports is a PITA. It's great for anything requiring many active connections like front controllers and P2P, but outside of that you're better off with Clojure if you want an FP with immutability IMO. I think that you need to be working on a niche concurrency-focused application, or have engineering manpower to burn, to justify using a different language for such a narrow case. Erlang library support still is not very good except for, again, concurrency-focused ones (gproc for instance).

Rjevski将近 8 年前

Personally I am a happy Python developer and I don't feel it's worth it for me (in terms of time) to learn another language. Maybe once Python starts to be obsolete I'll switch but in the meantime I can't afford spending time learning something new just for the sake of it.

评论 #14935729 未加载

评论 #14935780 未加载

评论 #14935770 未加载

评论 #14935731 未加载

评论 #14935808 未加载

swat535将近 8 年前

I think this a great discussion topic. I am really glad that everyone loves elixir on HN but I would like to hear both sides to analyze the weakness and strong points of a given technology. This makes more a balanced discussion instead of just praising a language. Honestly I would personally enjoy a more technical scrutiny of a language / framework, especially from a technical site like this one. Does anyone have a good write up on something like this for Elixir?

andrenth将近 8 年前

Personally I'm waiting for Alpaca :)<a href="https://github.com/alpaca-lang/alpaca" rel="nofollow">https://github.com/alpaca-lang/alpaca</a>

becga将近 8 年前

The deployment can be difficult to automate especially if you are attempting to inject application properties at runtime.There are solutions out there,though documentation may not cover every use-case, especially if you are deploying to something like AWS or GCP (Not everyone can adopt Docker just yet).The Hot-Upgrade is a great idea though you will have to do your research to integrate this with your Cloud Provider.Overall I'm betting adoption will be niche, and primarily via Teams coming from Rails. Until a major cloud provider starts offering native support + the community grows to a sizable percentage, it will be slow to catch on.

user5994461将近 8 年前

Don't use. You're gonna be in big troubles to recruit developers who knows that tech.It's already an issue with Erlang. It's made 10 times worse with Elixir.

评论 #14935947 未加载

评论 #14935757 未加载

评论 #14935724 未加载

maxxxxx将近 8 年前

After reading the second paragraph the headline should be rephrased "Who has tried Elixir and then decided not to use it and why not?"

qaq将近 8 年前

Lack of comments can be interpreted in positive light for Elixir I guess :).

评论 #14935623 未加载

评论 #14935665 未加载

评论 #14935702 未加载

DeepRote将近 8 年前

Elixir is just an AST transform for erlang/otp. I like erlang and there are features that I wish it had sometimes, but elixir couldn't be further from what I'd come up with if I decided to fix it myself. It takes all the bad parts of lisp, shoves them into a bad ast format, and crunches it all down to beam code. It's just a terrible implementation of a terrible idea.I am actually moving components of my apps away from erlang to f# to shield it from the destruction of beam that elixir will bring about.2/10

评论 #14935630 未加载