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

41–50 of 165 posts

Re: Elixir and Rust is a good mix

#41

Post by throwawaymaths »

sergiotapia wrote: post #16
zinclozenge wrote: post #14

Earlier quoted context omitted.

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.

On the flipside for me Ecto is the perfect balance between ORM and writing raw SQL queries. I've used many different ORMs like Entity Framework, ActiveRecord, Prisma, Ecto - Ecto stands alone.

I believe... technically Ecto is not an ORM but a query builder, which may be why you like it better than an ORM.

Re: Elixir and Rust is a good mix

#42

Post by throwawaymaths »

OkayPhysicist wrote: post #11
pawelduda wrote: post #4

I used this in past, but there were a lot of people saying that NIFs/ports are dangerous to use. Did any of this change or are there tried and tested practices that can be applied? What I used this for wasn't critical app so I didn't mind it going down. IIRC one threat was Rust sharing memory with BEAM which could exhaust it and cause OOM crash?

NIFs are dangerous, ports are not. Basically a NIF runs in the same memory space as the BEAM, so misbehavior of the NIF can crash the entire application. On the other hand, they have wildly better performance than ports, which have to operate through STDI/O. The Rust / BEAM memory sharing problem does exist, but it's not nearly as bad as in more traditional C NIFs, because almost all C programs leak memory due to bad…

ports can be dangerous! One time my server lost performance because of a lot of zombie processes.

Re: Elixir and Rust is a good mix

#44

Post by toast0 »

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 work on a lot of 'glue' issues, often with languages like Perl, PHP, and Erlang (and a bit of Javascript here and there). Specifying types all over the place in languages like C, C++, Java, and Rust feels like it gets in the way and limits more than it helps. (feelings more than data here, of course)

Sure, at boundaries between teams, you need to specify the data in some way. That could be a type, but for me, often the other team is using a different language than me, so it needs to be a language agnostic type, and it can't include unsigned numbers because Java can't cope, and it can't include large integers because Javascript can't cope, etc. Protobufs are popular, json is too.

I have a lot of unpopular opinions though, and that's fine. It's just tiresome that everyone wants to come in and add types to things that don't need them. Also, I agree with dllthomas, most developers and teams are capable of creating dumpster fires in all sorts of environments, with all sorts of tooling. :)

Re: Elixir and Rust is a good mix

#45

Post by dxhdr »

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,…

> 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?

Sure, you just need to reimplement light-weight threading with preemptive scheduling prioritizing latency over throughput, extremely robust fault tolerance with a supervision hierarchy, and runtime introspection with code hotloading capabilities. Maybe you could add frictionless distributed system support as well.

No big deal, why not right?

Re: Elixir and Rust is a good mix

#46

Post by bglusman »

I admit for a long time this was my primary motivation to learn Rust, but, sadly, I haven't come across problems in years that were CPU bound/where I needed something like Rust... Rustler still looks like a great fit if needed, but, depending on the use case, if I were CPU bound and needed to write my own code/not just use a Rust library, I'd be as or more likely to look at using Zig and Zigler[0], for much faster learning curve, and from what I've read, easier tighter integration into elixir, including I think language server integration. Some discussion here[1] though I forget if I listened to this one or not.

[0]https://github.com/ityonemo/zigler [1]https://podcast.thinkingelixir.com/83

Re: Elixir and Rust is a good mix

#47

Post by toast0 »

throwawaymaths wrote: post #34
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…

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 e…

Sure, you can do that for the code you write, but you can't for the code you call. Any Erlang you write or call will have this property, and most of the ERTS provided C code will as well; either it's trivially finite, it is designed to yield during the work, or it's neither but it hasn't triggered anyone to fix it, with occasional deviations of things that become known issues (like -- was for some time; although it got fixed twice and is now fairly ok).

Re: Elixir and Rust is a good mix

#48

Post by vlunkr »

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'm in the same boat with Elixir. I love many aspects of the language, but it borrows the fast-and-loose type ecosystem of ruby.

nil is an especially big problem. Any value could be nil, and this will absolutely bite you over and over. nil even allows you to use square brackets for some reason (some_nil_value[:some_key]) which is a great way to disguise the actual issue.

There is optional type checking with Dialyzer, which is good but has some problems. The warning output can be really hard to read, and unless you're diligent in using it across most of your project, it's not very useful, because you'll end up with 'any' values all over.

Re: Elixir and Rust is a good mix

#49

Post by toast0 »

OkayPhysicist wrote: post #11
pawelduda wrote: post #4

I used this in past, but there were a lot of people saying that NIFs/ports are dangerous to use. Did any of this change or are there tried and tested practices that can be applied? What I used this for wasn't critical app so I didn't mind it going down. IIRC one threat was Rust sharing memory with BEAM which could exhaust it and cause OOM crash?

NIFs are dangerous, ports are not. Basically a NIF runs in the same memory space as the BEAM, so misbehavior of the NIF can crash the entire application. On the other hand, they have wildly better performance than ports, which have to operate through STDI/O. The Rust / BEAM memory sharing problem does exist, but it's not nearly as bad as in more traditional C NIFs, because almost all C programs leak memory due to bad…

I personally include port drivers in with ports, which gives you the same level of shared runtime environment as NIFs, with the benefits and drawbacks. Sometimes it makes more sense to interface as a port rather than as a function. Of course, sometimes it makes more sense to interface as a C-node rather than either; then you can be on a totally isolated machine, and the C-node can even crash or otherwise disable the whole OS and your Erlang node will be fine.
Post reply on HN