Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

10 years-ish of Elixir

dashbit.co

Post reply on HN
Print view View original

51–60 of 127 posts

Re: 10 years-ish of Elixir

#51

Post by cactus2093 »

joelbluminator wrote: post #49
cactus2093 wrote: post #41

Earlier quoted context omitted.

Drawbacks I see are: 1. no static typing. With typescript having taken off, and now even python and ruby becoming more and more feasible to use in production with static typing, switching to a new dynamic language is a hard sell for me. 2. limited ability to take full advantage of some of its unique features in many cases. The runtime and the included OTP library/paradigm has some really cool features with its approa…

Ruby really isn't becoming static though. Most code used by Rubyists (e.g Rails apps) is likely to remain dynamic.

Yeah, I can't really tell if the overall community will adopt it or not, but you may well be right. Last time I commented something about ruby not having static typing I got downvoted by people claiming Sorbet is already used heavily in production.

But either way if I'm switching off of ruby, I don't really want to go to something else that doesn't have static typing.

Re: 10 years-ish of Elixir

#52

Post by sodapopcan »

Areading314 wrote: post #36
sodapopcan wrote: post #29

I'm building my first non-toy app in LiveView. I'm blown away by how quickly I can move with it and love how Phoenix encourages DDD practices. I'm a bit saddened that Elixir isn't bigger than it is. It's such a great entry into the world of BEAM and functional programming yet I've read more than once that people aren't interested because "it looks like Ruby and I don't like Ruby". There are some more legit reasons as…

What turned me off about elixir was not the syntax, it was the flexibility in designing new syntax. It felt like each library had its own idioms and syntax rules, which just adds a huge amount of variety and difficulty in a codebase. It was hard to have consistent architectural patterns across a team. I've seen an elixir/phoenix backend rewritten completely in python/django and it was a big improvement in developer p…

As in the whole project was rewritten in Django or some kind of transpiration going on there?

I haven't gotten to the point where I'm adding a lot of libs yet and certainly can't speak to using it in a big team.

In terms of syntax flexibility, Ruby has a similar issue where a lot of popular libs implement their own DSLs. I've never fully bought that that is a problem—a library is going to have an API that will require reading documentation. Maybe the one example that goes off the wire is RSpec (I'm really used to it now but I'm really enjoying going back to good ol' `assert` in `ExUnit`). In terms of keeping it idiomatic with the business logic, library can (and in my opinion always should) be wrapped. I may be missing the point or being reductive here, though, and I would be interested to hear more about your particular pain if you're willing to share!

...and of course if you are talking about using meta-programming to write business logic, that's not a thing anyone should ever do for any reason ever, period (IMO).

For me the raw speed of writing a highly interactive app in LiveView is unlike anything I've ever experienced. My primary experience is with Rails and React.

Re: 10 years-ish of Elixir

#53

Post by josevalim »

cactus2093 wrote: post #41
nudpiedo wrote: post #21

it looks really awesome! Can someone point out the negative sides (or drawbacks of any kind) ? What about finding elixir experts/freelancers? What about integration with .Net and the xamarin forms ecosystem?

Drawbacks I see are: 1. no static typing. With typescript having taken off, and now even python and ruby becoming more and more feasible to use in production with static typing, switching to a new dynamic language is a hard sell for me. 2. limited ability to take full advantage of some of its unique features in many cases. The runtime and the included OTP library/paradigm has some really cool features with its approa…

> limited ability to take full advantage of some of its unique features in many cases

Honestly, this shouldn't count as a downside. :) The way I frame it is "in the worst case scenario, you can deploy Erlang/Elixir as you would any other language".

You don't need to use distribution, you can still build stateless apps, etc. And yes, almost nobody uses hot code swapping!

However, whenever you need a specialized solution, such as quick messaging between servers, proper concurrency so a slow upstream server doesn't kill your app, etc... you have that at your fingertips!

Even if you are not using any of that in production, you are still leveraging concurrency when compiling code, running tests, etc. It really makes a large difference! And if for some reason you cannot leverage any of that either, the languages are still great on their own. Pattern matching and immutability are a joy, developers feel productive within the existing frameworks, and so on.

