Live data from Hacker News

Elixir for Humans Who Know Python

hibox.live

181–190 of 198 posts

Re: Elixir for Humans Who Know Python

#181

Earlier quoted context omitted.

I could be wrong and I really hope I am ... I really think it's the best stack out there, at least until you need the sort of extreme performance that dictates Rust (and even there Rustler looks good ... particularly as Rust extensions shouldn't jeopardise the extreme stability of the BEAM). But right now it looks on course to go the way of Clojure or Scala ... hanging in there for sure, but never becoming a major pl…

Why does it have to be a "major player"? :) Going the way of Scala, Clojure, etc is fine. If you have a community where people are innovating and/or enjoying the journey, companies feel productive but invest and understand the pros and cons of the ecosystem, then to me it is all good. They estimate there are more than 20 million developers worldwide and, if a technology can reach 1% of that, I personally find that am…

I absolutely feel you have grounds for being self-congratulatory.

But the linked article, and much of the discussion here, is really about persuading more people to adopt Elixir. Essentially people are being asked to tie a period of their professional career to the fortunes of a technology.

Most of us code for money ... we have families to support etc. This is where a language becoming a "major player" becomes relevant, it's all about career investment. Part of the reason dev pays so well (for people who typically suck at salary negotiation) is the extreme mobility of programmers. However that does depend, to a degree, on the technologies you have experience with being widely used.

Niche technologies can leave you somewhat trapped in your current job ... and the people negotiating salaries and raises for employers will inevitably exploit this.

I liked it when Python had a smaller user base ... there was more of a "geek club" feel ... but there is no question that the remuneration for devs and the flexibility they enjoyed improved as adoption increased.

So ... there are financial risks to adopting Elixir ... but, if more people adopted Elixir this risk would fall away ... a classic dilemma. The problem is that everyone pushing the tech seems to be glossing over this dilemma, and the risk it presents to the people being pitched to. Now much of this can be attributed to classic geek enthusiasm over a superior technology (caught up in idealism ... not always pragmatic), but not all. For sure, the cheerleaders for every new technology will do this, but it is still somewhat disingenuous.

Right now I think this gap between tech idealism and career pragmatism may be the primary sticking point in increasing Elixir adoption ... but I feel it is wrong to try to bridge it but steering the next wave of adopters away from a realistic, informed assessment of the risks. Downplaying this is a step towards making fellow devs cannon-fodder in a mind-share battle.

Re: Elixir for Humans Who Know Python

#182

Earlier quoted context omitted.

Why does it have to be a "major player"? :) Going the way of Scala, Clojure, etc is fine. If you have a community where people are innovating and/or enjoying the journey, companies feel productive but invest and understand the pros and cons of the ecosystem, then to me it is all good. They estimate there are more than 20 million developers worldwide and, if a technology can reach 1% of that, I personally find that am…

I absolutely feel you have grounds for being self-congratulatory. But the linked article, and much of the discussion here, is really about persuading more people to adopt Elixir. Essentially people are being asked to tie a period of their professional career to the fortunes of a technology. Most of us code for money ... we have families to support etc. This is where a language becoming a "major player" becomes releva…

> Niche technologies can leave you somewhat trapped in your current job ... and the people negotiating salaries and raises for employers will inevitably exploit this.

I don't think the relationship is that simplistic. On [StackOverflow Survey for 2022][0], the top salaries were for Clojure, Erlang, F#, LISP and Ruby. Elixir comes in 6th and Python comes in 25th. Choosing a niche technology may be a way to increase your salary and have more leverage because you will become a specialist on a niche (an increase of more than 40% when going from Python to Clojure by measure of average salaries).

Of course, it would be reductionist to say "learn Elixir and you will be paid more", but I also think it is inaccurate to say choosing a niche language is a certain trap. The best is to explore the companies, communities, and opportunities around you, especially in relation to which point you are in your career, instead of generalizing pros/cons as cheer-leading or blind optimism.

0: https://survey.stackoverflow.co/2022/#developer-profile

Re: Elixir for Humans Who Know Python

#183
post #177

Earlier quoted context omitted.

It is perhaps utopia but it would be nice if we could discuss those topics without falling into camps. For example, I could argue for hours about the benefits of immutability, but I still believe that imperative loops are clearer than functional ones. There is even a repository with solutions for nested traversals in different languages and the Python one is my preferred by some margin: https://github.com/josevalim/n…

Jose, are there still plans to modify Elixir at the language level to be potentially closer to the Python implementation? I know you started a proposal once around the time when we made that repo.

I was not able to write a proposal that was generally accepted by the community. We are still one break-through away from that happening.

Re: Elixir for Humans Who Know Python

#184

Earlier quoted context omitted.

It is perhaps utopia but it would be nice if we could discuss those topics without falling into camps. For example, I could argue for hours about the benefits of immutability, but I still believe that imperative loops are clearer than functional ones. There is even a repository with solutions for nested traversals in different languages and the Python one is my preferred by some margin: https://github.com/josevalim/n…

