And still 0 successful startup has been built on top of elixir.
Switching to Elixir
31–40 of 283 posts
Re: Switching to Elixir
#32> In Ruby it's common to use exceptions for control flow.
I think this is just plain incorrect. The example given later in this paragraph is the Rails `update` method--but the approach used in all canonical Rails examples and generators is the non-exception version of `update`.
Re: Switching to Elixir
#33“In fact, I might go as far as saying that Elixir gives you a fun language (like Ruby) while leaving out the stateful footguns OOP languages give you. There are no classes, no instances, no inheritance…it's immutable and functional and you're not bogged down by a static type system.” I want this but with types. I’m convinced strongly typed is the way to go for larger code bases as it hides the magic of a lot of thing…
Types are coming! Hopefully not too far away.
https://elixir-lang.org/blog/2023/06/22/type-system-updates-...
Re: Switching to Elixir
#34I often see people say static typing slows them down and I'd really like to know why that is because for me it's the exact opposite, I really don't like not knowing what format data is in. I'd much rather have to write slightly more verbose code and have a vast number of possible errors caught at compile time instead of having things go wrong in production when someone inputs something a bit weird with nothing so much as an error.
Re: Switching to Elixir
#35Earlier quoted context omitted.
> 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 w…
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.
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.
Re: Switching to Elixir
#36“In fact, I might go as far as saying that Elixir gives you a fun language (like Ruby) while leaving out the stateful footguns OOP languages give you. There are no classes, no instances, no inheritance…it's immutable and functional and you're not bogged down by a static type system.” I want this but with types. I’m convinced strongly typed is the way to go for larger code bases as it hides the magic of a lot of thing…
It's less of an issue with elixir than it is with ruby or python or any other dynamic lang (or static lang) with mutability. Because of pattern matching/unification in functions, you have a good idea what shape your data is as it's being passed around. if you still don't feel comfortable, there's always Dialyzer.
Dialyzer is a static analysis tool for erlang/elixir. It's part of the standard Erlang Release and stands for DIscrepancy AnaLYZer for ERlang programs. It identifies software discrepancies such as type errors, dead code, unnecessary tests, etc., in single Erlang modules or entire (sets of) applications. Dialyzer starts from a base of correct programs and infers types; it doesn't require type annotations but uses them if they are available to provide better warnings.
https://fly.io/phoenix-files/adding-dialyzer-without-the-pai...
Re: Switching to Elixir
#37I often see people say static typing slows them down and I'd really like to know why that is because for me it's the exact opposite, I really don't like not knowing what format data is in. I'd much rather have to write slightly more verbose code and have a vast number of possible errors caught at compile time instead of having things go wrong in production when someone inputs something a bit weird with nothing so muc…
[deleted]
Re: Switching to Elixir
#38I often see people say static typing slows them down and I'd really like to know why that is because for me it's the exact opposite, I really don't like not knowing what format data is in. I'd much rather have to write slightly more verbose code and have a vast number of possible errors caught at compile time instead of having things go wrong in production when someone inputs something a bit weird with nothing so muc…
because of unification/pattern-matching you have a pretty good idea, just looking at function name + args what the shape of the data is going to be.
Re: Switching to Elixir
#39For me the big sell of Elixir/Erlang is that it makes running "background jobs" a complete breeze with no concern for blocking IO bringing the entire server to a halt, especially in a web server context. At my last job I had to do a bunch of HTTP requests in a webhook handler and if enough happened at once, the entire site would just crash due to all the OS processes being busy. I found myself desperately wishing I w…
Meh. I don't want background jobs to be a breeze in quite this way. I want background work to live on different compute capacity than http requests, both because they have very different resources usage and because I want to have state or queues in front of background work so there's a well-defined process for retry, error handling, and back-pressure.
I get it, of course, it'd be lovely if these complications didn't exist and the same framework handled everything... but I don't think a programming language or even a runtime gets you there. You also need monitoring and ops processes to be part of the solution.
Re: Switching to Elixir
#40I only learned about Elixir a little more than a year ago and it’s been a lot of fun to learn and incorporate in different components. My biggest joy comes from how much one can do out of the box with beam/otp. Someone in a team I worked with once said “BEAM/OTP is like k8s only without the complicated parts”.
When all else fails that's how I explain it to my team.
I spent years learning Elixir but unfortunately the benefits were somewhat undermined by the recent migration to OpenShift (k8s) I had just architected.
It would have been a much more tantalizing proposition if k8s was not in the picture; instead we kept our existing dev stack and utilized k8s concepts to achieve what we would have been doing in OTP, with different trade-offs of course.