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

Elixir 1.19

elixir-lang.org

Post reply on HN
Print view View original

101–110 of 152 posts

Re: Elixir 1.19

#101

Post by lelanthran »

pjmlp wrote: post #57
bryanlarsen wrote: post #21

Earlier quoted context omitted.

> So many examples of programming languages have huge breaking changes between versions I can only think of 2: python 3 and perl 6. Those two were very traumatic so it's not surprising it feels like more.

.NET Framework => .NET While C#, F#, VB and C++/CLI were kept compatible, it doesn't help when the library stuff you want to call isnt' there any longer. C++ removal of exception specifiers, GC API, C VLAs got dropped in C11, function prototypes changed meaning in C23, and K&R declarations were dropped from the standard. Java, already someone else mentioned. D, the whole D1 => D2 transition, and Tango vs Phobos drama…

> C VLAs got dropped in C11, function prototypes changed meaning in C23, and K&R declarations were dropped from the standard.

Not so sure I'd call these huge breaking changes. They're breaking, sure, but I'd expect them to be trivial to fix in any existing codebase.

Maybe VLAs are a huge breaking change? Most code never used it due to no way at all to use them safely, so while it is a pain to replace all occurrences of them, the number of usages should be really low.

Re: Elixir 1.19

#102

Post by pjmlp »

int_19h wrote: post #98
pjmlp wrote: post #80

Earlier quoted context omitted.

Not really. CPython used to have a GIL, it is no longer the case since the latest version, 3.14. Other Pythons, jPython, GrallPy, PyPy, never had a GIL. Languages and implementations aren't the same.

It still has a GIL unless you're using the free-threaded build, which most people do not.

Well most people aren't using version 3.14 yet, and it depends on the platform installer.

However it is still a CPython issue, it is already available for those that install the right version, and no longer considered experiemental.

Re: Elixir 1.19

#103

Post by flux293m »

atonse wrote: post #7
crbelaus wrote: post #2

The progressive introduction of automated type checking in Elixir should serve as a reference on how to improve a programming language gracefully without breaking changes. So many examples of programming languages have huge breaking changes between versions that end up creating a split in the ecosystem that takes years to resolve. Thankfully José has been very clear about Elixir being done since at least 2018. The la…

Yea each time I’ve upgraded (been using elixir in production since 2017), it’s gone way smoother than I had anticipated. I usually find the Erlang/OTP upgrades to be a bit more problematic compatibility-wise. So I’m often in the latest elixir but one Erlang/OTP version behind cuz I wait a few months for all the kinks to be worked out.

That's definitely the right way to do it, I've had exactly the same experience.

Re: Elixir 1.19

#104

Post by myth_drannon »

patates wrote: post #68
agrounds wrote: post #48

Earlier quoted context omitted.

Scala 3 has failed to be widely adopted, and now the language as a whole is more or less dead. Not that that’s due to the 2-to-3 transition entirely.

I haven't been following, now I'm sad to hear... Scala is really dead? What'd be the JVM alternative?

Kotlin?

Re: Elixir 1.19

#105

Post by pjmlp »

lelanthran wrote: post #101
pjmlp wrote: post #57

Earlier quoted context omitted.

.NET Framework => .NET While C#, F#, VB and C++/CLI were kept compatible, it doesn't help when the library stuff you want to call isnt' there any longer. C++ removal of exception specifiers, GC API, C VLAs got dropped in C11, function prototypes changed meaning in C23, and K&R declarations were dropped from the standard. Java, already someone else mentioned. D, the whole D1 => D2 transition, and Tango vs Phobos drama…

> C VLAs got dropped in C11, function prototypes changed meaning in C23, and K&R declarations were dropped from the standard. Not so sure I'd call these huge breaking changes. They're breaking, sure, but I'd expect them to be trivial to fix in any existing codebase. Maybe VLAs are a huge breaking change? Most code never used it due to no way at all to use them safely, so while it is a pain to replace all occurrences…

It was breaking enough for the Linux kernel, and the money Google sponsored to the effort remove them,

https://www.phoronix.com/news/Linux-Kills-The-VLA

Breaking changes are breaking changes, even if it is only fixing a comma, someone has to spend part of their time making it compile again, which many times maps to actual money for people working at a company, their salary mapped into hours.

Re: Elixir 1.19

#106

Post by yuliyp »

dns_snek wrote: post #79
yuliyp wrote: post #66

