81–90 of 152 posts
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?
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.
Earlier quoted context omitted.
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.
Hi, 15155. May I clarify a couple of things? 1. Regarding Python's GIL: The issue isn't memory sharing between threads. Java and Go allow you to do this, too, but they don't have GILs. The reason Python has a GIL is that it uses reference counting for memory management. If it didn't have a GIL, multiple threads could simultaneously manipulate reference counts, which would lead to memory corruption/leaks. 2. You can s…
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…
mise use elixir@1.19-otp-26 erlang@26
rm -rf _build/ deps/ && mix deps.get && time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=1 mix deps.compile
________________________________________________________
Executed in 97.93 secs fish external
usr time 149.37 secs 1.45 millis 149.37 secs
sys time 28.94 secs 1.11 millis 28.94 secs
rm -rf _build/ deps/ && mix deps.get && time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=5 mix deps.compile
________________________________________________________
Executed in 42.19 secs fish external
usr time 2.48 secs 0.77 millis 2.48 secs
sys time 0.91 secs 1.21 millis 0.91 secsEarlier 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…
> GC API, Bit of a quibble but I'm not sure I'd call that a "huge breaking change" given that that feature wasn't really implemented in the first place, let alone actually used.
https://cppreference.com/w/cpp/compiler_support/11.html
It was a bad feature, as the two main C++ commercial products that make use of GC, namely C++/CLI and Unreal C++, were never taken into account while designing it, a good example how WG21 often does PDF driven design.
Earlier quoted context omitted.
I haven't been following, now I'm sad to hear... Scala is really dead? What'd be the JVM alternative?
It's not dead dead, but no new projects are choosing it. Those that chose Scala as the better Java can now just use the better Java from the latest JDK.
The issue for me is that Scala design lacks focus. They say yes to too many features.
Elixir was not a happy experience. The language itself is maybe OK but the overall experience is not. On a production build, stack traces look like Erlang code, which is the weird syntax that Elixir tried to improve upon. Then you have macros, which make code unmaintainable at the 10k SLOC mark, and increasingly harder to maintain as projects get larger. Running "mix xref graph" on most Elixir projects shows a spaghe…
Do you have an example? There are some cases that I can think of where the application dumps some foreign-looking data structures if the release fails to start, but that's very rare and usually the actual error is somewhere near the beginning like "eaddrinuse" here:
[notice] Application my_app exited: MyApp.Application.start(:normal, []) returned an error: shutdown: failed to start child: MyAppWeb.Endpoint
** (EXIT) shutdown: failed to start child: {MyAppWeb.Endpoint, :http}
** (EXIT) shutdown: failed to start child: :listener
** (EXIT) :eaddrinuse
Kernel pid terminated (application_controller) ("{application_start_failure,my_app,{{shutdown,{failed_to_start_child,'Elixir.MyAppWeb.Endpoint',{shutdown,{failed_to_start_child,{'Elixir.MyAppWeb.Endpoint',http},{shutdown,{failed_to_start_child,listener,eaddrinuse}}}}}},{'Elixir.MyApp.Application',start,[normal,[]]}}}")
10:47:17.229 [error] GenServer {MyApp.Registry, "some-long-running-thing:4196f8ae-c971-439b-854e-5057e45076b9", %{}} terminating
** (RuntimeError) attempted to call GenServer #PID but no handle_call/3 clause was provided
(my_app 1.1.0) /home/runner/work/elixir/elixir/lib/elixir/lib/gen_server.ex:895: MyApp.Monitoring.SomeServerMonitor.handle_call/3
(stdlib 5.2.3.5) gen_server.erl:1131: :gen_server.try_handle_call/4
(stdlib 5.2.3.5) gen_server.erl:1160: :gen_server.handle_msg/6
(stdlib 5.2.3.5) proc_lib.erl:241: :proc_lib.init_p_do_apply/3
Last message (from #PID): {:some_unknown_request, %MyApp.Monitoring.Stats{ts: ~U[2025-10-17 08:47:17.229542Z], some_data: 2}}
Absolutely, so don't write macro-heavy code. This is mentioned in the first paragraph of official Macro documentation and documented as an anti-pattern in the official documentation.
> The toolchain has much room for improvement.
I agree that editing experience (due to lacklustre language server support which is now being worked on officially), and debugging tools are lagging behind.
> And the documentation for most of the projects you will use is full of noise, with few workable examples, grandiose claims of performance and fantastic treasures, and the articles are a great read if you want to waste your entire evening.
I don't agree with this at all.
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…
> If it solves concurrency the "right way" due to supervision trees, why not use Python libraries that also implement the actor model, making Python code concurrent the "right way"? I can't speak too much about Python – but immutable vars is a core prerequisite for many of the features OTP (the platform underpinning Elixir (and Erlang)).
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.