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

751–760 of 799 posts

Re: Migrating away from Rust

#751

Post by delifue »

WhyNotHugo wrote: post #606
Animats wrote: post #231

Another failed game project in Rust. This is sad. I've been writing a metaverse client in Rust for almost five years now, which is too long.[1] Someone else set out to do something similar in C#/Unity and had something going in less than two years. This is discouraging. Ecosystem problems: The Rust 3D game dev user base is tiny. Nobody ever wrote an AAA title in Rust. Nobody has really pushed the performance issues.…

> > The lower levels are buggy and have a lot of churn > > The stack I use is Rend3/Egui/Winit/Wgpu/Vulkan The same is true if you try to make GUI applications in Rust. All the toolkits have lots of quirky bugs and broken features. The barrier to contributing to toolkits is usually also pretty high too: most of them focus on supporting a variety of open source and proprietary platforms. If you want to improve on some…

The "if I then go and code in Python, Java or C#, pretty much all objects have the overhead of an Arc" is not accurate. Rust Arc involves atomic operation and its preformance can greatly degrade when the reference count is being mutated by many threads. See https://pkolaczk.github.io/server-slower-than-a-laptop/

Java, C# and Go don't use atomic reference counting and don't have such overhead.

Re: Migrating away from Rust

#752

Post by delifue »

Charon77 wrote: post #377
Animats wrote: post #231

Another failed game project in Rust. This is sad. I've been writing a metaverse client in Rust for almost five years now, which is too long.[1] Someone else set out to do something similar in C#/Unity and had something going in less than two years. This is discouraging. Ecosystem problems: The Rust 3D game dev user base is tiny. Nobody ever wrote an AAA title in Rust. Nobody has really pushed the performance issues.…

A owns B, and B can find A I think you should think less like Java/C# and more like database. If you have a Comment object that has parent object, you need to store the parent as a 'reference', because you can't put the entire parent. So I'll probably use Box here to refer to the parent

If you use Box to refer to parent, then parent cannot own the child (unless using things like Arc>).

Re: Migrating away from Rust

#753

Post by palata »

koakuma-chan wrote: post #733
palata wrote: post #723

Earlier quoted context omitted.

You are one of those people stuck in the 90s, then. Take 5 min to read about JIT and AOT compilation.

What point are you trying to make? V8 has a JIT compiler too, does that make JavaScript a compiled language?

If you run JavaScript with a JIT compiler, you can't say "it is slow because it is interpreted". And it is obviously wrong to say "V8 is slow because it is an interpreter", isn't it?

Re: Migrating away from Rust

#754

Post by willtemperley »

vips7L wrote: post #749
willtemperley wrote: post #652

Earlier quoted context omitted.

It's a cherry picked, out-of-date counter-example. Swift isn't designed for building drivers. In reality, a lot of Swift apps are delegating to C code. My own app (in development) does a lot of processing, almost none of which happens in Swift, despite the fact I spend the vast majority of my time writing Swift. Swift an excellent C glue language, which Java isn't. This is why Swift will probably become an excellent…

> It's a cherry picked, out-of-date counter-example. Swift isn't designed for building drivers Do you have a counter benchmark? The burden is on you here to disprove the data presented. What that benchmark shows is that you spend A TON of time counting references, much more than tracing GC, unless you enter Swifts C++ networking code. I would think games don’t spend most of their time calling into networking code. >…

> I would think games don’t spend most of their time calling into networking code.

Exactly. That is why the out-of-date networking example being touted as evidence is irrelevant here.

What it boils down to is that Java and C have fundamentally incompatible memory models. Direct access to C memory is impossible because of the managed heap and GC.

> I would take this bet that it won’t. Purely on the sheer fact that gaming occurs on Windows and Swift is barely capable there.

This is a very odd comment - gaming occurs in a lot of places. Quite a lot happens on mobile these days. Turns out a lot of mobile devices run Swift, on which it appears to be reasonably capable.

Re: Migrating away from Rust

#755

Post by weksf54 »

vips7L wrote: post #703
cies wrote: post #650

Earlier quoted context omitted.