Earlier quoted context omitted.

You're measuring a cached compile in the subsequent runs. The deps.compile probably did some native compilation in the dep folder directly rather in _build.

No their results are correct. It roughly halved the compilation time on a newly generated Phoenix project. I'm assuming the savings would be more extensive on projects with multiple native dependencies that have lengthy compilation. rm -rf _build/ deps/ && mix deps.get && time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=1 mix deps.compile ________________________________________________________ Executed in 37.75 secs fish ex…

Oh, interesting. I guess `time` is only reporting the usr/sys time of the main process rather than the child workers when using PARTITION_COUNT higher than 1?

Re: Elixir 1.19

#107

Post by rkangel »

abrookewood wrote: post #32
innocentoldguy wrote: post #28

Earlier quoted context omitted.

Gleam doesn't give you access to the full amazingness of OTP and BEAM. Elixir does.

Why? Don't they all compile down to the same AST? How does Gleam prevent the use of OTP? Honest question - not overly familiar with Gleam

When talking about Elixir (or Erlang) you are actually talking about two things that give you the value:

- A language (Elixir/Erlang) and runtime (BEAM) - The concurrency standard library (OTP)

The language and runtime give you the low level concurrency primitives - spawn a process, send a message etc. But to build actual applications, you rarely use those primitives directly - instead you use GenServers and supervisors. That gives yo a way to manage state, turns message passing into function calls, restarts things when they crash etc.

Gleam compiles to the same runtime, but doesn't provide OTP in the same way - static types aren't easy to make work with the freely message passing world of OTP. They are implementing a lot of the same concepts, but that's work that Gleam has to do.

(Elixir provides some thin API wrappers over the Erlang OTP APIs, and then also provides some additional capabilities like Tasks).

Re: Elixir 1.19

#108

Post by [deleted] »

ludicity wrote: post #96
pandemic_region wrote: post #70

Earlier quoted context omitted.

How's that going for you?

Not the person you're responding to, but I also quit my job and started a company that uses Elixir for internal stuff. It's overkill for some of our problems but it's working fine! We make mistakes, but they're mistakes we'd have made with most other languages. I did have to buy Pragstudio licenses for anyone using Elixir on the team. I'd prefer a few books, but most Elixir/Phoenix books don't seem like they're keepi…

[deleted]

Re: Elixir 1.19

#109

Post by recroad »

pandemic_region wrote: post #70
recroad wrote: post #23

Earlier quoted context omitted.

I quit my job and started a company just so I can use Elixir.

How's that going for you?

Pretty good. The company is jumpcomedy.com and I'm making less money but am much happier. Pair and mob programming have been hugely helpful in sharing learnings and patterns. We only have three developers - all remote. One very nice surprise has been how amazing LLMs are with Elixir, something about a clean functional language maybe, not sure.

Getting feedback directly from production has been helpful too to tell us when we didn't think something through. We don't use branches, everything is a commit to main and every push is a production deployment so all three of us are in the loop on what each other is doing.

Didn't really buy any books but testing and trying things out in LiveBook has been huge to learn the nuances of the language. The LiveDashboard has been great in monitoring things, especially the PostGres plugin for it. The Discord community has been very supportive as well, and the Elixir Forums as well.

Re: Elixir 1.19

#110

Post by bmitc »

josevalim wrote: post #12
bmitc wrote: post #6

Earlier quoted context omitted.

The Phoenix churn is definitely real. It's so much so that I've never gotten into it. It's also extremely macro heavy, and so it's its own DSL or collection of DSLs. A concrete example of the churn is that the LiveView book has been "about to release" for five years now. Although, what parts of Elixir itself are rough or missing creature comforts? I generally feel it's stable and fine, but I admittedly haven't writte…

LiveView was still before v1.0, hence the churn, but Phoenix itself did not introduce breaking changes since v1.0, released more than a decade ago. Our skeleton for new applications change, as best practices around web apps are still evolving, but it is completely up to you to migrate. As a reference point, most other web frameworks have gone through several major versions in the same time, changing how new apps are…

Thanks for the clarifications!

> I believe less than 5% of Phoenix' public API turned out to be macros.

The idea may still be right, but I'm curious if that addresses the majority of the public API that users are greeted with. I have unfortunately not written Elixir in a few years (cries), and I've never fully grokked Phoenix, so perhaps I'm still wrong.

Post reply on HN