Thinking that because something worked for someone will automatically enable it to work for everyone else is too much of a long shot.
And it goes way beyond tech stack, look what the Consensus of Washington did to most Latin American economies…
Besides, I would chose José and Chris (since you’re using Rails as an example) to be the captains of the ship instead of DHH any day of the week (Matz seems nice though).
Being “nice” is not a compliment to leaders. For example, Linus is far from nice.
But I never said that José or Chris were nice, nor that DHH isn’t. I only said that about Matz.
I don’t even know any of them to say they are or aren’t.
But when I listen to José speaking he strikes me as being way more down to earth than DHH, same goes for Chris. There’s not a glimpse of arrogance when they are speaking even when they are being criticized.
And I would say that having their heads firm up their necks is something that a leader needs.
I think it’s great that Rails has something like that - and it’s particularly great for people wanting to create apps like those - but for marketing to the mainstream and to people wanting to create apps that make the best use of everything the BEAM has to offer, then we have something better: Erlang; Cisco; WhatsApp; Klarna and all the other very high profile Erlang apps (on top of course our own Elixir high profile apps - which of course we are already making the most of (such as the big names here and how they are incorporated here)).
Currently we as a BEAM community (not just an Elixir one) can’t capitalise on some of Erlang’s highest profile users (as much as we’d might like to) for a number of different reasons - and some of this is impacting Erlang adoption itself too - such as Erlang often being seen as an esoteric and not actively maintained or developed language (which couldn’t be further from the truth) and, there not being, or us not making more of, closer BEAM interop, which has in a way led to a segregation of the benefits of the success-stories of each individual BEAM language.
I think focusing on this may be tied to the next big phase of adoption for all BEAM languages and I have some ideas here that I hope to post some threads about at some point 
There’s a pretty wide spectrum of app types out there and maybe I’m way off base here but I find sites like GitHub, Shopify, Basecamp and others a lot more relatable than a chat app with a billion connections or other technically impressive feats like Heroku’s router.
Almost every app I create is mostly focusing on sites that have a number of “pages” or “screens” and each page or screen involves reading and writing data from a DB and producing HTML mostly over HTTP with a bit of user experience enhancements with JS or maybe websockets in some cases.
That describes a large portion of SAAS apps (including this Discourse forum btw). This is a personal opinion of course but to me this is the main stream internet when it comes to what types of applications folks are building.
What types of apps are you building?
I’m not the most knowledgeable but perhaps one of the major points would be making sure that elixir is totally usable from erlang somehow, I don’t know the amount of work that would entail or if it’s feasible and someone must already have thought of this, but something like a library in erlang that would contain the translation engine and make including an elixir dep/lib/file (in order of importance) in erlang seamless. It does seem like it might be a lot of work but if possible it would open up elixir to the remaining BEAM and kinda guarantee that it’s not only usable but of use for those writing in other BEAM langs and making investing in writing Elixir libs more rewarding?
Although I understand, it’s non-sensical to compare Elixir to Rails (? Ruby ?) in terms of adoption while excluding the context.
Rails came out in 2004, as did basecamp, when developing web-apps was not what it is today. This was when the web was booming and prior to 2008. The speed it afforded in development allowed people to start building things much faster. Shopify was started in 2006. Github launched in 2008. The fact it was much better for building fast MVP’s than anything that was there, and the usage by those high profile comps eventually just snowballed the adoption. This is also tied with things like heroku, which was launched in 2007, worked only with Ruby and allowed people to deploy in a single command a web app/site. If you looked at the landscape then, and saw these things all aiming towards making the life of a webdev easier, and focusing more on executing the “idea” than on technicalities it’s easy to see why you would choose a language that had so much momentum and was aligned with your goals as a web-dev and used as well in building those services/tools.
Django was 2005. And python kept on growing in usage in other areas.
Nodejs is 2009 but has the unholy advantage of js being the language for programming the client side. It’s just not comparable the advantage that gives in terms of adoption - the investment, the absolute treasure trove that entails having a registry that feeds packages directly to millions of computers and the promise of isometric web apps. The investment that went into the whole ecosystem probably dwarfs everything else in a wide range area. And we just tack on more into the babel (no pun intended) tower.
And this is ignoring things like Java, PHP, etc. Wordpress is from 2003.
Phoenix was 1.0 in 2015. Elixir launched in 2011. The, make a web app with a router, connect to the db, display, is solved (as in, it has solutions, independently of their shortcomings or advantages) by a long time now.
Erlang is older but its utility might be seen of being for different types of systems. It doesn’t help that it doesn’t follow either the C school nor the Lisp school, although most functional ideas are being introduced into “mainstream”, the programming models haven’t changed yet.
The problem with tech by the numbers/success cases is that for it to make sense you would need to include “well, this bank is using cobol and is valued at billions, sure this must be proof of its superiority”.
Agreed. I don’t think measuring success by using Rails as a stick is useful because it was really a perfect storm. The options at the time were either bureaucratic XML-driven Java web frameworks or completely unstructured PHP. Rails was truly different from everything else at the time. The agile manifesto was also released 3 years prior, starting a new discussion around software development. It is no accident that the main Rails book was “Agile web development with Rails”. Then you had a whole other front on how to better design UIs for web applications, which 37 Signals was also involved with, as well as the Getting Real book. All of those were part of the “movement” and contributed over time.
This is of course not to remove anything from Rails/DHH/Basecamp. Others could have seized the occasion but they were the ones who did it.
For those who were doing web development at the time, those ideas were a large departure from the status quo. Today we see improvements in different areas but nothing that impacted so many fronts as it happened back then. And that’s why I think expecting other things to be Rails is not productive. Case in point: if there was a community that could pull another Rails, at least in terms of size, it would be JavaScript, and we haven’t seen it either. It felt Meteor at the time could be the one but it didn’t for many reasons.
EDIT: I would also add that web development became much more complex today, at least in terms of applications/architecture/use cases. Back then, SPAs were not a thing, native was not a thing, etc. Now it is hard for something new to come out as the unquestioned champion because you will immediately find 3 other use cases it won’t shine at.
I for one find a software stack able to handle WhatsApp’s load much more impressive than the 100,000 CRUD apps out there. 
I think LiveView has the potential to be nearly as big. The way I see it, it is a way to turn back time to the telnet/BBS era, when everything is interactive.
Right now LiveView still rely on conventional HTTP for the login, initial setup, even live_redirect need a little AJAX. Can everything be done in websocket? Telnet/SSH can do it; there is no reason LiveView cannot.
If LiveView is pure websocket, with all the static assets serving offloaded to a CDN, it will be a much simpler story to explain, not to mention the logistic improvement.
I think a great argument for maintainability is that Elixir is “finished.” So there is a very little worry you would need a painful 2.x rewrite. And compiler gets clever with every Elixir/Erlang VM release.
Before rewriting make sure you get all the libraries in Elixir you might need. If yes (or can write the missing one), then go for it!
DockYard just put out a whitepaper FYI
Where I work, we have a service that everyone wants to rewrite because it’s a smelly hot spaghetti mess written in Merb, a predecessor of Rails 3 which I had never heard of. From my experience at this company, I would say there’s definitely business value in converting to technologies that lightens our stack and gives us greater resiliency. We face a lot of challenges in providing devs dedicated environments because our stack is so heavy, and bringing services up can be really slow and sometimes error prone.
I have at times tried to advocate for Elixir at our company, but I’ve since decided to keep my mouth shut. It seems like we’re in a tug of war between the “we’re a ruby shop” crowd, the “nothing is better than the JVM” crowd, and the rest who kind of advocate for polyglot, Elixir, Rust, Go, and the like. And we’re losing voices among this last category.
In my role I specialize in React and I’d like to see adoption of Elixir for better architecture with real-time support, but I have little to no optimism this will ever happen at my current job, and I’m not sure where I should take my career at this point.
I think various aspects play a part when deciding on tech and while I would agree being relatable is one of them, it’s really just one factor of many. There are lots of different frameworks/languages that can be used to create sites like those you list and each of them offer various benefits and payoffs - and it’s these that I think are more interesting to people nowadays. As José mentioned things are far less simple now and the landscape has changed quite a bit.
I am mostly maintaining older (Rails) apps at present, but that’s not why I came to Elixir. I came to Elixir mainly because I felt Ruby and Rails wouldn’t be able to power the types of apps I wanted to create. I think a lot of people felt the same - were your reasons for coming to Elixir similar?
I would love to see something like this as well, though, like you I don’t know how doable it is. Either way I think we could definitely do with some focused discussions on this and that’s something I hope to help get started at some point
Hi @AstonJ - what are some examples of these?
Historically I had other reasons for looking at Elixir in the first place (mostly related to how far you can get as a “one man band”), but the ease of “soft real-time” enabled by the run-time, pubsub, liveview etc have set us up for a new wave of highly interactive applications even in historically boring line of business applications.
I wasn’t necessarily unhappy with Rails or Flask with the type of apps I create. I mainly wanted to learn something new and after researching both Elixir and Phoenix a bit it felt like there were a lot of pros and they were worth exploring. It also felt like it wasn’t going to be something that’ll get hyped and dropped.
On the bright side, I went back and looked at some Elixir code I wrote almost a year ago and most of it still made sense. I was also reminded at how well designed the ok / error tuple system is with pattern matching for writing extremely readable and extensible code.
I have only a few month to look back on old Elixir code. But this is safely enough time for me to not understand what my C or Python code is supposed to do… 
So when I look back at my “old” Elixir code it is either complete nonsense (like the one where I subclassed a GenServer) or I really still understand it. But this is not a property of Elixir but rather functional languages.
So to come back to the original question: when deciding to invest in Elixir/Phoenix you also decide for a functional language. Which is not mainstream. So you can’t compare Phoenix (about 20k likes on Github) with Spring, Django or Rails (each about 50k). But afaik Phoenix is the biggest functional web-framework with Scala’s Play (10k) as runner up.
Yep 
but I think what people have been mentioning most is that’s not easy enough and things like not being able to use Phoenix and Ecto isn’t possible… however I recently saw a post saying that it’s not actually possible to call every Erlang library in Elixir either (which I always thought was a great selling point for Elixir)… so we definitely need more clarity and discussion on this imo.
You could probably guess… but… a social network (as well as a few smaller apps to help get aquatinted with the language and eco-system).
I actually created a social network for a specific community as one of my first Rails apps, and that’s when I first discovered I might struggle with using Ruby/Rails for the bigger SN and that experience is what started me on my quest for something else. At first that was within Ruby (Volt) but then not long after that Phoenix arrived on the scene with a lot of the benefits that Volt was offering - and then some! 
Nice! Are any of these completed/public? If so you should definitely think about posting them in our #community:showcase section 
That’s awesome! I think one of the reasons people were drawn to Elixir (and Phoenix) was because of the promise of showing us a ‘better way’. In fact I still think this is something that could become part of the draw in a big way and we’ve had some discussions about some of these things in the past.
One advantage of Elixir+Phoenix I think is often overlooked is that it allows you to get up-and-running real fast AND scale your application to millions of users without (too much) overhead.
Many languages and frameworks only support one of these use cases. For example, Rails gets you started super fast, but won’t be performant enough to “simply scale” vertically. Thus, you must introduce horizontal scaling quite early, which adds complexity to your architecture. Then, you have languages which are designed with performance in mind, like Go. These, however, seldom support getting up and running real fast. This is why many companies like e.g. Google build their 1st versions in “quick” languages, like Python, and then rewrite the 2nd version in a performant language, like Go, if they see traction in a feature.
Obviously, having to scale your application to millions of users is a rare requirement for us developers, but it might be enough of an argument to convince “higher ups” of the worth of Elixir and the BEAM. One can simply do both, develop a prototype or that next USP in incredibly short time AND roll it out without worrying (too much) about whether it will scale.
Lastly, one can do all these things without ever leaving the Elixir context, as @sasajuric likes to argue and I agree with him. Having so many tools (background jobs, PubSub, shared in-memory state, clustering, telemetry, you name it) baked into the language is a major advantage. It helps onboarding devs real fast and allows them to continuously add value rather than having to maintain all these peripheral systems as well.
It depends on what scale you’re talking about.
If you want to build a million dollar business with tens of thousands of customers you can do this with Rails on a single $20 / month server all-in (including your database) and still be sitting at a few percent server load and sub-100ms response times using no fancy optimizations other than caching some views with the constructs provided by the framework.
For a lot of people that’s good enough. In the above example (which is taken from a real site btw) it even serves a fairly complex web app to non-registered users / anonymous visitors so the traffic is substantially higher than the reported customer count.
© Copyright Elixir Forum | Terms | Privacy & Cookies
