Live data from Hacker News

Elixir 1.9

elixir-lang.org

151–160 of 174 posts

Re: Elixir 1.9

#151

Earlier quoted context omitted.

Currently releases require the OS and architecture to match. However, Erlang/OTP does support cross compilation, so at least a possibility is there, it needs to be further explored: http://erlang.org/doc/installation_guide/INSTALL-CROSS.html The other concern is packages with NIFs (native code) and they would need to be changed if they don't support cross-compilation yet. I believe Nerves, which is an Elixir framewor…

How does `mix release` handle NIFs currently? Same architecture is assumed?

Yes, basically it does not. It is up to the NIF packager to package a working way to handle that.

Re: Elixir 1.9

#152
post #20

Earlier quoted context omitted.

Elixir's `mix release` is intended to replace (or remove the need for) third-party packages like Distillery. However, it's not there yet, and Distillery is strictly more powerful at the moment. Notably, Elixir's release implementation does not support hot code upgrades. I use upgrades all the time, and won't be trying out Elixir's releases until this shortcoming is addressed.

What's the benefit of a hot code upgrade vs a blue/green deploy?

speed. A hot code upgrade can deploy a whole cluster in a few seconds. Plus it can keep states safe without rebalancing.

Re: Elixir 1.9

#153
post #122

Besides speed, what are the advantages of Elixir/Phoenix that a lot of fintech startups use them instead of Ruby/Rails?

Failure handling. Load profile is slower but far smoother, it degrades far more nicely.

It can handle stateful things and distributed systems far nicer, with a programming model that is really adapted to it.

Re: Elixir 1.9

#154

Earlier quoted context omitted.

Most people who point to Elixir's lack of static typing as a weakness, or believe their productivity would be adversely affected by it, do so because they haven't actually used the language. Anyways, this subject occasionally comes up for discussion in the community. This post sums up my thoughts fairly well: https://elixirforum.com/t/static-vs-dynamic-typing/9824/3

It's a near certainty that I've written an order of magnitude more elixir code than you have and I can say without a shadow of a doubt that elixir's lack of static typing definitely makes it less useful. Even if you disregard the modeling power that you can get from this there is an upper bound on any elixir project after which any work on it becomes less and less easy to do, as with all languages that lack a static…

What language would you use to write a server "that actually tries to do anything meaningful"?

Re: Elixir 1.9

#155
post #39

If anyone is on the fence on learning Elixir / Phoenix (Elixir's most popular web framework library) please do yourself a favor and give it a shot. If you're on a time crunch and want the best bang for your buck on "why bother learning yet another language to write web apps in?" then watch this talk called "The Soul of Erlang and Elixir": https://www.youtube.com/watch?v=JvBT4XBdoUE I'm not affiliated with the languag…

The Authn/Authz story of Phoenix is a joke though compared to Rails/Devise or Django. The framework authors refuse to ship a first party implementation and instead leave it to the community. Problem is, the ones available are mostly extremely low level (ueberauth, guardian etc.) and you have to spend ages customizing it. On Rails it's literally two commands to set up user registration, email confirmation, password re…

I can't speak for the Phoenix dev team but the fact that some of the Devise authors are now heavily invested in Elixir / Phoenix and they didn't port Devise to Phoenix by now makes you wonder if they still think the idea of Devise is a good one.

Personally I haven't found auth to be a problem in Phoenix and I have lots of experience with Rails (and using Devise).

You can put together an iron clad user registration + auth system in about 150 lines of app-level code (not including lines of code for the template forms, but with Devise you would end up customizing your own forms anyways). This includes registering new users, authenticating by email + encrypted password, logging in, logging out, session management and having the idea of a current_user in your system, along with a way to restrict routes, controllers or actions to only logged in users. The essentials basically.

I would much rather manage ~150 lines of code in my own project that I fully know and can easily customize than pull in something like Devise which is 6,000+ lines of Ruby and have to configure / override a number of things.

Everyone has their own opinions but I would much rather spend my time developing features for my app than trying to figure out how to customize a massive third party dependency.

Personally I'm rolling with a magic link authentication system in my Phoenix app and it was also around 200 lines of code to implement everything, including configuring and sending the emails out. There's no external libs beyond Phoenix to get it all working (except for sending the emails out, in which case I use Bamboo which is a lib dedicated to sending emails).

Re: Elixir 1.9

#156

Earlier quoted context omitted.

It's a near certainty that I've written an order of magnitude more elixir code than you have and I can say without a shadow of a doubt that elixir's lack of static typing definitely makes it less useful. Even if you disregard the modeling power that you can get from this there is an upper bound on any elixir project after which any work on it becomes less and less easy to do, as with all languages that lack a static…

What language would you use to write a server "that actually tries to do anything meaningful"?

Any language with the possibility to express variant types that all can have different structure and have that structure be checked at compile time, properly, will be a better choice for describing simple, medium and complex domains.

Whether or not this is based on nominal or structural typing is less important, because the feature itself only depends on differentiating between what is essentially different cases and having that be done safely and properly at compile time.

Elixir has no satisfying solution to this problem and it likely will never be able to. It is a huge penalty in domain modeling, which is why I personally don't want to use it for anything that actually has to deal with the flow of things.

To some extent I expected and wanted the VM to feel like it makes up for this by being so great that what it does, but there's no band-aid you can use to fix lack of modeling power.

Re: Elixir 1.9

#157

Earlier quoted context omitted.

The Authn/Authz story of Phoenix is a joke though compared to Rails/Devise or Django. The framework authors refuse to ship a first party implementation and instead leave it to the community. Problem is, the ones available are mostly extremely low level (ueberauth, guardian etc.) and you have to spend ages customizing it. On Rails it's literally two commands to set up user registration, email confirmation, password re…

> The Authn/Authz story of Phoenix is a joke though compared to Rails/Devise or Django. The framework authors refuse to ship a first party implementation and instead leave it to the community. I agree, but it's not unique to Phoenix. In the PHP world the otherwise excellent Symfony framework is only starting to add generation of authentication/authorization, and email confirmation and password reset remains the devel…

That's partially true because you have FosUserBundle as kind of defacto standard for user facing auth (but yes it's a community package) and many built-in things for APi auth.

