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

101–110 of 165 posts

Re: Elixir and Rust is a good mix

#101

Post by whalesalad »

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

There is a great talk from the creator of the language on why static types are not necessary. Of course there is nothing wrong with wanting them and feeling that they are, but I think he (José) makes really great arguments for why Elixir is the way it is. https://www.youtube.com/watch?v=Jf5Hsa1KOc8

Re: Elixir and Rust is a good mix

#102

Post by Dowwie »

dxhdr wrote: post #45
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…

This list isn't long enough. OTP and Elixir are wonderfully unique. Rust is, however, as well. I don't think that anyone who truly understands the two could comment about using one as a default.

Re: Elixir and Rust is a good mix

#103

Post by mrdoops »

benatkin wrote: post #89
mrdoops wrote: post #84

Earlier quoted context omitted.

Elixir does distribution and concurrency really well, so Fly making multi-region deployments easy makes it a good fit.

So is Fly good for small sites or is it good for huge sites? What's a big customer? For small sites my idea of a multi-region deployment is a single-region deployment that works in multiple regions thanks to the magic of the Internet. I see this which mostly seems to be content sites. https://www.wappalyzer.com/technologies/paas/fly-io/ Same on the first forum result: https://community.fly.io/t/customer-success-stori…

I'd say its good for both.

Small sites because it is low-bandwidth to figure out how to use. Time is money and if I'm just tinkering on the weekend I don't really want to learn Kubernetes or the labyrinth that is AWS; I just want to ship an app.

Big sites because your users get routed to the node closest to them and again you can do this without a lot of time investment. For Elixir I just wire up Libcluster and my nodes can talk to each other.

I really want GPUs on Fly soon though. Just take my money Kurt. (I hear they're working on it)

Re: Elixir and Rust is a good mix

#104

Post by Andys »

zinclozenge wrote: post #61
parthdesai wrote: post #27

Earlier quoted context omitted.

> Using Ecto as the main way of interacting with the database was a miserable experience. Ecto is prolly one of the best ways to interact with db. Genuinely curious, what other ORMs have you used?

I usually just write the SQL, honestly. For the last 6ish years of my career I've mainly been in the Golang world, so the closest I've gotten to an ORM is a utility to scan rows into structs.

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

Re: Elixir and Rust is a good mix

#105

Post by toast0 »

OkayPhysicist wrote: post #100
toast0 wrote: post #49

Earlier quoted context omitted.

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…

What's the benefit of a port driver over a NIF?

A port driver can participate in the BEAM event loop, adding filehandles that get called back when they're ready.

It's a more appropriate choice for something that's asynchronous, although NIFs do have ways to fill the same role. A port driver would probably be a better choice for specalty networking that ERTS doesn't provide (raw packets? netgraph, etc).

Re: Elixir and Rust is a good mix

#106

Post by dist1ll »

dxhdr wrote: post #45
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…

> light-weight threading with preemptive scheduling prioritizing latency over throughput

Tasks for backend systems are usually pretty homogeneous. I'm not sure how in such cases the overhead of preemption is in any way better than cooperative multitasking.

Re: Elixir and Rust is a good mix

#107

Post by 3836293648 »

dllthomas wrote: post #39
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.

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.

Sure, but they don't turn into dumpster fires because of the types, as untyped projects tend to do

Re: Elixir and Rust is a good mix

#108

Post by josephg »

freedomben wrote: post #92
RhodesianHunter wrote: post #58

Earlier quoted context omitted.

You can absolutely create a dumpster fire in any language. Putting the fire out in an untyped language is a Herculean effort.

Test coverage is, in my experience, much more important factor than typing. A codebase with great testing is much easier to aggressively refactor/change whether typed or not. That said, a dumpster fire usually has no or little tests, so maybe we're arguing non-existent hypotheticals :|

I’ve gone back and forth over the years on whether tests are a good enough replacement for types. A few thoughts:

- Types and tests find different bugs. I’ve found new bugs by converting a project from javascript to typescript. The project in question had a 2:1 test:code ratio but as soon as the typescript compiler could read it, it spotted a couple obvious errors.

- Large test suites often make refactoring harder, not easier. If you have a clear, fixed API boundary and your tests test that boundary, then testing helps. But most refactoring also involves changing up those APIs as well - since bad APIs are often the reason you want to refactor in the first place. When you do that, you have to also rewrite all your tests. Good type systems help refactoring. Writing rust in Intellij, I can globally rename functions and types in my project, promote tuples to structs, reorder function arguments, and all sorts of other handy refactorings. My tests get updated too. And the compiler tells me immediately if I missed anything, without needing to rerun my tests.

- Reading the types is my favourite way to get up to speed on a project, or get back up to speed on something I wrote myself that I’ve forgotten. "Show me your flowchart (code) and conceal your tables (type definitions), and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)

- I find I need far fewer tests to write reliable software when I’m using a language with a good type system. Most rust code I write works correctly once it compiles. Javascript is easier to write than typescript, but it’s harder to test and debug.

So with all that, I’m personally in camp type these days for most software. I think it’s usually the right choice.

Re: Elixir and Rust is a good mix

#109

Post by medo-bear »

ReflectedImage wrote: post #76
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.

Untyped languages work fine if you use them with microservices. The only thing you can't do is have both untyped and monolithic at the same time.

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?

Re: Elixir and Rust is a good mix

#110

Post by josephg »

sdeframond wrote: post #87
toast0 wrote: post #67

Earlier quoted context omitted.

> Which is more costly to fix later. This assumption is changed, IMHO, by Erlang. Hot loading makes the cost to make small changes very low. So the question becomes, do you pay the definite cost of build time type checking (usually includes coding time type annotation), or do you accept the possible future cost to making small fixes. Of course, if you work in an organization where even a small fix requires months to…

The cost at runtime also includes loss of data, inferior user experience, direct financial loss or even loss of human life for some systems. It really depends on the domain but it definitely is more than pushing an update.

The cost is also in debugging. It’s much harder to figure out a problem after the fact because you’ve forgotten how the code in question works. If you catch a mistake while you’re coding something up, you can fix it immediately and not give it a second thought. But if you need to track a bug down weeks or months after writing the code, it can take a lot of work to figure out what the code does (and why), and why it is behaving incorrectly.

I’ve lost weeks to a memory leak once in javascript that was a 2 line change to fix. If I realised the problem when I wrote the code, I would have saved myself a lot of trouble.

Post reply on HN