If only functional languages with immutable variables had some kind of "unsafe" section where you could actually mutate stuff... Rust approach looks good btw, with "let" making immutable vars and longer "let mut" for mutable variables

FWIW, F# also has something similar to `let mut`.

Re: Elixir for Humans Who Know Python

#185
post #178

Earlier quoted context omitted.

99% of line-of-business apps are CRUD. There's nothing special about "super complicated apps" that isn't brought in by the Python ecosystem. Where exactly do you think Django fails in that regard?

I love Django. I just think Python without types makes things hard at scale.

MyPy and friends have made this much, much better. In the long term it's probably not ideal for very large systems in many applications.

Re: Elixir for Humans Who Know Python

#186

Earlier quoted context omitted.

Concurrency is a pet use case for 99% of projects. Library ecosystem is the primary and dominant factor when choosing general-purpose technologies and Python has it beat.

In a multi core world concurrency and parallelism are no longer pet use cases. Unfortunately The slowness of python, gil and really bad design choices of Asyncio in python 3 relative to how elegant parallelism and concurrent programming is in Racket, haskell, elixir and erlang make python a non starter for many basic use cases

This is absolutely not true, because most of the industry uses Python for web services and serving web pages is still the same thing as it was 20 years ago. You scale by bringing in more processes.

Multicore concurrency is still a pet use case because high performance is still a minority of applications and async programming is not necessarily faster, per many benchmarks. Most companies will rewrite the high-performance component in the proper manner and continue to do everything else the way they did.

Re: Elixir for Humans Who Know Python

#187

Earlier quoted context omitted.

In a multi core world concurrency and parallelism are no longer pet use cases. Unfortunately The slowness of python, gil and really bad design choices of Asyncio in python 3 relative to how elegant parallelism and concurrent programming is in Racket, haskell, elixir and erlang make python a non starter for many basic use cases

This is absolutely not true, because most of the industry uses Python for web services and serving web pages is still the same thing as it was 20 years ago. You scale by bringing in more processes. Multicore concurrency is still a pet use case because high performance is still a minority of applications and async programming is not necessarily faster, per many benchmarks. Most companies will rewrite the high-performa…

>> Most companies will rewrite the high-performance component in the proper manner and continue to do everything else the way they did.

they do and when they need it is not in python or asyncio wonder why it is usually in cpp,java,erlang,elixir,haskell ?

Re: Elixir for Humans Who Know Python

#188
post #44

Earlier quoted context omitted.

I think this article does capture the magic of elixir phoenix live view that is impossible in the async await madness hell in python. I cannot wait to try elixir Phoenix live view, elixir |> pipes, :atom pattern matching and ets pids to send and manage processes across servers none of these AFAIK are currently possible with the GIL and single threaded nature of python As the venerable prof Joe armstrong would say you…

LiveView is great, but it is just one of many great reasons to use Elixir (and the ErlangVM ecosystem). There are the major benefits of Elixir itself, including FP, plus the array of features and tools for building distributed systems via OTP. Only talking about LiveView is underselling Elixir.

What are the major differences between elixir and erlang? Does elixir lose some of the advantages of the rock solid erlang improved over the years at Ericsson

Re: Elixir for Humans Who Know Python

#189
post #88
post #44

Earlier quoted context omitted.

I think this article does capture the magic of elixir phoenix live view that is impossible in the async await madness hell in python. I cannot wait to try elixir Phoenix live view, elixir |> pipes, :atom pattern matching and ets pids to send and manage processes across servers none of these AFAIK are currently possible with the GIL and single threaded nature of python As the venerable prof Joe armstrong would say you…

You can pattern match on basically any shape, not just atoms. Imagine you’re parsing a protocol over tcp and want to grab groups of characters between deliverers, you can pattern match that. I rewrote an hl7 parser from Java to Ruby to Elixr some years ago and the elixir implementation performed as well as Java and was more readable by miles.

Is this parser available for educational purposes on github thanks

Re: Elixir for Humans Who Know Python

#190
post #80

Earlier quoted context omitted.

As a Python programmer, I truly believe Elixir/Phoenix is the best stack out there from a technical perspective. However the incredible breadth of libs and resources ... and most importantly the mind share (both available devs, but more importantly available jobs for seniors who commit to Elixir) means that it is still just not a competitive choice. Almost all commercial software dev is not about technical excellence…

I guess it really depends on your definition of "make it". :) Elixir today is used by startups, unicorns, fortune 500, and at least two of the FAANG (for whatever it is worth). It is used for web apps, embedded, distributed systems, data processing, and making inroads on AI and machine learning. It has a vibrant community with events around the world, several dozens books, and more. It is on the [top quadrant of Redm…

From my initial review of growth since launch in 2014 Phoenix elixir seems to be by far the best web solution of all the contenders

I would say it's a mature platform supported by gcp as well as other major cloud computing providers

This replaces python/ perl / ruby for web development as the sane and sensible default this is a big deal and congratulations on this Jose and Chris

Post reply on HN