5 ms·

How do people switch programming languages? Established languages have massive ecosystems. Large set of libraries. For example, I cannot give up MS Entity Fr

How do people switch programming languages? Established languages have massive ecosystems. Large set of libraries. For example, I cannot give up MS Entity Framework Core or Hot Chocolate graphql server for C#. Sure, there are alternatives, but nothing as feature complete. Perhaps it is possible for applications that have small set of requirements.

whalesalad 3y ago
Elixir and Erlang are very well established ecosystems.
qaq 3y ago
Erlang is fairly established 37 years young language and Elixir got to build on top of Erlang ecosystem.
john-radio 3y ago
> Perhaps it is possible for applications that have small set of requirements. Well, for existing applications it is extremely difficult, not because Elixir lacks many important features that C# delivers (although I'm sure it does lack some, and vice versa in a big way), but more just because rebuilding any project that's had hundreds or thousands of person-hours poured into it, that's currently satisfying hundreds or thousands of business requirements which may or may not be documented, is a huge project with few rewards; the investment is huge and the return on investment is... I mean, being on {sexy new language} is nice, but nobody's paying you for that. But that's not what the OP's job is talking about. They just got a different job using Elixir, and are learning the technologies the same way anyone else does, and they're excited about this instance of it enough to write about it.
bradteamworks 3y ago
I used C# before using Elixir. I also thought Entity was awesome. But Ecto and Absinthe are even better from my perspective.
h0l0cube 3y ago
> MS Entity Framework Core Having worked with both EF Core and Ecto, I would gladly see the back of EF Core. Ecto is flexible enough to basically do everything you would with a raw SQL statement, but still use a relation mapper with it's validations. And if you have freeform output because you're doing a bunch of JOINs or querying a MATERIALIZED VIEW or whatever, you can just pipe that straight into a struct inline without having to declare a definition somewhere.
- CharlieDigital 3y ago
  EF Core these days is insanely good. It definitely has an initial learning curve, but once you've built a small sample app, it's quite easy to move ridiculous fast. It still provides access to raw SQL and can always add in Dapper if you want/need more complicated queries. But productivity is really, really good with very little sacrifice in terms of performance.
  - h0l0cube 3y ago
    I am using it these days and I've found it wanting compared to Ecto. The only thing I think is great about EF Core is automated migrations, but in practice that's not where the complexity lies. It's in all the odd queries you need to make to satisfy the business logic as it evolves. Edit: Probably the other good thing about EF Core is the designer, which as you mentioned is great for Rapid Application Development. Not really a time saver vs coding as the application scales, or if you prefer reasoning in code vs visually. Would like to see Ecto feature more user friendly tooling like a designer and automated migrations in the future though.
dimgl 3y ago
> For example, I cannot give up MS Entity Framework Core or Hot Chocolate graphql server for C#. What? Why? Also, what do you mean nothing is as feature complete as Entity Framework? What about ActiveRecord, Ecto, Django ORM, Knex, even Dapper in C# itself......
- cheema33 3y ago
  Do these replacements for Entity Framework Core offer first class support for Migrations, or temporal tables... Many of EF Core replacements do a handful of things well. And after that, it is a cliff. And now point me to a graphql server that is as feature rich and performant as Hot Chocolate. Simpler applications will not have complex needs that require feature rich libraries. But, beyond a certain level of complexity, you are on your own. And large orgs do create their own tooling and libraries. But, smaller orgs probably should stick to languages that offer large number of libraries to handle a vast number of problems. Anything else would be putting yourself at a competitive disadvantage.
lawn 3y ago
You just have to learn to let go of your favorite frameworks and libraries. If you do that then you'll often find loads of other amazing things that are better on the other side. For example; maybe there's nothing like the MS Entity Framework Core, but instead you'll get to use OTP that everyone's always gushing about which may solve many issues you're having with your current tech stack. Switching languages (and frameworks and libraries) is amazingly useful because you'll get exposed to solutions you didn't even knew you wanted.

whalesalad 3y ago

Elixir and Erlang are very well established ecosystems.

qaq 3y ago

Erlang is fairly established 37 years young language and Elixir got to build on top of Erlang ecosystem.

john-radio 3y ago

> Perhaps it is possible for applications that have small set of requirements. Well, for existing applications it is extremely difficult, not because Elixir lacks many important features that C# delivers (although I'm sure it does lack some, and vice versa in a big way), but more just because rebuilding any project that's had hundreds or thousands of person-hours poured into it, that's currently satisfying hundreds or thousands of business requirements which may or may not be documented, is a huge project with few rewards; the investment is huge and the return on investment is... I mean, being on {sexy new language} is nice, but nobody's paying you for that. But that's not what the OP's job is talking about. They just got a different job using Elixir, and are learning the technologies the same way anyone else does, and they're excited about this instance of it enough to write about it.

bradteamworks 3y ago

I used C# before using Elixir. I also thought Entity was awesome. But Ecto and Absinthe are even better from my perspective.

h0l0cube 3y ago

> MS Entity Framework Core Having worked with both EF Core and Ecto, I would gladly see the back of EF Core. Ecto is flexible enough to basically do everything you would with a raw SQL statement, but still use a relation mapper with it's validations. And if you have freeform output because you're doing a bunch of JOINs or querying a MATERIALIZED VIEW or whatever, you can just pipe that straight into a struct inline without having to declare a definition somewhere.

CharlieDigital 3y ago
EF Core these days is insanely good. It definitely has an initial learning curve, but once you've built a small sample app, it's quite easy to move ridiculous fast. It still provides access to raw SQL and can always add in Dapper if you want/need more complicated queries. But productivity is really, really good with very little sacrifice in terms of performance.
- h0l0cube 3y ago
  I am using it these days and I've found it wanting compared to Ecto. The only thing I think is great about EF Core is automated migrations, but in practice that's not where the complexity lies. It's in all the odd queries you need to make to satisfy the business logic as it evolves. Edit: Probably the other good thing about EF Core is the designer, which as you mentioned is great for Rapid Application Development. Not really a time saver vs coding as the application scales, or if you prefer reasoning in code vs visually. Would like to see Ecto feature more user friendly tooling like a designer and automated migrations in the future though.

dimgl 3y ago

> For example, I cannot give up MS Entity Framework Core or Hot Chocolate graphql server for C#. What? Why? Also, what do you mean nothing is as feature complete as Entity Framework? What about ActiveRecord, Ecto, Django ORM, Knex, even Dapper in C# itself......

cheema33 3y ago
Do these replacements for Entity Framework Core offer first class support for Migrations, or temporal tables... Many of EF Core replacements do a handful of things well. And after that, it is a cliff. And now point me to a graphql server that is as feature rich and performant as Hot Chocolate. Simpler applications will not have complex needs that require feature rich libraries. But, beyond a certain level of complexity, you are on your own. And large orgs do create their own tooling and libraries. But, smaller orgs probably should stick to languages that offer large number of libraries to handle a vast number of problems. Anything else would be putting yourself at a competitive disadvantage.

lawn 3y ago

You just have to learn to let go of your favorite frameworks and libraries. If you do that then you'll often find loads of other amazing things that are better on the other side. For example; maybe there's nothing like the MS Entity Framework Core, but instead you'll get to use OTP that everyone's always gushing about which may solve many issues you're having with your current tech stack. Switching languages (and frameworks and libraries) is amazingly useful because you'll get exposed to solutions you didn't even knew you wanted.