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

781–790 of 799 posts

Re: Migrating away from Rust

#781

Post by spookie »

fc417fc802 wrote: post #709
spookie wrote: post #701

Earlier quoted context omitted.

Huh wasn't aware of that. Nice. About the performance question, during the frag shader phase neighbouring pixels are already being tracked, so calling those is almost free. It would be difficult to match that performance when already on the compute phase.

That's just a matter of what's in cache. If your compute shader operates in coherent blocks it should generally be on par with the equivalent fragment shader. The potential exceptions are where access to dedicated hardware functionality is concerned. What I'm curious about is if there's a hardware intrinsic that computes derivatives or if the implementation of those opcodes is generally in software.

I chose to focus on the fact the frag stage is already tracking those changes because at that point it's basically free. And you don't need to worry too much.

To answer your question, which is very pertinent, they seem to use different hardware accelerated mechanisms. In the compute stage, wave based derivatives are used, and you need to account for different lane counts between GPU architectures.

Understanding that now makes me believe you're right. But one needs to benchmark them to be sure.

Re: Migrating away from Rust

#782

Post by Ygg2 »

scott_w wrote: post #778
Ygg2 wrote: post #773

Earlier quoted context omitted.

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.

> adding/subtracting by 1 is a billion times easier to understand than adding/subtracting 42.

Ok, then add start your indices with something else 1 or 2, -1 would be best but probably not well supported. Whatever you aren't used to.

Also why is substracting a small number such a problem? I never found adding/substracting 1, much more difficult than 42. It's just math.

Re: Migrating away from Rust

#783

Post by Ygg2 »

nl wrote: post #491
Ygg2 wrote: post #428

Earlier quoted context omitted.

> fight the borrow checker I see this and I am reminded when I had to fight the 0 indexing, when I was cutting my teeth in C, for class. I wonder why no one complains about 0 indexing anymore. Isn't it weird how you have to go 0 to length - 1, and implement algorithm differently than in a math book?

The ground floor in lifts isn't "1", it is "G". Same thing.

Actually some lifts don't start with G but -2, because basement exists.

Re: Migrating away from Rust

#784

Post by littlestymaar »

int_19h wrote: post #780
littlestymaar wrote: post #779

Earlier quoted context omitted.

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.

Neither is more ergonomic than Rust though.

You could add a lot of research/experimental and/or legacy languages as well (Modula 3, Odin, D, why not FORTRAN, even) but none of them are credible alternatives to C or C++ like Rust has managed to become. And none of them are polished enough (be it in terms of errors messages, libraries, docs, onboarding material, build toolchain) to be considered superior to Rust in terms of developer ergonomics even if you set aside safety.

And again, borrow checking isn't a feature, it's an implementation of the feature which is memory safety without performance tradeoff. Even when using a paradigm that doesn't interact with the borrow checker, you're still using the feature itself (especially because all of the underlying building blocks which aren't using ECS directly are benefiting from the borrow checker's validation).

Re: Migrating away from Rust

#785

Post by bmitc »

homebrewer wrote: post #760
bmitc wrote: post #745

Earlier quoted context omitted.

.NET is one of the easiest to install and robust cross-platform systems out there. It's actually very impressive. I don't know of a single other platform that nails cross-platform so well. The effort of .NET Framework to .NET Core to .NET 5 and now up to .NET 9 is well over a decade long of steady and increasing progress.

Compared to OpenJDK, dotnet: 1. only supports the three main operating systems and two architectures (or four if we're stretching things and being very generous) 2. large parts of it still don't work anywhere but Windows (UI being the primary one) 3. the level and quality of official tooling provided for Linux and macOS is incomparable to their Windows offerings No, its cross-platform story is far from the best we ha…

For (2), this is often misunderstood and mistated.

The JVM includes no GUI framework. .NET also includes no GUI framework. .NET happens to have a specific framework for Windows. But just like the JVM, there third-party GUI frameworks such as MAUI, Uno, Avalonia, and others.

So no, there's isn't a "large part" of .NET that isn't cross-platform.

> 3. the level and quality of official tooling provided for Linux and macOS is incomparable to their Windows offerings

What are you referring to here?

Re: Migrating away from Rust

#786

Post by scott_w »

Ygg2 wrote: post #782
scott_w wrote: post #778

Earlier quoted context omitted.

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

> adding/subtracting by 1 is a billion times easier to understand than adding/subtracting 42. Ok, then add start your indices with something else 1 or 2, -1 would be best but probably not well supported. Whatever you aren't used to. Also why is substracting a small number such a problem? I never found adding/substracting 1, much more difficult than 42. It's just math.

> Also why is substracting a small number such a problem? I never found adding/substracting 1, much more difficult than 42. It's just math.

If the answer to your question is not self-evident, then I don't know of any words that will convince you.

Re: Migrating away from Rust

#787

Post by 63stack »

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

Earlier quoted context omitted.

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.

No.

The structs sqlx creates through the macros are unnameable types, they are created on the fly at the invocation site. This means you can't return them without transforming them into a type you own (you declared), either through the FromRow derive, or writing glue code that associates this unnameable type's fields to your own struct's fields, leading to the boilerplate I was referring to. This is very specific to sqlx, don't try to dilute this into "other libraries are similar".

If you choose to forgo the macros, and use the regular .query() methods, then the results you get are tied to the lifetime of the sqlx connection object, which makes them unergonomic, which is again very specific to sqlx.

Re: Migrating away from Rust

#788

Post by 7bit »

mawadev wrote: post #244
bob1029 wrote: post #41

Earlier quoted context omitted.

> I am sure that is mostly access to additional external libraries that did things they wrote by hand in Rust This is the biggest reason I push for C#/.NET in "serious business" where concerns like auditing and compliance are non-negotiable aspects of the software engineering process. Virtually all of the batteries are included already. For example, which 3rd party vendors we use to build products is something that c…

In sectors that are critical here in the EU, nobody allows c# and microsoft due to licensing woes longterm. It's java and foss all the way down. SaaS also is not a thing unless it runs on prem.

That's absurdly wrong

Re: Migrating away from Rust

#789

Post by hresvelgr »

setr wrote: post #774
hresvelgr wrote: post #619

Earlier quoted context omitted.

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…

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

A pretty darn good model for what though and to what extent? For processing millions of objects, sure. For gameplay logic, using ECS for everything? I don't know about that. What I was implying with my comment is that ergonomics are the most important trait of a good game engine.

I reach for an ECS as a last resort when the performance of a gameplay system demands it, not before. Even before that I will tweak my gameplay code to be less wasteful.

Re: Migrating away from Rust

#790

Post by DarkmSparks »

int_19h wrote: post #721
DarkmSparks wrote: post #556

Earlier quoted context omitted.

Stuff that hooked me: you integrate it tightly with the engine so it only does game logic, making files small and very quick and easy to read. platform independent, no compiling, so can modify it in place on a release build of the game. the "everything is a table" approach is very easy to concept mentally means even very inexperienced coders can get up and running quickly. great exception handling, which makes most r…

FWIW if you really want to be able to edit code in-place on a live system, you can do that in C# with Roslyn without all that much effort. So much so, in fact, that it can be bolted onto an existing game written in C#. I did exactly that for Bannerlord: https://www.nexusmods.com/mountandblade2bannerlord/mods/1651

how well does that work with linux mac android and ios?
Post reply on HN