41–50 of 152 posts
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.
Java 8 -> anything 11+ wasn't great at scale. It's been smooth sailing for a long time again though.
Elixir is still confusing, not the language, but the ecosystem, tooling, and philosophy. Is it dynamic or static? Is it compiled or not? If it's not, then why do we have Elixir scripts, which have different file extension? If it uses BEAM and you'd inevitably need to know Erlang when you hit the edge cases, then why not just learn Erlang? If it solves concurrency the "right way" due to supervision trees, why not use…
Python has a GIL and is mutable, which makes concurrency impossible and error-prone, respectively. Elixir doesn't have a GIL and is immutable.
A high-level language with a strict shared-nothing concurrency model doesn't need a GIL... but you naturally can't practically share very large objects between BEAM processes.
Earlier quoted context omitted.
Python has a GIL and is mutable, which makes concurrency impossible and error-prone, respectively. Elixir doesn't have a GIL and is immutable.
Python allows for memory sharing between threads - which is why a GIL is necessary. A high-level language with a strict shared-nothing concurrency model doesn't need a GIL... but you naturally can't practically share very large objects between BEAM processes.
I don't program in Elixir, but I'm a fan. I was a fan of Ruby -- because of it's pragmatism and subjective beauty -- but then I got into type systems. Elixir now also has a type system and, so does Ruby... Though I know program in Kotlin, which syntax-wise is very much a "typed Ruby".
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…
> 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.
Elixir is still confusing, not the language, but the ecosystem, tooling, and philosophy. Is it dynamic or static? Is it compiled or not? If it's not, then why do we have Elixir scripts, which have different file extension? If it uses BEAM and you'd inevitably need to know Erlang when you hit the edge cases, then why not just learn Erlang? If it solves concurrency the "right way" due to supervision trees, why not use…
these are all surprisingly specific questions that can actually be answered! 1. It's dynamic 2. It's compiled 3. Elixir script is just a file with Elixir code that compiles and runs right away 4. I've been writing Elixir for 7 years and barely know any Erlang. I even submitted bugs to OTP team with reproductions in Elixir, they're chill. 5. Preemptive scheduler, immutable data
My app is a mix of real time and rest endpoints, and there’s no heavy computation and even if there was I could just call do that one off in Go or something.
Would Phoenix make sense for me? I have some cool collaborative features in the works.
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…
> 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.
Earlier quoted context omitted.
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
They both ultimately produce BEAM bytecode, but Gleam compiles to Erlang source first (then through the Erlang compiler), while Elixir compiles to Erlang's abstract format. Gleam doesn't prevent OTP use - it has type-safe OTP bindings, but they're less mature/feature-complete than Elixir's, plus Elixir has better BEAM runtime integration (stack traces, profiling tools, etc).
For me some serious elixir adventure is high up in my todo list. But I remain suspicious if I can ever fully enjoy myself with a dynamic language - I think gleam and elixir do cater to different crowds. Gleam is pure minimalism (just pattern matching really), but elixir doesn't seem bloated either.
I am so happy that both languages exist and give alternatives in times of hundreds of node deps for any basic slob webapp.
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…
> 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.