Re: Elixir 1.9

#158
post #39

If anyone is on the fence on learning Elixir / Phoenix (Elixir's most popular web framework library) please do yourself a favor and give it a shot. If you're on a time crunch and want the best bang for your buck on "why bother learning yet another language to write web apps in?" then watch this talk called "The Soul of Erlang and Elixir": https://www.youtube.com/watch?v=JvBT4XBdoUE I'm not affiliated with the languag…

Fantastic talk. I have been meaning to learn more about Elixr for a while now, and this video was perfect. Thank you!

Re: Elixir 1.9

#159

Earlier quoted context omitted.

Most people who point to Elixir's lack of static typing as a weakness, or believe their productivity would be adversely affected by it, do so because they haven't actually used the language. Anyways, this subject occasionally comes up for discussion in the community. This post sums up my thoughts fairly well: https://elixirforum.com/t/static-vs-dynamic-typing/9824/3

It's a near certainty that I've written an order of magnitude more elixir code than you have and I can say without a shadow of a doubt that elixir's lack of static typing definitely makes it less useful. Even if you disregard the modeling power that you can get from this there is an upper bound on any elixir project after which any work on it becomes less and less easy to do, as with all languages that lack a static…

> It's a near certainty that I've written an order of magnitude more elixir code than you have and I can say without a shadow of a doubt that elixir's lack of static typing definitely makes it less useful.

You should really read that post I linked, and do a bit more research on this topic. The consensus in the Elixir community (where many members have written an order of magnitude more Elixir than you) is that static typing would be "nice to have", but is not critical by any means. Your post seems to be an attempt to spread FUD.

Re: Elixir 1.9

#160

Earlier quoted context omitted.

It's a near certainty that I've written an order of magnitude more elixir code than you have and I can say without a shadow of a doubt that elixir's lack of static typing definitely makes it less useful. Even if you disregard the modeling power that you can get from this there is an upper bound on any elixir project after which any work on it becomes less and less easy to do, as with all languages that lack a static…

> It's a near certainty that I've written an order of magnitude more elixir code than you have and I can say without a shadow of a doubt that elixir's lack of static typing definitely makes it less useful. You should really read that post I linked, and do a bit more research on this topic. The consensus in the Elixir community (where many members have written an order of magnitude more Elixir than you) is that static…

I've done all the research I need to, thank you very much, and I was there when this thread was started and much earlier than that. The consensus in the elixir community is hardly relevant when most of the users aren't experienced enough with type systems to know what they're talking about.

If you asked a community of people who primarily have never used languages that don't have garbage collection, they'll likely not understand at all why it could be a bad thing.

Someone who has used a language without garbage collection and is comfortable with basic allocation strategies is very likely to remark that having control of memory allocation and deallocation is very often something that you end up wanting instead of having to re-architect your solution in indirect ways to influence the garbage collector. This comes from having a wider perspective and the elixir community at large does not have this.

Given that the elixir community is also very cultlike it's hardly a productive thing to take what they say as the objective truth.

(I'm not saying this is an outsider at all, I've been a part of the elixir community since 2016. It's not really despite that I am saying these things, it's because of that.)

Post reply on HN