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

Elixir for Humans Who Know Python

hibox.live

Post reply on HN
Print view View original

51–60 of 198 posts

Re: Elixir for Humans Who Know Python

#51

Post by bboygravity »

spapas82 wrote: post #17
michaelteter wrote: post #5

No offense to TFA author, but I don't think this is doing to sell Elixir to Python people. In fact, I have serious doubts as to whether most Python lovers would be willing to set aside their beliefs and practices to learn the Elixir way. Perhaps Phoenix and LiveView will be the gateway drug, but even to reach that point requires a lot of effort to understand functional programming and Elixir. Python has some function…

I've got experience in both Phoenix and Django and I disagree. In my view, Phoenix is the less clean one: Django does not generate anything through scaffolding like Phoenix. Your CRUD (and auth and forms and everything more or less) is generated by overring the built-in Django classes or the classes offered by the packages. Nothing gets thrown away in real production; you use your class hierarchy to change it to your…

> I use Phoenix only on projects where its real-time capabilities will be the protagonist.

As a web user (not dev) I would say real-time (as in super fast?) should always be the protagonist?

To me that's the most important factor that makes the difference between nice and shtty website.

Re: Elixir for Humans Who Know Python

#52

Post by dugmartin »

ak_111 wrote: post #6

What is the productivity advantage of Elixir/Phoenix over other frameworks when using it for implementing more mundane SaaS (some dashboards, some CRUD,...) rather than the game lobby feature mentioned in the post? I am a developer with significant non-web development experience (Although I know pure JS and Erlang quite well), who is interested in learning some full-stack development to implement a SaaS on the side a…

For me it's not just the framework (although that is nice) but really the VM that it runs under (BEAM/OTP). Running an app on the BEAM means removing the need for external servers like redis/memcache for cacheing and whatever queue management system you pick.

For a SaaS app this means instead of trying to orchestrate a bunch of services via some complex system (k8s, etc) you run everything under one VM that both scales across both local CPU cores and distributed nodes in the same network easily.

As for dashboards and CRUD UI that is improving in the latest Phoenix release. I have a 5 year old Phoenix app that I wrote that is still running in production and I generated all of the backend admin and most of the frontend using Phoenix's generators. However that did result in a lot of nearly duplicate view code. With 1.7's focus on shared common UI components the shear volume of template code is reduced, (but not eliminated).

If I were you I'd wait for 1.7 to fully release and then try it out for a couple of hours and generate some simple app to get a feel for it. I've been programming professionally for 30+ years and I've written in a lot of languages and writing Elixir code just feels good. José Valim got a lot right with Elixir (and he sets a great tone - just read his comments in this very comment section).

Re: Elixir for Humans Who Know Python

#53

Post by noloblo »

spapas82 wrote: post #17
michaelteter wrote: post #5

No offense to TFA author, but I don't think this is doing to sell Elixir to Python people. In fact, I have serious doubts as to whether most Python lovers would be willing to set aside their beliefs and practices to learn the Elixir way. Perhaps Phoenix and LiveView will be the gateway drug, but even to reach that point requires a lot of effort to understand functional programming and Elixir. Python has some function…

I've got experience in both Phoenix and Django and I disagree. In my view, Phoenix is the less clean one: Django does not generate anything through scaffolding like Phoenix. Your CRUD (and auth and forms and everything more or less) is generated by overring the built-in Django classes or the classes offered by the packages. Nothing gets thrown away in real production; you use your class hierarchy to change it to your…

Elixir haskell and erlangs concurrency and parallelism story far outweigh any imperative pythonic benefits or idioms IMHO

Re: Elixir for Humans Who Know Python

#55

Post by spapas82 »

bboygravity wrote: post #51
spapas82 wrote: post #17

Earlier quoted context omitted.

I've got experience in both Phoenix and Django and I disagree. In my view, Phoenix is the less clean one: Django does not generate anything through scaffolding like Phoenix. Your CRUD (and auth and forms and everything more or less) is generated by overring the built-in Django classes or the classes offered by the packages. Nothing gets thrown away in real production; you use your class hierarchy to change it to your…

> I use Phoenix only on projects where its real-time capabilities will be the protagonist. As a web user (not dev) I would say real-time (as in super fast?) should always be the protagonist? To me that's the most important factor that makes the difference between nice and shtty website.

Not really. Real time is not the same as super-fast. You can be real time but super slow or super fast using traditional request/response web apps.

