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

721–730 of 799 posts

Re: Migrating away from Rust

#721

Post by int_19h »

DarkmSparks wrote: post #556
Rohansi wrote: post #363

Earlier quoted context omitted.

What makes Lua the best for game logic? You don't even have types to help you out with Lua.

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

Re: Migrating away from Rust

#722

Post by Groxx »

neonsunset wrote: post #711
Groxx wrote: post #706

Earlier quoted context omitted.

To within a rounding error of zero, I don't think anyone outside Windows devs truly expects Microsoft to maintain .NET on other platforms, so it's not really an option in many (most?) fields. They've effectively dropped it a couple times in the past, and while they're currently putting effort in, the company as a whole does not seem to care about stuff like this beyond brief bursts of attention to try to win back dev…

> To within a rounding error of zero, I don't think anyone outside Windows devs truly expects Microsoft to maintain .NET on other platforms, so it's not really an option in many (most?) fields. This is provably wrong, unless you want to insist despite the facts because that's what your social bubble tells you to do. The most popular deployment target for .NET is Linux: https://dotnet.microsoft.com/en-us/platform/tele…

People use Microsoft open source stuff, definitely. It's fairly often decent or better.

But Microsoft's most consistent legacy across its entire existence has been Embrace, Extend, Extinguish. Any Linux-supporting project is directly opposed to their core business, aside from Azure - if it starts becoming a threat, they'll turn it into a way to force people onto their other money-makers.

Re: Migrating away from Rust

#724

Post by neonsunset »

Groxx wrote: post #722
neonsunset wrote: post #711

Earlier quoted context omitted.

> To within a rounding error of zero, I don't think anyone outside Windows devs truly expects Microsoft to maintain .NET on other platforms, so it's not really an option in many (most?) fields. This is provably wrong, unless you want to insist despite the facts because that's what your social bubble tells you to do. The most popular deployment target for .NET is Linux: https://dotnet.microsoft.com/en-us/platform/tele…

People use Microsoft open source stuff, definitely. It's fairly often decent or better. But Microsoft's most consistent legacy across its entire existence has been Embrace, Extend, Extinguish. Any Linux-supporting project is directly opposed to their core business, aside from Azure - if it starts becoming a threat, they'll turn it into a way to force people onto their other money-makers.

And so the broken record takes another turn...

Re: Migrating away from Rust

#725

Post by Groxx »

neonsunset wrote: post #724
Groxx wrote: post #722

Earlier quoted context omitted.

People use Microsoft open source stuff, definitely. It's fairly often decent or better. But Microsoft's most consistent legacy across its entire existence has been Embrace, Extend, Extinguish. Any Linux-supporting project is directly opposed to their core business, aside from Azure - if it starts becoming a threat, they'll turn it into a way to force people onto their other money-makers.

And so the broken record takes another turn...

When the broken record keeps predicting the future accurately, it's not claiming to be the next Nostradamus. History just repeats pretty consistently.

Re: Migrating away from Rust

#726

Post by int_19h »

gregschlom wrote: post #93
ninjis wrote: post #79

The "Learning" point drives home a concern my brother-in-law and I were talking about recently. As LLMs become more entrenched as a tool, they may inevitably become the crutch that actually holds back innovation. Individuals and teams may be hesitant to explore or adopt bleeding edge technologies specifically because LLMs don't know about them or don't know enough about them yet.

I was actually meaning to post this as an Ask HN question, but never found the time to word it well. Basically, what happens to new frameworks and technologies in the age of widespread LLM-assisted coding? Will users be reluctants to adopt bleeding-edge tools because the LLMs can't assist as well? Will companies behind the big frameworks put more resources towards documenting them in a way that makes it easy for LLMs…

This is already happening.

On one hand, yes, when it comes to picking tools for new projects, LLM awareness of them is now a consideration in large companies.

And at the same time, those same companies are willing to spend time and effort to ensure that their own tooling is well-represented in the training sets for SOTA models. To the point where they work directly with the corresponding teams at OpenAI etc.

And yes, it does mean that the barrier to entry for new competitors is that much higher, especially when they don't have the resources to do the same.

Re: Migrating away from Rust

#727

Post by int_19h »

SoKamil wrote: post #129
gwd wrote: post #97

Earlier quoted context omitted.

New languages / packages / frameworks may need to collaborate with LLM providers to provide good training material. LLM-able training material may be the next important documentation thing. Another potentially interesting avenue of research would be to explore allowing LLMs to use "self-play" to explore new things.

How can it compete with vast amount of trained codebases on Github? For LLMs, more data equals better results, so people will naturally be driven to better completion with already established frameworks and languages. It would be hard to produce organic data on all ways your technology can be (ab)used.

In a similar way to how this works for natural languages. Turns out that if you train the model on e.g. vast quantities of English, teaching it other languages doesn't require nearly as much, because it has already internalized all the "shared" parts (and there's a lot more of those than there are surface differences).

But, yes, it does mean that new things that are drastic breaks with old practices are much harder to teach compared to incremental improvements.

Re: Migrating away from Rust

#728

Post by int_19h »

pclmulqdq wrote: post #75
littlestymaar wrote: post #57

Earlier quoted context omitted.

Borrow checker is mostly a strawman for this discussion, the post is about using Bevy as an engine and Bevy uses an ECS than manages the lifetime of objects for you automatically. You will never have an issue with the borrow checker when using Bevy, not even once.

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?

Re: Migrating away from Rust

#729

Post by int_19h »

yyyk wrote: post #501
neonsunset wrote: post #473

Earlier quoted context omitted.

Structs in C# or F# are not low-level per se, they simply are a choice and used frequently in gamedev. So is stackalloc because using it is just 'var things = (stackalloc Thing[5])' where the type of `things` is Span . The keyword is a bit niche but it's very normal to see it in code that cares about avoiding allocations. Note that going more hands-on with these is not the same as violating memory safety - C# even ha…

Right, it depends on how far one wants to go to avoid allocations. structs and spans are safe. But one can go even deeper and pin pointers and do Unsafe.AsPointer and get a de-facto (unsafe) union out of it.... > https://em-tg.github.io/csborrow/ Oooh... I didn't know scoped refs existed.

If you want an unsafe union, that's what StructLayout.Explicit and FieldOffset is for - a struct with all fields placed at offset 0 is exactly the same as a C union.

Re: Migrating away from Rust

#730

Post by Ygg2 »

tremon wrote: post #604
Ygg2 wrote: post #490

Earlier quoted context omitted.

Maths books aren't being weird. They are counting in a way most people learn to count. One apple, two apples, three apples. You don't start zeroth apple, one apple, two apples, then respond the set of apple contains three apples.

But computers are not actually counting array elements, it's more accurate to compare array indexing with distance measurement. The pointer (memory address) puts you at the start of the array, so the first element is right there under your feet (i.e. index 0). The other elements are found by measuring how far away from the start they are: element_position = start + index*element_size

> But computers are not actually counting array elements

Sure. But from most general to least general, it goes:

Counting on fingers >>>> Math Equations >> Computer algorithms

The more general ones influence the less general ones because that's where most people start.

Post reply on HN