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

Elixir and Rust is a good mix

fly.io

Post reply on HN
Print view View original

31–40 of 165 posts

Re: Elixir and Rust is a good mix

#31

Post by malkosta »

zinclozenge wrote: post #14
satvikpendem wrote: post #7

I used to use Elixir, but the lack of static types got to me (especially since I prefer the type-driven development methodology). Using Rust afterwards was great, plus it was faster than the BEAM. I guess, why not use Rust entirely instead of as a FFI into Elixir or other backend language? I've been using Axum and it works pretty well. The only time I had to do FFI with Rust was with Flutter via flutter_rust_bridge,…

I pretty much agree with this. As much as I liked the core language, I absolutely hated using anything else in the ecosystem, and in my opinion a lot of that was due to lack of static types. Using Ecto as the main way of interacting with the database was a miserable experience. Part of that was due to skill issue I'm sure.

> Ecto as the main way of interacting with the database was a miserable experience

That's very common when you don't know DBs. But DB savy developers usually claim the opposite, because the syntax is more familiar.

Re: Elixir and Rust is a good mix

#32

Post by RhodesianHunter »

toast0 wrote: post #25
satvikpendem wrote: post #7

I used to use Elixir, but the lack of static types got to me (especially since I prefer the type-driven development methodology). Using Rust afterwards was great, plus it was faster than the BEAM. I guess, why not use Rust entirely instead of as a FFI into Elixir or other backend language? I've been using Axum and it works pretty well. The only time I had to do FFI with Rust was with Flutter via flutter_rust_bridge,…

