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

131–140 of 165 posts

Re: Elixir and Rust is a good mix

#131

Post by valenterry »

Fire-Dragon-DoL wrote: post #122
valenterry wrote: post #119

Earlier quoted context omitted.

I'm not a Rust programmer, but: > light-weight threading with preemptive scheduling prioritizing latency over throughput Rust has Tokio for light-weight threading which might well be sufficient for the majority of use-cases. > extremely robust fault tolerance with a supervision hierarchy One could argue that Rusts compile-time guarantees together with something like the Result-type make it so that such a supervision…

Tokio seems to be a valid replacement for lightweight threading in elixir. Fault tolerance and supervision hierarchy might be unnecessary as mentioned. Hotloading capabilities are unnecessary, most shops go with blue-green deployments, so the hotcode loading is usually unused (and for a good reason, so much complexity!). Distributed computing also goes unnecessary as most applications are deployed with containers wit…

> Fault tolerance and supervision hierarchy might be unnecessary as mentioned.

It's not like there is suddenly no fault tolerance though. Erlang has a certain way of handling/dealing with errors/faults and so does Rust and other languages. I would not by default assume that Erlang's errorhandling is superior.

> That leaves us with runtime introspection, which is pretty cool indeed. But that has to compete with Rust performance.

I would much rather say that runtime introspection has to comete with a static type system.

As I said many times, I really like the BEAM (saying that after having worked with Akka quite a bit) but Erlang/Elixir... those languages are really not great. There are many languages that way better. I also know that there is a new one for the BEAM (forgot the name) but so far we are mostly stuck with E&E.

Re: Elixir and Rust is a good mix

#132

Post by kaba0 »

valenterry wrote: post #119
dxhdr wrote: post #45

Earlier quoted context omitted.

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

I'm not a Rust programmer, but: > light-weight threading with preemptive scheduling prioritizing latency over throughput Rust has Tokio for light-weight threading which might well be sufficient for the majority of use-cases. > extremely robust fault tolerance with a supervision hierarchy One could argue that Rusts compile-time guarantees together with something like the Result-type make it so that such a supervision…

Come on, Rust has a good type system, but it’s nothing special - Haskell has the same guarantees since decades and it’s not like Haskell programs are suddenly without fault. There is only so much static types can catch without dependent typing, as per Rice’s theorem, types are a ‘trivial property’. Most of the interesting stuff happens at runtime and those are much harder to reason about.

Just because you have a Result type doesn’t mean you actually properly/meaningfully handle the error at all, it may just happen that “restart” is the correct solution. Also, Rust is not safe from dead/live locks and many other concurrency issues, only data race free.

This is not against Rust, but against the very biased hype for it.

Re: Elixir and Rust is a good mix

#133

Post by kaba0 »

toast0 wrote: post #44
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 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…

I always wanted to ask someone whose “native tongue” is untyped languages — when you reason about code, what do you think of an object, is it of specific type? Nominal, or more like structural typing that you know that it has to have this and that method?

I have started programming in untyped languages, but simply can’t remember back at all, and now I can’t really imagine dealing with objects in my mental medal as not having some type.

Note: this is not a rebuttal for/against dynamic typing, I do think that types are really important at boundaries, but they may not be the silver bullet - contracts may be better at some things, for example. This may be an open question.

Re: Elixir and Rust is a good mix

#134

Post by kaba0 »

ReflectedImage wrote: post #82
RhodesianHunter wrote: post #54

Earlier quoted context omitted.

The issue isn't productivity. As far as just slamming out code untyped languages are undeniably faster. The issue is working on projects once they've reached a certain size where you have no idea what the intent of the original author was and you maybe need to refactor, add-in major pieces, or change anything with the expectation that it continues to work.

Untyped code bases with microservices are the best code bases out there by far. They are exceptionally easy to refactor, add-in new parts, etc. The keyword is microservices, you need to know how to do proper microservices if you are using untyped code.

Microservices just push the problem out of sight — now you need interoperable types between them, there are race conditions, IDEs don’t see inside the black box of other services so refactoring is harder, etc.

They can be the correct solution sometimes, but blindly applying them everywhere is just dumb.

Re: Elixir and Rust is a good mix

#135

Post by valenterry »

kaba0 wrote: post #132
valenterry wrote: post #119

Earlier quoted context omitted.

I'm not a Rust programmer, but: > light-weight threading with preemptive scheduling prioritizing latency over throughput Rust has Tokio for light-weight threading which might well be sufficient for the majority of use-cases. > extremely robust fault tolerance with a supervision hierarchy One could argue that Rusts compile-time guarantees together with something like the Result-type make it so that such a supervision…

Come on, Rust has a good type system, but it’s nothing special - Haskell has the same guarantees since decades and it’s not like Haskell programs are suddenly without fault. There is only so much static types can catch without dependent typing, as per Rice’s theorem, types are a ‘trivial property’. Most of the interesting stuff happens at runtime and those are much harder to reason about. Just because you have a Resu…

