Elixir ecosystem is a dream come true and future proof, except...for...,

[dimitarvp]

@PJextra

PS: if you had at least 2 options you would avoid debates about the best one and you would get more people on board.

Disagreed. There are more storage models outside of RDBMS and graph databases – like append-only ledgers, key-value stores, time series, and many others. There will always be those unhappy that their favourite tech piece has no adapter in Elixir.

@PJextra

Then you could debate while using Elixir ecosystem. Now we are debating when some people are outside the ecosystem.

With respect, you are way too focused on how you evaluate and choose your tech. I personally know 15+ programmers who refused to do a deep dive in Elixir because they didn’t want to learn functional programming. I know at least 20 who want to but their management wouldn’t let them. And I spoke face-to-face with 6-7 who needed something very specific and niche but couldn’t spare the time to reinvent it in Elixir and thus went back to Java or C#.

---

Finally, I don’t see why we should strive to make Elixir more popular. It has a lot of unique and strong properties yet that doesn’t stop numerous uninformed skeptics regularly bashing it on Reddit and HackerNews. What should we do? Force them to adopt it with a gun to their head?

When you build something valuable, people will come to you. If you follow ElixirForum lately you’ll see that it should probably be renamed to LiveViewForum. Like half the new topics are about LiveView these days.

People should adopt a tool on their own free will and needs. Elixir has received a lot of advocacy already. If that didn’t convince some people, that’s okay.

[dorgan]

I believe nobody disagrees that Elixir will benefit from a wider ecosystem of libraries and projects(and adopters!).
However, someone has to write them, maintain them, and put a lot of effort so you can use it. This has been already pointed out.

Repeating that Elixir would benefit from more options wont make libraries magically appear, nor will convince many people to start working on them if they don’t have the need or energy to, especially if it’s something they don’t need. I know you’re excited about Elixir(and that’s great!), and coming from a js background you may be used to a very wide ecosystem, with libraries for whatever you can imagine being published every day, but the message that gets to me is of a request for the community to make a wider ecosystem, and that doesn’t happen so easily. Many people reach for elixir because they had to solve a problem that was very hard to tackle in other languages, not because of the wide ecosystem.

The best you can do is learn and understand elixir(and erlang!), tell people about it(in an informed way, preferably), help people to solve their problems, and write some libraries yourself(which is a great learning exercise, too).

You don’t need to compare graphdb or nosql solutions to rdbms or whatever else to write a library(that’s a different discussion that should be made when building a program that may use it), that’s not the point, if that helps to your vision of the Elixir ecosystem, then do it! “Because I want to” is more than enough of a reason

[chouzar]

I would say SQL is way ahead of its time personally I love how the language is very terse while keeping consistency within formal methods.

[Nicd]

I don’t think this thread is going anywhere. I find two arguments are being repeated:

1. Elixir needs more choices for non-relational databases.
2. Elixir already has many libraries for non-relational databases, even though they don’t all work with Ecto (which is relational focused).

I don’t see any progress being made in this thread anymore and it feels like persons arguing 1 do not react to argument 2, just repeat 1. So I suggest just abandoning this discussion to prevent wasting time and prevent possibly heating arguments.

[revati]

@PJextra I didn’t read everything, but from many of your responses about new -> old, past -> future, sql -> nosql and so on i cough’t some pattern that is a little bit worrying for me.

What is your reasoning behind that document is future and sql is past? Mostly it is something that you have consumed a lot of content about.

And if you will look closely you will find that for every 1 post “praising” (because mostly everyone are describing benefits and how it is better than what ever came before) some sql implementations there will be hundredths of posts describing how some nosql db is the best. For every post that “praises” crud there will be many “praising” graphql. Pattern is clear “old” (read: stable) technology does not get as much hype posts, clicks as “new” (read trendy) technology. We have technology/trendiness bubbles.

And you as you self described are somewhat new developer and you are exposed to world, here there are plenty content about some technologies, that might seem as something everyone is praising/talking about and thats the silver bulled, that once it will be finished/understud and what not, will be applicable to all uses cases world will throw at me. Thats rarely is the case.

99.99% that people who currently invest in learning java/sql, will be able to work with these tools for rest of their lives and earn living. It will not go anywhere. I doubt that elixir will go anywhere, but it might get stuck in limbo, where it is one of those niche languages, that after 20 years only dedicated ones know. And if so, i would tell that it is bad. Becase for each good programmer that is developing nice frameworks/tools for elixir ecosystem, there are many more doing the same for jvm (even tho it is “old”).

I doubt there is clear solution how to escape those bubbles i have been victim of similar thinking:

• graphql - don’t get me wrong, its great, but up front design i need to do, and extra maintenance. I personally have worked only in ine project wehere it might pay off.
• reactjs - why bother if now there is next great thing liveview
• seperating frontend and backend in seperate apps - once agian, its rarely is necesity. in most projects where i encountered it, it was premature optimization, becasue we will have multiple clients, what will talk to this one api. Its nice, but f*cking get one client battle tested, to understand your bussiness domain first.
• eventsourcing/cqrs - its great, and i still think that with proper tooling it would beat conventional crud systems in no time, but tooling isnt there, debuging is harder, unceonvetional. It has great pros, but it also has cons, that rarly anyone is talking about.

Everything has cons and pros. Each product, solution might require different aproach and tools. I would suggest no to concentrate on implementation (crud/graphql, sql/nosql), but to try to extract overall patterns. In oop in that sense it is easier, because whole oop revolves around patterns. In fp languages, its wrongly (in my opinion) described that no patterns is needed. there are no patterns only functions. But There are (recursion, fold left, reducer - all of these are the same pattern sort of just in different implementation level).

DDD blue book by Eric Evans is one of the best books on programming there is. Its examples are in oop, but once again oop is just an implementation. Overal pattern is how you think about structuring your app. And if you think fp does not need that, than you are mistaken.

/rant

Hope you will find your middle ground between those worlds. Good luck

[mkunikow]

There are new sql databases like Google spanner , cocrouch db so called distributed SQLl databases. So SQL will never be dead