My car can go 260km/h but I never went past 140km/h (speed limit where I live) and I still love it (the best car I ever had).

Re: 10 years-ish of Elixir

#54

Post by jbothma »

Areading314 wrote: post #36
sodapopcan wrote: post #29

I'm building my first non-toy app in LiveView. I'm blown away by how quickly I can move with it and love how Phoenix encourages DDD practices. I'm a bit saddened that Elixir isn't bigger than it is. It's such a great entry into the world of BEAM and functional programming yet I've read more than once that people aren't interested because "it looks like Ruby and I don't like Ruby". There are some more legit reasons as…

What turned me off about elixir was not the syntax, it was the flexibility in designing new syntax. It felt like each library had its own idioms and syntax rules, which just adds a huge amount of variety and difficulty in a codebase. It was hard to have consistent architectural patterns across a team. I've seen an elixir/phoenix backend rewritten completely in python/django and it was a big improvement in developer p…

Yeah, my first job was in perl. Its "there's more than one way to do it" is harmful to productivity in a team.

Once I got into erlang's relatively obscure syntax, I could read just about any erlang at a glance.

I now mostly use python since it fits the use case better, and I love its "there's preferably one, obvious way to do it".

Re: 10 years-ish of Elixir

#55

Post by likortera »

desmondmonster wrote: post #46
likortera wrote: post #43

Meanwhile te company I work for is moving away from it. We cannot find enough people with enough knowledge to be already productive in it. Not many want to learn it because it is considered pretty niche, and the ones willing to learn will need many months or years to be productive and build with some level of quality, and once they learn they move away to bigger companies which pay more. We end up paying to people to…

