Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating away from Rust

deadmoney.gg

Post reply on HN
Print view View original

771–780 of 799 posts

Re: Migrating away from Rust

#771

Post by wyager »

goku12 wrote: post #496
wyager wrote: post #346

Earlier quoted context omitted.

I write a lot of Rust, but as you say, it's basically a vastly improved version of C++. C++ is not always the right move! For all my personal projects, I use a mix of Haskell and Rust, which I find covers 99% of the product domains I work in. Ultra-low level (FPGA gateware): Haskell. The Clash compiler backend lets you compile (non-recursive) Haskell code directly to FPGA. I use this for audio codecs, IO expanders, a…

What do you mean by 'a mix of Haskell and Rust'? Is that a per-project choice or do you use both in a single project? I'm interested in the latter. If so, could you point me to an example? Another question is about Clash. Your description sounds like the HLS (high level synthesis) approach. But I thought that Clash used a Haskell -based DSL, making it a true HDL. Could you clarify this? Thanks!

Yeah, sometimes I'll do e.g. a backend state management server in Haskell and then a lightweight (embedded) client in Rust. I haven't ever tried linking rust from haskell yet, if that's what you mean.

I would actually flip your HDL definition a bit. Clash is a true HDL, but specifically because it's not just a shallowly embedded DSL.

Clash is actually a GHC plugin that compiles haskell code to a synchronous circuit representation and then can spit that out as whatever HDL you like. It's emphatically not just a library for constructing circuit descriptions, like most new gateware development tools. This is possible because the semantics of Haskell are (by a mixture of good first-principles design and luck) an almost exact match for the standard four-state logic semantics of synchronous digital circuits.

This is also different from the standard HLS approach where the semantics of the source language do not at all match the semantics of the target. With Haskell, they are (surprisingly) very close! Only in a few edge cases (mostly having to do with zero-bit wires and so on) does the evaluation semantics of haskell differ from the evaluation semantics of e.g. verilog.

Re: Migrating away from Rust

#772

Post by scott_w »

Ygg2 wrote: post #768
scott_w wrote: post #713

Earlier quoted context omitted.

I literally just described my process, so I don’t get how you got to “you don’t know how you know” because… well… I just told you. Also, there’s a huge difference between beginners not understanding 0-based indexing and experienced C++ engineers describing the challenges understanding Rust’s unique features. I mean, Jesus Christ, we’re commenting on a thread here of experienced engineers commenting on how challenging…

> Also, there’s a huge difference between beginners not understanding 0-based indexing and experienced C++ engineers describing the challenges understanding Rust’s unique features Keep in mind I wasn't new to programming at that point. I was programming in C64 basic for 3 years and Pascal for 3 as well. For hobby of course, and not fully. Zero indexes aren't simple, they are intertwined everywhere but they are easy -…

> What you could do is take a language that has arbitrary starting index value and set it to something weird. Like 42 or -5. Then rewrite your programs. See how many off by 41 errors you make. Then once you no longer make mistakes with it. Go back to 0 indexes.

Do you need me to comment on the difference between 0 and 42?

Re: Migrating away from Rust

#773

Post by Ygg2 »

scott_w wrote: post #772
Ygg2 wrote: post #768

Earlier quoted context omitted.

> Also, there’s a huge difference between beginners not understanding 0-based indexing and experienced C++ engineers describing the challenges understanding Rust’s unique features Keep in mind I wasn't new to programming at that point. I was programming in C64 basic for 3 years and Pascal for 3 as well. For hobby of course, and not fully. Zero indexes aren't simple, they are intertwined everywhere but they are easy -…

> What you could do is take a language that has arbitrary starting index value and set it to something weird. Like 42 or -5. Then rewrite your programs. See how many off by 41 errors you make. Then once you no longer make mistakes with it. Go back to 0 indexes. Do you need me to comment on the difference between 0 and 42?

No.

But you need to see with eyes of a newbie. I mean what is the problem here, you did say it's just adding or subtracting a number whether it's 0, 1, -1 or 42? Should be trivial, right?

My guess while the change of indices is simple (altering ranges by a constant), it's going to be hard (requiring constant mental effort until it's internalized).

Re: Migrating away from Rust

#774

Post by setr »

hresvelgr wrote: post #619
12_throw_away wrote: post #110

More than anything else, this sounds like a good lesson in why commercial game engines have taken over most of game dev. There are so many things you have to do to make a game, but they're mostly quite common and have lots of off-the-shelf solutions. That is, any sufficiently mature indie game project will end up implementing an informally specified, ad hoc, bug-ridden implementation of Unity (... or just use the inf…

I think this has less to do with Rust and commercial game engines being better and more of a fetish that game programmers seem to have for entity component systems. One does not have to look far to see similar projects repeated in C++ years prior.

ECS is basically the realization that relational databases are a pretty damn good model.

I’m suspicious though that you could probably get away with literally just using like an in-memory duckdb to store your game state and get most of the performance/modeling value while also getting a more powerful/robust query engine — especially for like turn-based games. I’m also not sure that bevy’s encoding of queries into the type system is all that sane — as opposed to something like query building with LINQ, but I think it’s how they get to resolve the system dependency graph for parallelization