When I mentioned real-time I was talking about apps that need to use web sockets to have fast client-server communication. There aren't many apps where this is required (or worth it).

Re: Elixir for Humans Who Know Python

#57

Post by traverseda »

bboygravity wrote: post #51
spapas82 wrote: post #17

Earlier quoted context omitted.

I've got experience in both Phoenix and Django and I disagree. In my view, Phoenix is the less clean one: Django does not generate anything through scaffolding like Phoenix. Your CRUD (and auth and forms and everything more or less) is generated by overring the built-in Django classes or the classes offered by the packages. Nothing gets thrown away in real production; you use your class hierarchy to change it to your…

> I use Phoenix only on projects where its real-time capabilities will be the protagonist. As a web user (not dev) I would say real-time (as in super fast?) should always be the protagonist? To me that's the most important factor that makes the difference between nice and shtty website.

Real time like a chat app, or a video game or something. Not just a fast site. Seems like most "real-time" sites are slower as they have a harder time taking advantage of caching and the like, or use a lot of slow client-side javascript that inevitably works poorly.

Basically if you need the server to be able to change the data a user is currently looking at, collaborative multi-user stuff mostly. Liveview could be great if you're building google docs, but you could probably build youtube using just a more traditional framework like django.

Re: Elixir for Humans Who Know Python

#58

Post by elephanlemon »

fud101 wrote: post #56

I'm trying to decide between taking a Django job and an Elixir one. Can't decide between old and proven and new and early adopter. Any advice?

Have you written a functional language before professionally? If not, I’d lean towards Elixir as a way to expand. Can always go back to Python later.

Re: Elixir for Humans Who Know Python

#59

Post by yurishimo »

fud101 wrote: post #56

I'm trying to decide between taking a Django job and an Elixir one. Can't decide between old and proven and new and early adopter. Any advice?

Personally, I would take the Elixir job. Especially if you already know Python and have been employed previously. You'll learn a totally new way of thinking about problems. Many Elixir jobs are also aware that most people don't know Elixir, so you'll have plenty of time to learn on the job with plenty of support.

Re: Elixir for Humans Who Know Python

#60

Post by spapas82 »

josevalim wrote: post #27
spapas82 wrote: post #17

Earlier quoted context omitted.

I've got experience in both Phoenix and Django and I disagree. In my view, Phoenix is the less clean one: Django does not generate anything through scaffolding like Phoenix. Your CRUD (and auth and forms and everything more or less) is generated by overring the built-in Django classes or the classes offered by the packages. Nothing gets thrown away in real production; you use your class hierarchy to change it to your…

> Django does not generate anything through scaffolding like Phoenix I was one of the co-authors of Devise, which is an integrated authentication solution for Rails (similar in spirit to Django), and you will easily find people who swear that the code generation solutions are miles better. That’s because eventually they’d want to customize how the framework or library work and then, instead of simply being able to ch…

> instead of simply being able to change the code, you need to find the exact hook or configuration to get the behavior you want.

I don't think that this is a bad thing. This is the purpose of a framework. To extend its functionality. If I wanted to re-write everything (or change the generated scaffolds) then I'd skip the framework and use libraries directly.

I'd like to point out the biggest problem with scaffolding: Let's suppose I use scaffolding to generate a scema / database table in phoenix, along with all the bells and whistles. I'm happy; instant code. I customize all the scaffolds as I like (i.e change html layouts, fix the schema/migration for fks, fix the queries, improve forms etc). I'm happy; everything works as I like. After 1 hour I notice understand that my table is missing a field. I'm sad. Now I've got two equally sad options:

* Delete everything that phoenix has generated for me, drop the schema, re-generate the scaffold (with the new field) and re-apply all my customizations or * Add the field myself by adding a migration, adding it to the schema, fixing the tests, adding it to changesets, fixing the templates, fixing the queries and praying I haven't forgotten anything.

Now I'm very sad.

What would happen in that case (forgot a field in the database) in Django? Add the field to the model and re-run the migrations. That's it. Happy days!

> You can migrate (or not) at your convenience

Yes, I know that the views are still there but my understading is that they won't be generated anymore (so the steer is to not use them anymore, at least for new code). However, my main argument was that Django is better at holding your hand to produce acceptable code even if you are not experienced with the framework nor you have mentoring. The fact that now you have even more options (i.e you can use views if you want and think you need them) strengthens that argument.

Post reply on HN