> it’s not like Haskell programs are suddenly without fault

I never said that. But would you claim that Haskell programs are generally more faulty / less stable than Erlang programs?

> Just because you have a Result type doesn’t mean you actually properly/meaningfully handle the error at all

Okay, but the same is true for Erlang and the BEAM.

> it may just happen that “restart” is the correct solution

Yeah, but is very easy to do with Rust and Haskell or even just on the infrastructure level (i.e. restart the failed container/instance).

> Also, Rust is not safe from dead/live locks and many other concurrency issues, only data race free.

How is Erlang safe from those things in a way that cannot or only with a lot of effort be replicated when using Rust?

Re: Elixir and Rust is a good mix

#136

Post by kaba0 »

freedomben wrote: post #90
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 not descend into dumpster fire. Typing can definitely help, but it's just a small tool. Java is a pretty typed language and I'm seen some real doozy code bases in Java.

Though that might just as well mean that typed language projects, like those in Java have actually survived long enough to have turned into that.

It is easy to be maintainable at iteration 1 when the requirements haven’t changed 20 times yet.

Re: Elixir and Rust is a good mix

#137

Post by kaba0 »

zelphirkalt wrote: post #129
jimbob45 wrote: post #97

Earlier quoted context omitted.

I haven't come across problems in years that were CPU bound/where I needed something like Rust This is where Rust falls short of C#: scaling to the issue at hand. C# can build you a beautiful app at a high-level but also lets you dick with pointers and assembly at a low level. Rust insists on defaulting to pass-by-move and an arcane trait system that hold it back from being usable in large projects.

If Rust had gone for a traditional OOP system, the "everything must be OOP/use inheritance everywhere" crew would have messed up the ecosystem pretty quickly. The traits concept is refreshing and traits + structs encourage composition over inheritance. I think it has been a huge plus for the language and the ecosystem.

I really like the trait system, but “refreshing” might not be the correct word given that it is pretty much what Haskell had for I don’t even know how many years.

Re: Elixir and Rust is a good mix

#138

Post by medo-bear »

ReflectedImage wrote: post #127
medo-bear wrote: post #109

Earlier quoted context omitted.

for some reason people are able to use huge undocumented common lisp monolithic projects from the 90s without much effort and without setting their computer on fire. why do you think that is? i mean, given your world view, why would people even think about doing this for a codebase that doesnt have static types?

I'm just trying to point you in the right direction. Dynamically typed microservices is where it is at.

thanks, but maybe not

Re: Elixir and Rust is a good mix

#139

Post by medo-bear »

lispm wrote: post #123
medo-bear wrote: post #109

Earlier quoted context omitted.

for some reason people are able to use huge undocumented common lisp monolithic projects from the 90s without much effort and without setting their computer on fire. why do you think that is? i mean, given your world view, why would people even think about doing this for a codebase that doesnt have static types?

Maybe because the language is not untyped? It has both dynamic typing and optional static typing.

sure but not in a sense that rust is. my point is that it is entirely possible to build good software with substantial code bases in dynamically typed languges and i used common lisp as an example. in fact i dont know of one common lisp code base that turned to a dumpster fire because of typing problems. instead i find the opposite true: old forgotten code can often be resurrected because the language promotes clear coding and interactive introspection

Re: Elixir and Rust is a good mix

#140

Post by Dowwie »

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

Concurrency: if you used Elixir, then you should understand how different its concurrency offering is from that of std and tokio. Standardized, structured concurrency makes building complex, highly concurrent, stable, low-latency systems achievable by mere mortals. Rust has no such offering, yet, but it may 5-10 years from now.

Runtime instrospection: the ability to log into a running application to inspect its state, start and stop processes

Compile times: elixir compiles very quickly and has tight feedback loops where as rust compiles slowly and has long feedback loops

Elixir also doesn't get in the way that the borrow checker does, allowing a programmer to just get on with work and not become saddled with related debugging.

Ecosystem: data pipeline processing via GenStage, Broadway, Flow -- wow. Rust developers should take note of what can be achieved in Elixir. However, Rayon and crossbeam are fantastic. Elixir cannot compete with Rust on performance in the category of pipeline processing, but it has very high marks in other very important categories that need to be considered for professional development.

I don't think that fault isolation is as compelling an advantage over Rust as it is other languages. Rust makes defense programming a regular part of development, unwrap used sparingly. Faults hardly happen because the program isn't designed to crash. In the rare event that a well-designed Rust program crashes, it's probably managed by an orchestrator that will restart. Both well-designed Elixir and well-designed Rust applications can enjoy very long uptimes if that is a goal.

This is just a starting point of discussion.

Post reply on HN