It sounds like you're recruiting from a pool of junior developers and convincing them to use Elixir instead of attracting folks who are already interested in the language. Not only is that community sizable, but it's experienced- surveys of attendees at my conference ( https://empex.co ) consistently show that 50% have >5 years and 30% have >10 years in the industry. Elixirists really are senior developers and Elixir…

The folks you're talking about are a lot more expensive (in Europe at least) than the equivalent folks for more traditional platforms.

Again, and without centering ourselves in pure technical and our own careers and CVs. How does that help the business?.

Regarding to libraries, there's not much to discuss.

Just look at the number of available packages as right now:

rubygems: 164,235 (source: https://rubygems.org/stats) NPM: millions (source: https://en.wikipedia.org/wiki/Npm_(software)) PyPI: 283,519 (source: https://pypi.org/) HEX:: 12 252

I'm pretty sure I can find more than one package I'll miss.

> My company has built a scalable platform with 3 engineers. I don't even think about maintenance, I just think about delivering new features. So business wins are higher velocity + lower hosting costs + less downtime + senior team. You don't need to be WhatsApp to appreciate those benefits.

Hosting costs are a lot cheaper for us than developer's time. Downtime has never been an issue given "cloud" (docker based) infrastructure. The productivity part is something we're not seeing to be any better than with more traditional technology, and the reason we're moving away.

I wonder if what your team of 3 people is building couldn't have been built with just one engineer and ruby on rails at the expense of paying for two more servers.

Re: 10 years-ish of Elixir

#56

Post by andy_ppp »

freedomben wrote: post #47
1_player wrote: post #9

Earlier quoted context omitted.

You probably have seen it already, but recent Phoenix docs have a section on contexts and what is their intended use case: https://hexdocs.pm/phoenix/contexts.html The way I see it, context are just the public API to access your data model. Your Ecto schema is a piece of data, which in a functional language has no behaviour attached. The (business) logic to deal with this piece of data lives in the context. That's it…

Thanks, I'm not GP but have the same questions. What about access control? That's often directly tied into business logic, but it's so elegant and convenient to do it in the controllers or even the router using the pipelines. In fact a ton of the examples (I think even the Chris McCord Phoenix book) does exactly this, presumably for that reason. However I did that with an app and haven't been very happy with it becau…

There’s already an article on this you can find here: https://dashbit.co/blog/a-new-authentication-solution-for-ph...

The GitHub for the generator is here: https://github.com/aaronrenner/phx_gen_auth

Basically if you need something different it might be worth forking the generator. I might look at passwordless login at some point.

Re: 10 years-ish of Elixir

#57

Post by amattn »

nudpiedo wrote: post #21

it looks really awesome! Can someone point out the negative sides (or drawbacks of any kind) ? What about finding elixir experts/freelancers? What about integration with .Net and the xamarin forms ecosystem?

Elixir and the broader ecosystem have the following traits:

- It's a bit quirky, there's much else like it. Ruby is the closest.

- It's got a learning curve. It's not a particularly hard curve, but it is longer than a small language like go.

But on the other side of that curve is a very elegant, productive development experience.

No idea about the .Net ecosystem. It seems unlikely as Phoenix/LiveView is fairly self-contained.

Re: 10 years-ish of Elixir

#58

Post by ch4s3 »

mcintyre1994 wrote: post #37
ch4s3 wrote: post #25

Earlier quoted context omitted.

Come by and check out https://elixirforum.com/ and slack https://elixir-slackin.herokuapp.com/ everyone is super friendly and helpful. * edit: fixed link

I'm getting an error on that Slack link - https://elixir-lang.org/ links to https://elixir-slackin.herokuapp.com/ which I think is the right one?

The one from https://elixir-lang.org. I think I incorrectly copied it from slack.

Re: 10 years-ish of Elixir

#59

Post by desmondmonster »

likortera wrote: post #55
desmondmonster wrote: post #46

Earlier quoted context omitted.

It sounds like you're recruiting from a pool of junior developers and convincing them to use Elixir instead of attracting folks who are already interested in the language. Not only is that community sizable, but it's experienced- surveys of attendees at my conference ( https://empex.co ) consistently show that 50% have >5 years and 30% have >10 years in the industry. Elixirists really are senior developers and Elixir…

The folks you're talking about are a lot more expensive (in Europe at least) than the equivalent folks for more traditional platforms. Again, and without centering ourselves in pure technical and our own careers and CVs. How does that help the business?. Regarding to libraries, there's not much to discuss. Just look at the number of available packages as right now: rubygems: 164,235 (source: https://rubygems.org/stat…

Ironically, Europe has a higher concentration of Elixirists given Erlang was invented there. My hiring attitude is that paying for senior developers is cheaper in the long run given their ability to make better decisions.

> I wonder if what your team of 3 people is building couldn't have been built with just one engineer and ruby on rails at the expense of paying for two more servers.

Emphatically no. Having more servers costs more than just hosting, there's maintenance, orchestration, and communications complexity.

While other package ecosystems certainly have _more_ packages, the question is: how many of those will you actually use?

Re: 10 years-ish of Elixir

#60

Post by josevalim »

freedomben wrote: post #47
1_player wrote: post #9

Earlier quoted context omitted.

You probably have seen it already, but recent Phoenix docs have a section on contexts and what is their intended use case: https://hexdocs.pm/phoenix/contexts.html The way I see it, context are just the public API to access your data model. Your Ecto schema is a piece of data, which in a functional language has no behaviour attached. The (business) logic to deal with this piece of data lives in the context. That's it…

Thanks, I'm not GP but have the same questions. What about access control? That's often directly tied into business logic, but it's so elegant and convenient to do it in the controllers or even the router using the pipelines. In fact a ton of the examples (I think even the Chris McCord Phoenix book) does exactly this, presumably for that reason. However I did that with an app and haven't been very happy with it becau…

Personally, here is what I do: if access control is part of the business model, then I put it in the context and, almost always, I raise. Otherwise, continue doing it in plugs. That's it!

For web apps, you should almost never be triggering these invalid access control state, because it means the UI is allowing users to do something they are not really supposed to do. If the user cannot delete a resource, then the button most likely shouldn't show up (or it should be disabled with a comment) etc.

Raising actually helps us find these bad UI paths too because I get an error I can act on.

Now let's say you do want to handle some of these errors. You have three options:

1. Continue raising and rescue in the controller (meh)

2. Continue raising and implement Plug.Exception for said exception so you control how they are shown to the user (great if they are still general exceptions)

3. Return {:ok, _} | {:error, ...} and handle it in the controller (or in the FallbackController for APIs)

Post reply on HN