Re: Migrating away from Rust

#775

Post by ben-schaaf »

63stack wrote: post #603
ben-schaaf wrote: post #304

Earlier quoted context omitted.

Building a proper ORM is hard. Querying a database is not. See the postgres crate for an example. Querying a database while ensuring type safety is harder, but you still don't need an OEM for that. See sqlx.

Sqlx is completely lacking in the query composability department, and leads to a very large amount of boilerplate. You can derive FromRow for your structs to cut down the boilerplate, but if you need to join two tables that happen to have a column with the same name it stops working, unless you remember to _always_ alias one of the columns to the same name, every time you query that table from anywhere (even when the…

You don't need to derive anything, sqlx creates structs with the query results for you. The rest of your complaints are just the natural consequence of SQL's design. sqlx is no more difficult to use than similar libraries in other languages.

Re: Migrating away from Rust

#776

Post by littlestymaar »

int_19h wrote: post #728
pclmulqdq wrote: post #75

Earlier quoted context omitted.

Everything in every ECS system is done with handles, but the parent comment is correct that many games use hairballs of pointers all over the place (and they are handles with ECS). There is never a borrow checker issue with handles since they divorce the concept of a pointer from the concept of ownership.

But then the question becomes - why Rust, if you deliberately work around its single most prominent distinguishing feature?

The main feature of rust isn't borrow checking, the feature is safe low level programming. Borrow checking is Rust's default way of doing this, but it's not the only one (the standard library has Reference Counting primitives built in).

Borrow checking is a way to make manual memory management safe, ECS works around manual memory management entirely, so it doesn't need borrow checking to be safe (which is also why it's popular in C++, which doesn't have a borrow checker) but because it's Rust, you have strong guarantees about the safety of it, while in C++ you can still shoot yourself in the foot if you don't use ECS the right way.

Also Rust is more than safety: https://steveklabnik.com/writing/rust-is-more-than-safety

Re: Migrating away from Rust

#777

Post by int_19h »

littlestymaar wrote: post #776
int_19h wrote: post #728

Earlier quoted context omitted.

But then the question becomes - why Rust, if you deliberately work around its single most prominent distinguishing feature?

The main feature of rust isn't borrow checking, the feature is safe low level programming . Borrow checking is Rust's default way of doing this, but it's not the only one (the standard library has Reference Counting primitives built in). Borrow checking is a way to make manual memory management safe, ECS works around manual memory management entirely, so it doesn't need borrow checking to be safe (which is also why i…

I would argue that borrow checking is the only feature that is actually unique (more or less) to Rust. If you don't need it, you can get the rest from elsewhere, often with better ergonomics.

Re: Migrating away from Rust

#778

Post by scott_w »

Ygg2 wrote: post #773
scott_w wrote: post #772

Earlier quoted context omitted.

> What you could do is take a language that has arbitrary starting index value and set it to something weird. Like 42 or -5. Then rewrite your programs. See how many off by 41 errors you make. Then once you no longer make mistakes with it. Go back to 0 indexes. Do you need me to comment on the difference between 0 and 42?

No. But you need to see with eyes of a newbie. I mean what is the problem here, you did say it's just adding or subtracting a number whether it's 0, 1, -1 or 42? Should be trivial, right? My guess while the change of indices is simple (altering ranges by a constant), it's going to be hard (requiring constant mental effort until it's internalized).

> I mean what is the problem here, you did say it's just adding or subtracting a number whether it's 0, 1, -1 or 42? Should be trivial, right?

Apparently I do need to comment but I don't think any human on earth has the words to convince you that, as a human, adding/subtracting by 1 is a billion times easier to understand than adding/subtracting 42.

Re: Migrating away from Rust

#779

Post by littlestymaar »

int_19h wrote: post #777
littlestymaar wrote: post #776

Earlier quoted context omitted.

The main feature of rust isn't borrow checking, the feature is safe low level programming . Borrow checking is Rust's default way of doing this, but it's not the only one (the standard library has Reference Counting primitives built in). Borrow checking is a way to make manual memory management safe, ECS works around manual memory management entirely, so it doesn't need borrow checking to be safe (which is also why i…

I would argue that borrow checking is the only feature that is actually unique (more or less) to Rust. If you don't need it, you can get the rest from elsewhere, often with better ergonomics.

If you don't care about performance, then sure.

If you want to squeeze the maximum performance of your hardware (which is indeed the case for game engines) then all your options are Rust, C and C++. In which case is by far the more ergonomic choice on every aspects.

Re: Migrating away from Rust

#780

Post by int_19h »

littlestymaar wrote: post #779
int_19h wrote: post #777

Earlier quoted context omitted.

I would argue that borrow checking is the only feature that is actually unique (more or less) to Rust. If you don't need it, you can get the rest from elsewhere, often with better ergonomics.

If you don't care about performance, then sure. If you want to squeeze the maximum performance of your hardware (which is indeed the case for game engines) then all your options are Rust, C and C++. In which case is by far the more ergonomic choice on every aspects.

Or Zig. Or (if you want a stable, proven solution) Ada.
Post reply on HN