13 ms·
Onboarding to Elixir
- rpastuszak 5y agoAnyone here with Django and Phoenix experience? Is there any reason to use Django over Phoenix now?
- ttymck 5y agoThe most compelling reason is probably still the open source ecosystem. There's just a relative plethora of django extensions and plugins that Phoenix (and Elixir) lacks.
- toolz 5y agoI hear this all the time, but what exactly does the elixir ecosystem lack? It's older than the python ecosystem (open source release was much later), although not nearly as popular but since elixir can drop-in erlang libraries as easily as "native" elixir libraries (caveats exist) I'm not sure I find this statement to be nearly as correct relative to how often I hear it stated
- cuddlecake 5y agoParent is specifically talking about Django, and I'm not sure if there is anything comparable to Django in the Elixir ecosystem. So, if there is an absolute necessity for time-to-release at all costs, I reckon Django would probably have some advantage over Elixir.
- lawik 5y agoYeah, for some use-cases the Django Admin and everything-spawns-from-the-model approach can go from nothing to CRUD in a ridiculous time. Phoenix is ludicrously quick to get from zero to realtime UI and interesting backend work such as polling, consuming updates, sharing state, collaboration. Having done a bunch of Python I wouldn't discount Django but I would pick Phoenix almost every time at this point. The initial burst of Django doesn't seem like a long-term upside and Elixir/BEAM/Phoenix has a lot of long-term upside in my eyes.
- ttymck 5y agoAnd, by my estimate, Django has been around ~9 years longer than Phoenix. Comparing DjangoPackages[0] and awesome-elixir[1], sure you could say "there's an elixir package for everything", but how battle-tested are they? How well-maintained are they? If someone is trying to decide between Django and Phoenix, I am not sure how likely it is that the individual would have the necessary Elixir/BEAM experience to be confident in dropping-in erlang libraries. [0] https://djangopackages.org/ https://djangopackages.org/ [1] https://github.com/h4cc/awesome-elixir https://github.com/h4cc/awesome-elixir
- cultofmetatron 5y agoif your team already knows python and you don't need realtime websockets as a first class feature, django is probably a better bet. The best language for yoru project is always the oen you can drop preexisting libraries for in a language you already know. That said, I delved into elixir and haven't looked back. My ios engineer is always mentioning how crazy fast it is compared to previous stacks he's worked with.
- rpastuszak 5y agoYeah, I think it's quite interesting in a sense that it tackles a similar problem than say Next + Prisma, but in a more opinionated (convention over configuration) way. Coming from Node, having to mess with WebSockets in Django feels so backwards, although I do appreciate less cognitive load when you're dealing with more traditional, MVC + REST style apps.
- mehphp 5y agoThat's something only you (or your team) can answer. Does one of them help you solve a problem better than the other? If you can't articulate an answer to that, then I would suggest using whichever your team is most productive in.
- rpastuszak 5y agoOf course, 100% agree, but I'm after concrete examples from other teams, because at the moment I belong to only one, which is a limited sample:) and I'm curious. I should've asked what are the cases when one outperforms the other? Or, what are the cases where Django is a better choice than Phoenix (besides talent, available libs, etc...). Or even, better, what are the concrete examples in which one is a better choice--from your own experience? Given my (fairly superficial) experience with both Django and Phoenix I can see a tonne of similarities: convention over configuration, generators/scaffolding, ORM, fairly similar project structure (to some extent). At the same time things such as realtime/WebSockets feel so unnecessarily complex in Django and so much easier to work with in Node, Elx, Go, literally anything else. I feel like Django fits in the niche once occupied by RoR, whilst Phoenix has a stronger overlap (in terms of use cases) with something like Next.js + Prisma.
- mehphp 5y agoJust a nitpick but Django is definitely not convention over configuration, you might be thinking of Rails. > At the same time things such as realtime/WebSockets feel so unnecessarily complex in Django and so much easier to work with in Node, Elx, Go, literally anything else. So this is where Elixir shines. If you need highly scalable real-time applications, then it's no contest. If it's a pretty straightforward crud app then it's really going to come down to preference. > Or even, better, what are the concrete examples in which one is a better choice--from your own experience? I personally chose Phoenix because of liveview. It removed the need for me to maintain what feels like two separate apps when you have a back-end and then a front-end in React/Vue/whatever.
- deleted 5y ago[deleted]
- pantulis 5y agoYou could say the same for Ruby and Rails, to be honest.
- rkangel 5y ago[disclaimer - am an Elixir and Phoenix developer, and a Python developer, but only a little bit a Django developer] Django still has a bit more stuff out of the box or from the community. There are various pieces that you can use from scratch. For a lower complexity, simple web app if your team hasn't built their "usual needed bits" Django is probably going to give you more. Elixir/Phoenix is a much better platform that is going to help you more once you're out of the initial bring-up. E.g. they provide authentication templates but explicitly don't just hand you auth because they philosophically believe that it's too integrated with your app that "one size fits all" can ever work (I agree with this). Once you need to do backend work, it's just more Elixir rather than Unicorn etc.
- bcrosby95 5y agoI've never created a consumer facing webapp in Django, but because of the automatic admin stuff I love to use it for quick internal webapps where the prettiness of the UI doesn't really matter.
- sergiomattei 5y agoDjangonaut learning Phoenix ATM here. My initial thoughts... - way less out of the box. you’ll have to spend sometime getting a boilerplate up and running, especially if you’re making APIs, as with solutions like pow aren’t the best for that use case - having your tests run instantly and webpack or node running on the same process is just life changing - there is no equivalent of something like Django REST framework for Phoenix, which is annoying, but writing Phoenix is quite productive so it’s all pretty trivial - ecto has a huge learning curve if you’re coming from the Django ORM - you will miss the admin panel, and solutions out there are really janky. stuff like Kaffy, ExAdmin... they’re awful. - documentation is really low tier compared to Django, especially when it comes to Phoenix. I was spoiled by how good the Django docs are and with Phoenix it’s been mostly digging through old forum threads for basic stuff. Docs assume a lot of prior knowledge about the elixir ecosystem, making it hard for beginners, unlike rails and Django. Their docs need a lot of work. - community can be a little elitist or idealistic. Try asking how to get JWT auth running on elixir forums, watch it get shot down in minutes because “jwt is insecure”. they can be very friendly but also very unhelpful, sometimes lacking pragmatism - unmaintained packages left and right - being able to send email asynchronously or do websocket stuff without worrying about memory leaks is just glorious. doing that in Django channels, deploying to production was just a cycle of crossing my fingers worrying that the slightest bug would take down the entire runtime. python async absolutely sucks garbage I can’t understate that last point. I’ve deployed multiple socket apps with Channels to production, and it’s always been a major pain in the ass on the long run. I spent months debugging a memory leak in Django Channels that only happened in production. Turns out an external package, sentry-python, wasn’t playing nice with ASGI. Async Django is painful and slow. I wouldn’t wish it on anyone. I have more thoughts written down somewhere, but this is off the top of my head. All in all: it’s been interesting, very fun. There’s tradeoffs to make, especially in productivity and documentation, but I feel they’re all worth it. Today’s apps demand speed, real-time, and concurrency. Django just feels stuck in a time warp from the last decade and Django channels isn’t progressing fast enough (add that async python is painful). Maintainability and reliability is important for me as a solo maker. I want a resilient web app that can operate without babysitting, I'm a full time student. Performance matters to me as well. I can't have a memory leak taking down my runtime every hour, or a slow request causing midnight support emails. Elixir is just pleasantly fast at everything: unit tests are async, the server is concurrent, everything is just blazing.. Realtime is important for me because you don't always need it, but when you do, it's nice to have it. Knowing that Phoenix has a rock solid implementation makes me use it more. It helps me effortlessly make next-gen products. Elixir and Phoenix come with performance/reliability guarantees, maintainability and new capabilities like flawless real-time that make it all worth it for me. This is my next upgrade to my stack and I’m really happy with it so far.
- bsaul 5y agoI've always had a hard time understanding the benefits of supervision trees in today's world. Either the thing you're scaling / respawning is stateless, and then anything from kubernetes to amazon ecs will do. or it's stateful with a state that you need to persist somehow, and then frankly the hardest part clearly isn't the way web server scale, but rather how the data storage and retrieval mechanism works (along with handling the potential transactionnal behavior requirements). What am i missing ?
- blacktriangle 5y agoIf the choice is between having my language solve a problem or having to reach for Kubernetes, then I'll take the language solution every time. I'd happily program in Brainfuck if that's what it took to avoid Kube.
- pantulis 5y agoBut then it's the runtime what is solving the problem for you, not exactly the language.
- rapsey 5y agoErlang is completely tied to its runtime. Making a distinction is not really important. The point is Erlang gives you the best parts of much more complex solutions in a simple easy to use package.
- pantulis 5y agoAgreed, it's kind of a pedantic/moot observation.
- hyperhopper 5y agoThats even better! That way, you get to program with much saner assumptions in a more pleasant environment, rather than having to write code to smooth that over manually, or deal with configuration and operational hell to make it work at a deployment level.
- EzraM 5y agoClear and thoughtful introduction to how developers with different levels of experience onboard to Elixir projects of varying kinds. Strong evidence for Elixir being nice to use.
- danfritz 5y agoIf only there were jobs in Elixir, god I switched in an instance. Sadly here in Belgium there is not a single company looking for a senior Elixir dev :(. I love that language...
- hauxir 5y agoemail me hauxir[at]gmail.com
- nesarkvechnep 5y agoAre you offering remote positions?
- pierot 5y agoMail me at pieter[at]jackjoe.be
- devoutsalsa 5y agoSoftServ has Elixir devs working remotely. Could be an option => https://www.softserveinc.com/ https://www.softserveinc.com/
- lawik 5y agoIf you need to work in Belgium I can imagine the problem. Though I've dealt with at least 4-5 Elixir companies just in Sweden. If remote is an option there's really no shortage of people looking for experienced devs from what I've seen. Feel free to reach out if you want some options.
- lawik 5y agoI'll extend that to anyone that does want to work with Elixir but finds it hard to find work. Reach out, I can't guarantee a single thing beyond that if I get your message I'll read and respond. But I've put people into Elixir work before and am happy to do it again.
- masijo 5y agoIf you think finding senior jobs is hard, try finding junior or mid-level Elixir jobs... I've been trying for a while (~3 years of exp with Laravel, Django, etc)
- ashton314 5y agoThe local-reasoning properties of Elixir (and any other functional language with emphasis on immutability for that matter) make it soooooo much easier to onboard. Meanwhile over in a Rails/Laravel/node-framework-flavor-of-the-month you can get lost in the monkey patching and mutation. It’s nice to be able to look at a single function and know what it does, without having to reason about what might happen beyond getting a return value if you call another function.
- dgb23 5y agoNavigating those kind of frameworks and libraries is also incredibly frustrating. Where are my data structures? It's all hidden, scattered behind idiosyncratic interfaces that provide little observability.
- ashton314 5y agoExactly! In Elixir, structs are just a special case of a map with a little bit of compile-time field checking magic. At runtime it's all the same. It's so easy to see the shape of things and figure out where stuff came from. Also, `|> IO.inspect(label: "...")` is one of my favorite things ever in getting my head wrapped around a new struct I haven't encountered before.
- dnautics 5y agoif you use vscode, you might like this: https://slickb.it/bits/70 https://slickb.it/bits/70
- bostonvaulter2 5y agoNice snippet! I think that snippets are often underrated by programmers, especially debugging related snippets (the code is temporary so "duplication" doesn't really matter).
- dnautics 5y ago
- fny 5y agoWelcome to the legacy of Rails! Jose Valim contributed heavily to that ecosystem back its heyday. Nearly all of the cultural norms like embracing "convention over configuration" came from Rails. Thankfully, Jose appreciates performance and engineering more too, traits the Rails community was as keen about.
- callamdelaney 5y agoThe rails community were keen about performance? You'd never have guessed.
- acrooks 5y agoI think they meant "wasn't* as keen" - in context the sentence as-is doesn't make sense.
- krainboltgreene 5y agoAt least 3 talks for ever conf were about rails performance. The rails team itself did a lot of work to improve performance. Rails core teams even spent considerable time working on MRI to improve performance. Thousands of libraries devoted to this very topic just for Rails.
- fny 5y agoI don't deny this, but it's all been an after thought whereas with Erlang/Elixir its been part of the focus from day 1.
- krainboltgreene 5y agoWhat in the world is an "afterthought" for something that continually improves? I mean, you're not even right.
- fny 5y agoTypo sorry. They were definitely NOT.
- merlinHe4rt 5y agoAs a beginner in programming i can say, learn elixir is the most enjoyable experience i ever had.
- likecarter 5y agoI love elixir. But the thing that keeps me coming back to Typescript is the ability to interchange dynamic and static types. Such a powerful pattern. I found dialyzer to be slow and unhelpful quite often.
- lawik 5y agoDialyzer certainly isn't a perfect solution for static checking. But it does provide some of that to a very dynamic language. So I find it a useful tool. Personally I'm not that keen on type-heavy programming. Do you have good examples of this mix from Typescript, I'd be curious to see what that can be like.
- handrous 5y ago> Personally I'm not that keen on type-heavy programming. They all have types. Some are just much better-documented than others.
- bcrosby95 5y agoMy favorite are codebases whose type documentation is wrong. Such as the Java JPA+domain+webform god-type that will randomly have fields missing or unused based upon context, simply because people are too lazy to "document" another type.
- lawik 5y agoI'm aware the types are there. I can be more explicit if that was actually unclear. Static explicit typing often feels cunbersome to me. I gather you got my meaning but chose to make your point. But just in case.
- cryptica 5y agoHN community should stop promoting Elixir. It ruined many companies by depriving them of talented developers and it also ruined the careers of many developers by preventing them from becoming talented. Pure functional programming makes it easy for beginners to avoid mistakes but it limits their growth and prevents then from learning about proper blackboxing and separation of concerns. You cannot learn blackboxing without co-locating logic and state. It is an essential coding skill.
- sergiotapia 5y agolol
- cryptica 5y agoThe funny thing is that nobody has ever once bothered to debunk a single one of my points in any of the comments that I've ever made against Elixir or FP on HN. I've written much more detailed points in the past. Only downvotes but no meaningful responses. Nobody ever properly responded to any specific point. The best I get is "No it's not" without any further explanation. When I said that I've never seen any well written Elixir or pure FP project in my career and challenged people to send me a link to such a project on GitHub, nobody could do this. All I've ever seen in pure FP is spaghetti code; full of dependency injections which make it difficult to follow the logic (where does that module come from?), global state store (no different from using global variables!) or state being passed around all over the code (traversing many files since components are not allowed to hold any state), etc... Some ideas of FP are useful, but pure FP as a philosophy is rubbish.
- zachdaniel 5y agohttps://elixir-lang.org/cases.html https://elixir-lang.org/cases.html here you go
- dwoot 5y agoI mean, your points are pretty subjective. You've also extrapolated your anecdotes to make a sweeping statement that implies that all FP is spaghetti. You've made no objective counterpoints. Reducing any platform or language to "bad" sounds like someone that never quite understood the benefits of FP. Imperative languages are no silver bullet. Literally every code base that I'd ever worked in exhibits the same issues you describe as "spaghetti". But how does FP make it more so? Do you write unit tests? Tell me how you've not come across a codebase in a non-FP language that didn't require some insane fixture or factory or set-up code and it was insanely difficult to reason about because you had to invoke methods in a particular order to set an object up to be tested for a particular scenario. This is not the case with functional languages. You don't get the rug pulled out from under you very often and if so, it's typically centralized in the "actor" or process whose state can change whereas state is EVERYWHERE in most imperative languages and even challenging at times to introspect, especially when encapsulation is done right in some languages. Just because you've written more detailed points does not mean that they're valid or good. It just means that you have thoughts. If you've asked people to send you good projects, then you're already in a mental state that disallows you from accepting a good project. There are many. Don't ask, just search on GitHub -- many projects that don't even come from core devs. It's been much easier for me to reason about and push fixes to these projects compared to Ruby or JavaScript projects. I mean, we get it. You hate Elixir and you hate FP. You're entitled to that opinion, but please don't tell others to stop using it without having worked with it heavily and an accepting mentality to dig beyond the surface.