Embedding Python in Elixir, it's fine • Hacker News Board

Re: Embedding Python in Elixir, it's fine

#61

Post by chantepierre » Wed, Feb 26, 2025, 9:43 AM UTC

throwawaymaths wrote: post #52

yellowapple wrote: post #49

Other commenters have already pointed out the safety implications of using NIFs for this. There are, however, other downsides worth considering: - The Erlang VM scheduler can't preempt a NIF, so a long-running Python call risks hanging the VM. This is a non-issue for ports, since Python's running in a separate OS process. A NIF can mitigate this by spawning an OS thread and yielding until it finishes; ain't clear if…

I would have guess the builders of this would have mitigated this problem by running the python in a thread? That won't hang the VM (or cause a segfault at the 1ms boundary). It might cause OS starvation in extreme cases, but you'd have to be really extreme.

There are dedicated "dirty" schedulers for long-running NIFs that by nature cannot be preempted, to avoid interfering with BEAM process scheduling : https://www.erlang.org/doc/apps/runtime_tools/scheduler.html

Re: Embedding Python in Elixir, it's fine

#62

Post by __jonas » Wed, Feb 26, 2025, 11:16 AM UTC

giancarlostoro wrote: post #34

chefandy wrote: post #16

Earlier quoted context omitted.

I hadn’t heard of gleam. Looks cool! I like working with elixir in a lot of ways but never was a Ruby guy, and I think I’d prefer the C-style syntax.

I'm more of a Python and C# kind of guy, so Elixir never really hit the itch for me, but Gleam definitely does. One of these days I'll take a crack to see how I can use Gleam with Phoenix.

I’d recommend to first see if you can use a full-Gleam solution (like wisp/lustre) if it’s a greenfield project – interop is of course possible but can sometimes be a bit unpleasant due to the difference in data structures (Elixir structs va Gleam records) and inability to use Elixir macros directly from Gleam, which are heavily used by projects like Phoenix and Ecto.

Re: Embedding Python in Elixir, it's fine

#63

Post by tmountain » Wed, Feb 26, 2025, 6:36 PM UTC

ikety wrote: post #40

chefandy wrote: post #16

Earlier quoted context omitted.

I hadn’t heard of gleam. Looks cool! I like working with elixir in a lot of ways but never was a Ruby guy, and I think I’d prefer the C-style syntax.

My current favorite language, just no time to finish my gleam projects.

I’ve been eyeing gleam as my next language to learn. Lots to like about it for sure, and I have always like the idea of OTO but never had an opportunity to tinker with it.

Re: Embedding Python in Elixir, it's fine

#64

Post by OkayPhysicist » Wed, Feb 26, 2025, 10:02 PM UTC

behnamoh wrote: post #7

Elixir has some features I wish Python had: - atoms - everything (or most things) is a macro, even def, etc. - pipes |>, and no, I don't want to write a "pipe" class in Python to use it like pipe(foo, bar, ...). 90% of the |> power comes from its 'flow' programming style. - true immutability - true parallelism and concurrency thanks to the supervision trees - hot code reloading (you recompile the app WHILE it's runni…

The part of Elixir pipes that people overlook is the fact that, as a native, heavily used part of the language, the entirety of the standard library and most third party libraries are written with their behavior in mind. The first argument (the pipe target) will be the argument you want piped in faaaar more often than in languages where pipes are tacked on later.

Re: Embedding Python in Elixir, it's fine

#65

Post by ch4s3 » Thu, Feb 27, 2025, 6:29 PM UTC

fire_lake wrote: post #25

paradox460 wrote: post #24

Earlier quoted context omitted.

I feel like you can write some variant of this comment every few years and just add the previous "best" to the front of the stack of things it's better than.

It’s true - people were saying that Poetry solves these problems for ages. Maybe uv does? I’ll wait and see.

This time they've got it for sure!

Re: Embedding Python in Elixir, it's fine

#66

Post by streblo » Fri, Feb 28, 2025, 7:49 PM UTC

paradox460 wrote: post #24

streblo wrote: post #21

Earlier quoted context omitted.

uv for Python is a game changer, better than anything else out there and solves a lot of the core problems with pip/venv/poetry/pyenv (the list goes on).

I feel like you can write some variant of this comment every few years and just add the previous "best" to the front of the stack of things it's better than.

You're not wrong, this is the nth iteration of python tools that try to solve all the problems of what came before, including whatever the n-1th iteration introduced.

That said, in my personal experience with uv, it solves nearly all of the problems I've come across that were created by other python package management tools. It seems to have been very thoughtfully designed and I think there's a strong chance it'll become the standard, and that there won't need to be more standards after this. We'll see!