Rust doesn't have a lot of good runtime introspection tools (or they're very not obvious). If you're running a system with a lot of concurrency, it's nice to be able to attach a debugger and find out exactly what's going on with each of your tasks. I haven't seen hot loading for Rust (but a quick search shows there's some out there), and I'm not sure how amenable Rust is to dlopen and friends to force the issue. Erla…

>Also, some of us are as anti-typing as you are pro-typing.

Assuming ample experience with both, how does one reach this conclusion?

I have yet to see a project of any size that needs to be worked on by multiple teams and is written in an untyped language not descend into dumpster fire.

Re: Elixir and Rust is a good mix

#33

Post by dsiegel2275 »

satvikpendem wrote: post #7

I used to use Elixir, but the lack of static types got to me (especially since I prefer the type-driven development methodology). Using Rust afterwards was great, plus it was faster than the BEAM. I guess, why not use Rust entirely instead of as a FFI into Elixir or other backend language? I've been using Axum and it works pretty well. The only time I had to do FFI with Rust was with Flutter via flutter_rust_bridge,…

I used to use Elixir. I still do, but I used to too.

Re: Elixir and Rust is a good mix

#34

Post by throwawaymaths »

toast0 wrote: post #25
satvikpendem wrote: post #7

I used to use Elixir, but the lack of static types got to me (especially since I prefer the type-driven development methodology). Using Rust afterwards was great, plus it was faster than the BEAM. I guess, why not use Rust entirely instead of as a FFI into Elixir or other backend language? I've been using Axum and it works pretty well. The only time I had to do FFI with Rust was with Flutter via flutter_rust_bridge,…

Rust doesn't have a lot of good runtime introspection tools (or they're very not obvious). If you're running a system with a lot of concurrency, it's nice to be able to attach a debugger and find out exactly what's going on with each of your tasks. I haven't seen hot loading for Rust (but a quick search shows there's some out there), and I'm not sure how amenable Rust is to dlopen and friends to force the issue. Erla…

it's certainly possible to write a nif that cooperates with the VM so that its async yield points match up with the VM's expectation of yield points. Definitely tricky to do correctly in C (given that C doesn't have a yield statement, lol, you have to structure it as an awkward tail call where you pickle/unpickle whatever state you want to keep around or unmarshal it from a passed struct). I'm not sure if that's so easy to do in rust.

Re: Elixir and Rust is a good mix

#35

Post by throwawaymaths »

RhodesianHunter wrote: post #32
toast0 wrote: post #25

Earlier quoted context omitted.

Rust doesn't have a lot of good runtime introspection tools (or they're very not obvious). If you're running a system with a lot of concurrency, it's nice to be able to attach a debugger and find out exactly what's going on with each of your tasks. I haven't seen hot loading for Rust (but a quick search shows there's some out there), and I'm not sure how amenable Rust is to dlopen and friends to force the issue. Erla…

>Also, some of us are as anti-typing as you are pro-typing. Assuming ample experience with both, how does one reach this conclusion? I have yet to see a project of any size that needs to be worked on by multiple teams and is written in an untyped language not descend into dumpster fire.

>I have yet to see a project of any size that needs to be worked on by multiple teams and is written in an untyped language not descend into dumpster fire.

Github? Dropbox? I mean they both eventually went to type hints in their respective languages or migrated to a typed language but for a long time I'm certain it wasn't.

Re: Elixir and Rust is a good mix

#36

Post by clessg »

peregrine wrote: post #24
alberth wrote: post #19

Doesn't the use of Rust have to be extremely minimal because ErlangVM has hard time limits on their preemptive scheduler and if your Rust code hasn't finished when preempted, that causes lots of problems. EDIT: thanks for pointing out where in the article this is talked about.

I go into this in the article :) the rustler team has a made a DirtyNif that can work around that, or you can manually yield if you'd like.

Indeed, your (excellent) article addresses this, here's the gist for those following along:

> Change `#[rustler::nif]` to `#[rustler::nif(schedule = "DirtyCpu")]`

> This tells the Rustler and BEAM to automagically schedule this in a way that won't block the entire world while it works. Again amazing, this is called a DirtyNif and is way more difficult to work with when you are manually using this via C.

Essentially, regular NIFs have to be extremely fast (https://docs.rs/rustler/latest/rustler/attr.nif.html):

> For functions that may take some time to return - let’s say more than 1 millisecond - it is recommended to use the `schedule` flag. This tells the BEAM to allocate that NIF call to a special scheduler. These special schedulers are called “dirty” schedulers.

> We can have two types of “lengthy work” functions: those that are CPU intensive and those that are IO intensive. They should be flagged with “DirtyCpu” and “DirtyIo”, respectively.

(Somewhat OT, but since I'm here: excellent article @ peregrine! I really enjoyed the read. Elixir and Rust are such a perfect fit. Plus, some of the specifics will be helpful for certain image-related things I'm actively working on, which is always nice. :) )

Re: Elixir and Rust is a good mix

#38

Post by ollien »

throwawaymaths wrote: post #35
RhodesianHunter wrote: post #32

Earlier quoted context omitted.

>Also, some of us are as anti-typing as you are pro-typing. Assuming ample experience with both, how does one reach this conclusion? I have yet to see a project of any size that needs to be worked on by multiple teams and is written in an untyped language not descend into dumpster fire.

>I have yet to see a project of any size that needs to be worked on by multiple teams and is written in an untyped language not descend into dumpster fire. Github? Dropbox? I mean they both eventually went to type hints in their respective languages or migrated to a typed language but for a long time I'm certain it wasn't.

It's worth noting of course that ~Github~ Dropbox was the driving force behind mypy

Re: Elixir and Rust is a good mix

#39

Post by dllthomas »

RhodesianHunter wrote: post #32
toast0 wrote: post #25

Earlier quoted context omitted.

Rust doesn't have a lot of good runtime introspection tools (or they're very not obvious). If you're running a system with a lot of concurrency, it's nice to be able to attach a debugger and find out exactly what's going on with each of your tasks. I haven't seen hot loading for Rust (but a quick search shows there's some out there), and I'm not sure how amenable Rust is to dlopen and friends to force the issue. Erla…

>Also, some of us are as anti-typing as you are pro-typing. Assuming ample experience with both, how does one reach this conclusion? I have yet to see a project of any size that needs to be worked on by multiple teams and is written in an untyped language not descend into dumpster fire.

While I'm pretty solidly in the "pro-typing" camp, it seems worth acknowledging that such projects often turn into dumpster fires in typed languages as well, even expressively typed languages.

Re: Elixir and Rust is a good mix

#40

Post by throwawaymaths »

ollien wrote: post #38
throwawaymaths wrote: post #35

Earlier quoted context omitted.

>I have yet to see a project of any size that needs to be worked on by multiple teams and is written in an untyped language not descend into dumpster fire. Github? Dropbox? I mean they both eventually went to type hints in their respective languages or migrated to a typed language but for a long time I'm certain it wasn't.

It's worth noting of course that ~Github~ Dropbox was the driving force behind mypy

yes, that is exactly what I meant by "they both eventually went to type hints", but doesn't github use ruby? I think you mean sorbet? Dropbox was the driving force behind mypy (IIRC).
Post reply on HN