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

161–165 of 165 posts

Re: Elixir and Rust is a good mix

#161

Post by MaxBarraclough »

bombela wrote: post #64
di4na wrote: post #59

Earlier quoted context omitted.

In my experience it is even harder in a typed one because now you have to deal with the type system nightmare they built. So the compiler fight your refactoring.

Nobody code without a type system. The distinction is build time vs runtime type checking. At build time you catch bugs that would appear later at runtime. Which is more costly to fix later.

> Nobody code without a type system.

A small number do. Assembly languages are generally untyped. The Forth language is also untyped.

> At build time you catch bugs that would appear later at runtime. Which is more costly to fix later.

Generally agree. Programmers proficient in Haskell or Ada tend to consider types to be integral to their development process. The real question is whether this is a good tradeoff against development velocity, for your given project. Neither language markets itself for rapid application development, instead they tend to emphasise that the language aids with correctness and the ability to reason about code's behaviour.

Re: Elixir and Rust is a good mix

#162

Post by halostatue »

valenterry wrote: post #157
halostatue wrote: post #145

Earlier quoted context omitted.

> > 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? Each BEAM process (other runtimes would call them preemptable green threads) has its own heap, communicates with other processes by messages, and only works on immutable data without the involveme…

> Each BEAM process (other runtimes would call them preemptable green threads) has its own heap, communicates with other processes by messages, and only works on immutable data without the involvement of Native Interface Functions (NIFs). There’s no shared memory at all. Is this related to my question? I can see that this helps to prevent (or ease) out-of-memory errors. Other than that, what's the difference to using…

It is completely the answer to your question.

Note that Rust does not have green threads (RFC 230: https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...), so without using the coroutine crate (which most developers don’t know how to use; the truth is that most people don’t know how to use threads).

The features that I talked about have nothing to do with preventing out-of-memory errors—they don’t really help with that. For non-external resources, the features described prevent memory contention (no shared memory).

Much like it’s hard to understand the Rust borrow checker quickly, the "example" you’re asking for is not possible in a comment on HN. I recommend looking over Joe Armstrong’s thesis, for which I provided you a link.

Re: Elixir and Rust is a good mix

#163

Post by valenterry »

halostatue wrote: post #162
valenterry wrote: post #157

Earlier quoted context omitted.

> Each BEAM process (other runtimes would call them preemptable green threads) has its own heap, communicates with other processes by messages, and only works on immutable data without the involvement of Native Interface Functions (NIFs). There’s no shared memory at all. Is this related to my question? I can see that this helps to prevent (or ease) out-of-memory errors. Other than that, what's the difference to using…

It is completely the answer to your question. Note that Rust does not have green threads (RFC 230: https://github.com/rust-lang/rfcs/blob/master/text/0230-remo... ), so without using the coroutine crate (which most developers don’t know how to use; the truth is that most people don’t know how to use threads). The features that I talked about have nothing to do with preventing out-of-memory errors—they don’t really he…

> Note that Rust does not have green threads

Rust has Tokio, which does have green threads.

From https://docs.rs/tokio/latest/tokio/task

> A task is a light weight, non-blocking unit of execution. A task is similar to an OS thread, but rather than being managed by the OS scheduler, they are managed by the Tokio runtime. Another name for this general pattern is green threads.

Hence I don't see a fundamental difference here.

Re: Elixir and Rust is a good mix

#164

Post by valenterry »

dxhdr wrote: post #159
valenterry wrote: post #157

Earlier quoted context omitted.

> Each BEAM process (other runtimes would call them preemptable green threads) has its own heap, communicates with other processes by messages, and only works on immutable data without the involvement of Native Interface Functions (NIFs). There’s no shared memory at all. Is this related to my question? I can see that this helps to prevent (or ease) out-of-memory errors. Other than that, what's the difference to using…

> Other than that, what's the difference to using Rust's green threads, given that the developer knows what they are doing (but are still human and can make mistakes of course)? An analogy: The BEAM process model is to "developers know what they are doing" as the Rust borrow checker is to "C developers know how to write memory safe code." In other words, your program will have bugs. Your program will not correctly ha…

> The BEAM process model makes it so that a failure in one process won't take down all processes

Yeah. But the deveveloper still decides on how many and what processes there are. They have to understand the concept of a process and spawn them accordingly.

The same is true for Rust Tokio (and similar solutions) as well - you have to create tasks and manage their lifecycle.

For example, if you were to implement an http server, you'd have to use one erlang process per request so that if something goes wrong it only impacts this request and doesn't kill the server. In Rust, you would create a Task (green thread) per request as well, which then (if it fails) will not impact that Task that is "supervising" and creating those per-request-tasks, no matter if the request fails for a "valid" reason or because of a bug like an endless loop.

And even if there is memory and CPU resources (even OS threads) shared between those tasks, they are logically separated and for the developer it only matters in very rare cases (such as OOM errors).

I'm not saying that you get exactly the same level of fault tolerance or convenience with Rust here but I also don't see the fundamental difference. Hence, I feel your analogy would only make sense, if the developer has to work without a Task/Greenthread library.

Re: Elixir and Rust is a good mix

#165

Post by Andys »

zinclozenge wrote: post #150
Andys wrote: post #104

Earlier quoted context omitted.

Have you tried sqlc? Different to any other SQL library I've used and suits Go really well

Yes, I like it very much. I've run into some edge cases with it, and I wish there was a setting to change the names of some of the autogenerated code, but otherwise it works very well.

Yeah, hopefully its plugin architecture will continue to develop and make changing things easier in the future.
Post reply on HN