Live data from Hacker News

Migrating away from Rust

deadmoney.gg

641–650 of 799 posts

Re: Migrating away from Rust

#641
post #520

Earlier quoted context omitted.

I'd rather write rust than java, personally

Note that I mentioned JVM languages. There is Scala, Kotlin and others. Kotlin is the default for Android, and it is really nice.

Kotlin is nice indeed. Most of the issues I had with it were in interop with Java code (those pesky platform types, that behave like non-nullable but are nullable: and you are back in the NPE swamp!)

Re: Migrating away from Rust

#642
post #564

Earlier quoted context omitted.

I think the choice of C++ vs JVM depends on your project. If you're not using the benefits of "unsafe" languages then it probably doesn't matter. But if you are after performance how do do the following in Java? - Build an AOS so that memory access is linear re cache. Prefetch. Use things like _mm_stream_ps() to tell the CPU the cache line you're writing to doesn't need to be fetched. Share a buffer of memory between…

> but there is a reason that commercial gamedev is typically C++. Sure, and that's kind of my point. There are a few use-cases where C++ is actually needed, and for those cases, Rust (the language) is a good alternative if it's possible to use it. But even for gamedev, the article here says that they moved to Unity. The core of Unity is apparently C++, but users of Unity code in C#. Which kind of proves my point: out…

We were using a modified Luajit, in assembly, with a bit of other assembly dotted around the place. That assembly takes a long time to write (to beat a modern C++ compiler).

Then we had C++ for all our low level code and Lua for gameplay.

We were floating a middle layer of Rust for Lua bindings and the glue code for our transformation pipeline, but there was always a little too much friction to introduce. What we were particularly interested in was memory allocation bugs (use after free and leaks) and speeding up development of the engine. So I could see it having a place.

Re: Migrating away from Rust

#643
post #593

Earlier quoted context omitted.

People that haven't tried this are downvoting with prejudice, but they just don't know. Rust is an absolute gem at web backend. An absolute fucking gem.

We know, it stil isn't at Spring/ASP.NET level, coupled with Scala/Kotlin/F#.

I hate Spring(Boot): too much magic due to overuse of annotations.

On the JVM I'd prefer Kotlin/http4k/SQLDelight any day over {Java,Kotlin}/Spring(Boot)/{Hibernate,sql-in-strings}.

Re: Migrating away from Rust

#644
post #634

Earlier quoted context omitted.

Can you speak more of this best in class tooling?

The official `go` command does dep management, (cross) compilation, testing (including benchmarks and coverage reports), race detection, profiling reports, code generation (metaprogramming alternative), doc generation etc. Build times are insanely fast too. The only tooling I use personally outside of the main CLI is building iOS/Android static libraries (gomobile). It’s still first party, but not in the go command.

I haven't tried Go in a while, but 8 years ago, I felt the tooling was a disaster. The V1 ways of doing things were really janky, and the improved versions didn't seem to be universally adopted yet. It's nice to hear that seems to have changed.

Re: Migrating away from Rust

#645
post #208

I really like Rust as a replacement for C++, especially given that C++ seems to become crazier every year. When reasonable, nowadays I always use Rust instead of C++. But for the vast majority of projects, I believe that C++ is not the right language, meaning that Rust isn't, either. I feel like many people choose Rust because is sounds like it's more efficient, a bit as if people went for C++ instead of a JVM langua…

VPS/Cloud providers skimp on RAM. The JVM sucks for any low RAM workload, where you want the smallest possible single server instance. The startup times of JVM based applications are also horrendous. How many gigabytes of RAM does Digital Ocean give you with your smallest instance? They don't. They give you 512MiB. Suddenly using Java is no longer an option, because you will be wasting your day carefully tuning literally everything to fit in that amount.

Re: Migrating away from Rust

#646
post #643
post #593

Earlier quoted context omitted.

We know, it stil isn't at Spring/ASP.NET level, coupled with Scala/Kotlin/F#.

I hate Spring(Boot): too much magic due to overuse of annotations. On the JVM I'd prefer Kotlin/http4k/SQLDelight any day over {Java,Kotlin}/Spring(Boot)/{Hibernate,sql-in-strings}.

Because macro magic, or compiler plugins, is so much better, I guess.

Re: Migrating away from Rust

#647
post #599

Earlier quoted context omitted.

C# has aged better but I feel like Java 8 approaching ANSI C level solid tools. If only Swing wasn't so ugly. They should poach Raymond Chen to make Java 8 Remastered I like his blog posts. There's probably a DOS joke in there. Also they should just use the JavaFX namespace so I don't have to change my code and I want the lawyer here to laugh too.

Java current version is 24.

Java's current version is Kotlin /joke

Re: Migrating away from Rust

#648
post #570

Earlier quoted context omitted.

While there are many technical reasons to use C++ over Java in game development, many commercial games could be easily done in Java, as they are A or AA level at most. Had Notch thought too much about which language to use, maybe he would still be trying to launch a game today.

Minecraft was Indie then. And anyway, it's now in C++.

Literally no one who has access to the Java version cares even a little bit about Minecraft bedrock edition.

Re: Migrating away from Rust

#649

Earlier quoted context omitted.

> These crates also get "refactored" every few months, with breaking API changes I am dealing with similar issues in npm now, as someone who is touching Node dev again. The number of deprecations drives me nuts. Seems like I’m on a treadmill of updating APIs just to have the same functionality as before.

I wish for ecosystems that would let maintainers ship deprecations with auto-fixing lint rules.

They do. They're called stable, versioned interfaces and work in any language

Re: Migrating away from Rust

#650
post #581

Earlier quoted context omitted.

Does Java have sum types now?

Yes via sealed classes. It also has pattern matching.

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 Car(int numberOfSeats, String brandName) {
        this.numberOfSeats = numberOfSeats;
        this.brandName = brandName;
      }
    }

In Kotlin it's a bit better, but nothing beats the ML-like langs (and Rust/ReScript/etc):

    type Truck = { loadCapacity: int }
    type Car = { numberOfSeats: int, brandName: string }
    type Vehicle = Truck | Car
Post reply on HN