So they are there, but ugly to define: public abstract sealed class Vehicle permits Car, Truck { public Vehicle() {} } public final class Truck extends Vehicle implements Service { public final int loadCapacity; public Truck(int loadCapacity) { this.loadCapacity = loadCapacity; } } public non-sealed class Car extends Vehicle implements Service { public final int numberOfSeats; public final String brandName; public Ca…

You implemented this much more verbosely than needed sealed interface Vehicle { record Truck(int loadCapacity) implements Vehicle {} record Car(int numberOfSeats, String brandName) implements Vehicle {} }

Ah! Thanks, I didn't know that. I should have RTFMD better - https://docs.oracle.com/en/java/javase/21/language/sealed-cl...

Turns out you can do this and not have the annoying inner class e.g. Vehicle.Car too:

  package com.example.vehicles;

  public sealed interface Vehicle
      // The permits clause has been omitted
      // as its permitted classes have been
      // defined in the same file.
  { }
  record Truck(int loadCapacity) implements Vehicle {}
  record Car(int numberOfSeats, String brandName) implements Vehicle {}

Re: Migrating away from Rust

#756

Post by DanielHB »

3np wrote: post #550
DanielHB wrote: post #535

Earlier quoted context omitted.

I wrote a few benchmarks a few years ago comparing JS vs C++ compiled to WASM vs C++ compiled to x64 with -O3. I was surprised that the heaviest one (a lot of float math) run about the same speed in JS vs C++ -> x64. The code was several nested for loops manipulating a buffer and using only local-scoped variables and built-in Math library functions (like sqrt) with no JS objects/arrays besides the buffer. So the code…

I've also seen Cython used to this effect for hotspots or entire applications in scientific Python code.

I am not super familiar with python but that sounds quite annoying to set up in the build process. You would need to compile different files/modules using a different compiler right?

Re: Migrating away from Rust

#757

Post by pjmlp »

ryao wrote: post #696
pjmlp wrote: post #678

Earlier quoted context omitted.

Because C++ was "TypeScript for C", plenty of room to improvement that WG 14 refuses to act on for the last 50 years. Yes, most language features past the C89 subset are not supported, besides the C standard library, because C++ has much better alternatives, like why _Generic when templates are a much saner approach, than type dispatching with the pre-processor. However that is besides the point, 99% of C89 code minu…

C, unlike C++, does not really force new versions onto you, even if dependencies begin using them. That said, Linux switched to C11. Newer versions of C will gradually be adopted, despite the incompatibilities this causes for C++. As for WG 14, they incorporated numerous C++isms into C. While you claim that they did not go far enough, I am sure you will find many who would say that they went too far.

I very much doubt it, when someone decides to make full of use of recent ISO C on a C library header file.

I claim they aren't focused on what matters, we don't need C++isms into C, we already have C++, and C should have been done as language back in C89.

Anyone that wanted more has always been able to use C++ instead, or Objective-C on Apple/NeXT land.

What we need is for WG14 to finally take security regarding strings, arrays seriouslys, not yet another reboot of functions using (ptr, length) pairs.

Re: Migrating away from Rust

#758

Post by pjmlp »

willtemperley wrote: post #754
vips7L wrote: post #749

Earlier quoted context omitted.

> It's a cherry picked, out-of-date counter-example. Swift isn't designed for building drivers Do you have a counter benchmark? The burden is on you here to disprove the data presented. What that benchmark shows is that you spend A TON of time counting references, much more than tracing GC, unless you enter Swifts C++ networking code. I would think games don’t spend most of their time calling into networking code. >…

> I would think games don’t spend most of their time calling into networking code. Exactly. That is why the out-of-date networking example being touted as evidence is irrelevant here. What it boils down to is that Java and C have fundamentally incompatible memory models. Direct access to C memory is impossible because of the managed heap and GC. > I would take this bet that it won’t. Purely on the sheer fact that gam…

And 70% of the mobile world runs Android, which is powered by Java, so it is equally capable.

Re: Migrating away from Rust

#759

Post by willtemperley »

pjmlp wrote: post #758
willtemperley wrote: post #754

Earlier quoted context omitted.

> I would think games don’t spend most of their time calling into networking code. Exactly. That is why the out-of-date networking example being touted as evidence is irrelevant here. What it boils down to is that Java and C have fundamentally incompatible memory models. Direct access to C memory is impossible because of the managed heap and GC. > I would take this bet that it won’t. Purely on the sheer fact that gam…

And 70% of the mobile world runs Android, which is powered by Java, so it is equally capable.

Android does not run Java and you know that.

https://omeraydin.dev/blog/does-android-run-java

Re: Migrating away from Rust

#760

Post by homebrewer »

bmitc wrote: post #745
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…

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

https://wiki.openjdk.org/display/HotSpot/Ports

Post reply on HN