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

91–100 of 165 posts

Re: Elixir and Rust is a good mix

#91

Post by throwawaymaths »

RhodesianHunter wrote: post #58
toast0 wrote: post #44

Earlier quoted context omitted.

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…

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

have you tried doing it in elixir? It's not that bad.

Re: Elixir and Rust is a good mix

#92

Post by freedomben »

RhodesianHunter wrote: post #58
toast0 wrote: post #44

Earlier quoted context omitted.

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…

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

Re: Elixir and Rust is a good mix

#93

Post by benatkin »

peregrine wrote: post #86
benatkin wrote: post #81

This makes me think of DotCloud, the precursor to Docker Inc. The idea that you can run anything has been around for a while. I don't see how Fly.io is especially good for Elixir. It seems to be about delivering reliable resources for each service, and it works no matter the web framework, as long as you have a PaaS that's geared towards running arbitrary OCI images. These posts seem a lot like the content on the Dig…

One of the interesting bits about Fly is we have our own servers distributed globally and connected via wireguard. Which makes it is trivial to setup Elixir/Erlang distribution globally, and most importantly, close to your customers. While its not a magic bullet it is pretty amazing to type a few commands have a globally deployed and directly distributed application. Further Fly builds its Dashboard internally with P…

That's just internal networking isn't it? VPC on the big clouds, DigitalOcean, and Vultr. Private Services on render.com.

I remember when Fly.io used to tout Firecracker but that is just a KVM engine, along with QEMU used on a zillion hosts.

What I'd like to see are customer success stories.

Edit: looks like you have to set up your own cross-region links on DigitalOcean and Vultr. So that interests me somewhat. :)

Re: Elixir and Rust is a good mix

#94

Post by throwawaymaths »

vlunkr wrote: post #48
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,…

Elixir is incredibly consistent with how it uses nil. It does take a bit of work -- you have to really pay attention to the convention of fetch! vs fetch vs get -- and often times library maintainers are not... always the best at that... but for all the problems that dynamic languages has, nil in elixir is pretty low on the list. I think I get bitten by maybe one a year, and it causes the sporadic report on sentry, and then I go and fix it, and that's that.

That access acts on nil is unfortunate, but it's necessary for things like get_in.

Re: Elixir and Rust is a good mix

#95

Post by freedomben »

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.

Interesting, I usually just write the SQL too in most projects, but in Elixir I love Ecto because it's so close to the SQL but has an elegant and powerful way to handle interpolated values.

Re: Elixir and Rust is a good mix

#96

Post by mtremsal »

This is amazing! The Gods have sent me the perfect excuse to finally read all the rust ebooks I’ve been collecting! I have a toy project where certain functions are CPU-bound and would make for a perfect learning project. Very timely read!

Re: Elixir and Rust is a good mix

#97

Post by jimbob45 »

bglusman wrote: post #46

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

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.

Re: Elixir and Rust is a good mix

#98

Post by freedomben »

maciejgryka wrote: post #37

Shameless plug & also a point of support for the article: I used that same stack to build https://regex.help/ (more details here https://maciej.gryka.net/building-regex-help )

Neat! You should definitely add a link to the github repo to the main page of regex.help though, because I didn't realize it was open source and I'll use it now.

Github link for others: https://github.com/maciejgryka/regex_help

Re: Elixir and Rust is a good mix

#99

Post by tessierashpool »

hexo wrote: post #60
lucasyvas wrote: post #56

Earlier quoted context omitted.

Is any of this needed though? For some use cases yes, but for many no. It's possible the parent has no practical use for these capabilities.

[flagged]

This is not helpful. Please consider what if might be like if you were to edit your comment to improve it.

Re: Elixir and Rust is a good mix

#100

Post by OkayPhysicist »

toast0 wrote: post #49
OkayPhysicist wrote: post #11

Earlier quoted context omitted.

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…

What's the benefit of a port driver over a NIF?
Post reply on HN