4 ms·

Because there's no alternative in Elixir. In Clojure, you can make a website many other ways, use any existing Java server, implement your own server quickly,

Because there's no alternative in Elixir. In Clojure, you can make a website many other ways, use any existing Java server, implement your own server quickly, use any templating language you want, implement your own quickly, use whatever routing lib you want, implement your own quickly, etc. Not only are there existing options from Java, but implementing your own is approachable to your average dev, and can be done in a reasonably short amount of time. Maybe it's a bit of the Lisp curse afterall. A language too productive, that no one bothers settling for the one framework. I also think Elixirs Ruby friendly syntax brought in a lot of Rubyists with Rails experience, and that attracted people who used Rails to Phoenix, giving it that inertia. Chris McCord used to be a Rails developer, so he came directly from Rails, so it made sense to rebuild a similar framework for Elixir, and a lot of people followed from Rails to Elixir as a better ruby with better scaling.

lvass 4y ago
Elixir is close to a different syntax for Erlang/OTP. It has high quality built-in alternatives since it came into existence.
- didibus 4y ago
  Erlang is not commonly used for web applications though, with Clojure, you had existing Java shops with Java web app who transitioned to using Clojure, simply keeping their Java web framework and writing their business logic in Clojure instead. If you adopted Elixir, you most likely were starting from scratch, a green field project. Since Erlang is already great at concurrent distributed systems, Elixir's niche became web application development, and it didn't have much existing libraries or frameworks to leverage, so I think it makes more sense for an initial popular framework to come to existence and rally others around. It still built on Erlang fundamentals, its web server is Cowboy for example, but there wasn't much on top to help with other parts of a web app.
jb1991 4y ago
> In Clojure, you can make a website many other ways, use any existing Java server, implement your own server quickly, use any templating language you want, implement your own quickly, use whatever routing lib you want, implement your own quickly, etc. The thing is, many (most?) developers are interested in building the end product, not building or heavily researching the ideal framework/library/stack itself. Without something easy to use, widely understood, and that has all the pieces hooked together, a lot of developers will get frustrated and seek different pastures so they can just concentrate on a product. That's why Rails and other similar libraries in other languages are so successful and make those languages successful, because a key layer is handled for you so you can just get higher-level work done. I used Clojure many years full-time and liked so many things about it, but the myriad ways to do the same thing does not appeal to everyone. This also extends to other aspects of the language -- the many different development environments and tooling, hooking together all the various ways to actually write, develop Clojure code. Many developers also don't want a lot of their time spent building a development workflow.
- didibus 4y ago
  Maybe since I consider myself more of a software engineer than a developer, I have a different viewpoint, but to me, as a SE, my job is not just to deliver the end product, but actually to produce the version of the end product that is also of as good quality as it can be within the budget and constraints of the business, as well as guarantee enough architectural runway to meet the business future goals and needs without increasing the future cost or lowering the delivery velocity over time. Often, I even contribute to what the end product should be, by consulting and informing on what can or cannot be achieved with technologies, or how by changing certain aspect of the product we can enable a lot more functionality in other ways. That means, throwing a scaffolded template and a prefab framework might be good for an initial proof of concept and v0 testing the market launch, but with Clojure you can often deliver POCs and v0s just as fast, but then have the flexibility to grow it as it needs too, where frameworks often become big drag on what you can do and how quickly you can do so as you need to grow the product. Basically, the inner working matters to the end product, especially when products don't have an end, but are really a lifetime of support and continued changes in feature-set and compatibility/scale.
  - jb1991 4y ago
    Valid perspective for some developers, yet thousands of software engineers enjoy creative, satisfying careers building projects without concerns for the inner workings of a web library or the extra effort to engineer the stack directly. They just want to build the product using an established framework.
    - blain_the_train 4y ago
      and clojure has several such frameworks.
      - jb1991 4y ago
        ... but nothing like rails, hence this article and discussion
    - 4y ago

lvass 4y ago

Elixir is close to a different syntax for Erlang/OTP. It has high quality built-in alternatives since it came into existence.

didibus 4y ago
Erlang is not commonly used for web applications though, with Clojure, you had existing Java shops with Java web app who transitioned to using Clojure, simply keeping their Java web framework and writing their business logic in Clojure instead. If you adopted Elixir, you most likely were starting from scratch, a green field project. Since Erlang is already great at concurrent distributed systems, Elixir's niche became web application development, and it didn't have much existing libraries or frameworks to leverage, so I think it makes more sense for an initial popular framework to come to existence and rally others around. It still built on Erlang fundamentals, its web server is Cowboy for example, but there wasn't much on top to help with other parts of a web app.

jb1991 4y ago

> In Clojure, you can make a website many other ways, use any existing Java server, implement your own server quickly, use any templating language you want, implement your own quickly, use whatever routing lib you want, implement your own quickly, etc. The thing is, many (most?) developers are interested in building the end product, not building or heavily researching the ideal framework/library/stack itself. Without something easy to use, widely understood, and that has all the pieces hooked together, a lot of developers will get frustrated and seek different pastures so they can just concentrate on a product. That's why Rails and other similar libraries in other languages are so successful and make those languages successful, because a key layer is handled for you so you can just get higher-level work done. I used Clojure many years full-time and liked so many things about it, but the myriad ways to do the same thing does not appeal to everyone. This also extends to other aspects of the language -- the many different development environments and tooling, hooking together all the various ways to actually write, develop Clojure code. Many developers also don't want a lot of their time spent building a development workflow.

didibus 4y ago
Maybe since I consider myself more of a software engineer than a developer, I have a different viewpoint, but to me, as a SE, my job is not just to deliver the end product, but actually to produce the version of the end product that is also of as good quality as it can be within the budget and constraints of the business, as well as guarantee enough architectural runway to meet the business future goals and needs without increasing the future cost or lowering the delivery velocity over time. Often, I even contribute to what the end product should be, by consulting and informing on what can or cannot be achieved with technologies, or how by changing certain aspect of the product we can enable a lot more functionality in other ways. That means, throwing a scaffolded template and a prefab framework might be good for an initial proof of concept and v0 testing the market launch, but with Clojure you can often deliver POCs and v0s just as fast, but then have the flexibility to grow it as it needs too, where frameworks often become big drag on what you can do and how quickly you can do so as you need to grow the product. Basically, the inner working matters to the end product, especially when products don't have an end, but are really a lifetime of support and continued changes in feature-set and compatibility/scale.
- jb1991 4y ago
  Valid perspective for some developers, yet thousands of software engineers enjoy creative, satisfying careers building projects without concerns for the inner workings of a web library or the extra effort to engineer the stack directly. They just want to build the product using an established framework.
  - blain_the_train 4y ago
    and clojure has several such frameworks.
    - jb1991 4y ago
      ... but nothing like rails, hence this article and discussion
  - 4y ago