8 ms·
All of my pet projects are run on Elixir/Phoenix. If there is a language/framework to learn, this would be it. As approachable as Rails with the benefits of han
by acconrad 9y ago
All of my pet projects are run on Elixir/Phoenix. If there is a language/framework to learn, this would be it. As approachable as Rails with the benefits of handling real time applications (chats are trivial with Channels) and faster runtimes than Rails (by orders of magnitude).
Happy to help anyone out if they're interested in learning!
- atom-morgan 9y agoWhat resources did you use/would recommend?
- deleted 9y ago[deleted]
- acconrad 9y agoI actually think phoenixframework.org is pretty robust on this at the moment, and using the #elixir chat in Slack is also awesome.
- mhd 9y agoThe problem with nice backend systems is that it just makes the switch to frontend work even worse. (Say what you will about Struts, but at least it makes JavaScript/React almost palatable by comparison.)
- randomstudent 9y agoYou can look into drab, an elixir server-side DOM manipulation library: https://github.com/grych/drab https://github.com/grych/drab. I've never used it, but many people in the Elixir community think it holds a lot of potential.
- esistgut 9y agoThis project seems really interesting, I guess it could pretty much replace SPAs (and related javascript fatigue) in a lot of use cases. Am I missing some significant limitation other than moving some computation back to the servers?
- randomstudent 9y agoI'm not qualified to answer that, as I haven't used Drab, but you can ask on the proper topic at the elixir forum: https://elixirforum.com/t/drab-phoenix-library-for-server-side-dom-access/3277/111 https://elixirforum.com/t/drab-phoenix-library-for-server-si...
- grych 9y agoThe only real limitation I can see for now is a response time for the actions, which might be done locally, without requesting anything from the server. Eg, you don't want to do animation loop with Drab, for this just use the ol' good JS.
- notamy 9y agoHoly @#$% that's amazing.
- bobwaycott 9y agoBoy, am I glad I read the HN comments today. Never knew Drab existed. It’s fantastic!
- christophilus 9y agoSerious question, though I know it will sound negative... I really don't like Rails and don't like Ruby or VB.NET, either (syntactically), which means Elixir is off-putting for me, at least in how it's been marketed. Do you know of anyone like me who has come to Elixir and liked it? Note: I like Clojure, F#, and other functional languages, so that's not a hurdle.
- randomstudent 9y agoThe syntax is bad (just like ruby), and there are some annoying limitations with macros, but the semantics are very good, and the ability to keep thousands (or hundreds of thousands, or even millions if you know what you're doing) of stateful connections to clients is very useful in practice.
- awj 9y ago> The syntax is bad (just like ruby) Any interest in qualifying that opinion?
- christophilus 9y agoNot the OP, but I share the opinion. I strongly prefer a precise syntax over ones where parens are optional, but required in some circumstances, etc. I don't like Ruby's block syntax at all. (Incidentally, I wish Ruby had better first-class function support instead of blocks.) I don't like "end" littered everywhere. I find the `=>` for hashes/dictionaries to be annoying, given how often I use that data structure (granted, I now mostly can do `{foo: :bar}`). There're other things I don't love, but that's a good chunk. Philosophically, I prefer explicit code to implicit (so, Rails is out). And I prefer functional programming to OOP in general, and find that Ruby greatly favors mutable OOP. I've had a tough time navigating around the Ruby parts of most code-bases I've found, largely due to the implicit nature, and annoying language features that allow clever generation of methods in a way that makes them impossible to search for (delegate ... prefix: true for example).
- randomstudent 9y ago
- Touche 9y agoI would love to use Elixir, I find the language to be the natural successor to Ruby, given the trends in languages today. However, everything I've read says that it's pretty hard to deploy. That the cloud options are limited (or take away the advantages of Erlang VM like code hot swapping). Any progress on this front?
- dgllghr 9y agoI think one of the difficulties here is that much of the functionality that comes from, for example, Docker + Kubernetes exists as part of the BEAM VM. A lot of the development being done today in deployment is around Docker and Docker clustering technology, which means that it often feels like you are doing things the old fashioned way when using BEAM clustering & networking technology. There are ways to set up these systems in symbiotic configurations, like having an Elixir/Erlang/BEAM cluster that has auto-joining thanks to external service discovery. However, to use the hot-swap functionality, you are going to be working with the BEAM VM directly, which means going through the Docker container boundary. Know that if you choose to go with BEAM and no Docker, you will still have access to amazing deployment features (like hot swapping, as you mentioned), but also clustering, service discovery, monitoring, etc. You're just going to be spending a lot more time at the command line without the pretty interfaces and the sleek modern tools. To get a better understanding of running BEAM, I highly recommend "Designing for Scalability with Erlang/OTP". You'll have to learn Erlang to get through it, but IMO it's the best introduction.
- sb8244 9y ago> you will still have access to amazing deployment features (like hot swapping, as you mentioned), but also clustering, service discovery, monitoring, etc. Can you elaborate on this statement? My understanding is that you can have these things (minus hot swapping) cleanly on Docker.
- dgllghr 9y agoYes, you definitely do. What I meant is if you didn't use Docker and just used BEAM, you would still have access to all those features that are present in Docker + clustering technology.
- tmat 9y agoreplace pet with nothing and you get my life.. it's also FAR cheaper to run at scale than ruby.. which means you can offer faster/better apps than your ruby peers at a lower price point. as a Ruby developer from Rails 2 > Rails 5.. about a year ago I made the switch to non-monolithic applications to Elixir API(no phoenix) and ReactJS front ends.. Match made in heaven.