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

High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

hamy.xyz

Post reply on HN
Print view View original

31–40 of 122 posts

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#31

Post by bluegatty »

loglog wrote: post #29
bluegatty wrote: post #27

Java is a fine language and has sufficiently expressive types. It's the most consistently overlooked language and frankly it's completely annoying. Java is a powerhouse. If you can live with a VM, it's an amazing language. The disdain for Java is honestly just weird. The boiler plate is only marginally annoying to write and makes it considerably easier to read. The 'enterprise ecosystem' is definitely bloat, but that…

1. Java is mentioned in their comparison table. They just don't use it much. 2. There is really no reason to include Java in the search for your preferred language, since Kotlin is strictly better along every relevant axis.

Kotlin is a few tweaks on top of Java, most of which aren't relevant anymore, and it's not strictly better in most ways other than saving a few keystrokes (and preference).

It's a little bit nicer to write but that's almost irrelevant.

It also comes with some runtime cruft.

In reality there is no Kotlin without Java, which means most projects end up a bit 'dual'; every single Kotlin project we've had (except Android) folded back onto Java. Even Scala wasn't worth it, though that's a different question.

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#32

Post by PhilippGille »

jurschreuder wrote: post #11

I program almost all languages except C# and Rust haha. So someone looking for the perfect languages while actively using the only two languages I actively avoid is very strange to me. C# has close to zero community and only really works properly in Windows which is far past its glory days. Except for Microsoft aggressively pushing it as a Java alternative it has no right to exist. Rust is an overcomplicated subset o…

> C# [...] only really works properly in Windows

What do you mean with this? Maybe you are thinking of the old ".NET Framework" runtime, which only runs on Windows? Nowadays there is ".NET Core" which runs on macOS and Linux as well.

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#33

Post by teaearlgraycold »

Tade0 wrote: post #16

Regarding TypeScript: > but types lie at runtime (unsound) requiring you to add your own runtime checks. I don't recall doing that outside of situations when data is crossing system boundaries. The vast majority of languages have an unsound type system, yet people are productive in them. Over the years I've come to realise it's a form of nitpicking. You absolutely need it in some applications, but it's not an importa…

The main problem with TypeScript is the default compiler flags are not safe. I understand having things weak when you’re getting the ecosystem up and running, before you have wide adoption. You don’t want to throw too many red squigglies at early adopters and cause them to give up. But these days the default should not allow any. No implicit any. No explicit any. The stdlib should not use it. JSON.parse() should return either unknown or a recursive union that defines all valid JSON structures.

I believe it’s largely because of these defaults that the idea that TypeScript isn’t really checking types persists. Without the any type, or loose undefined and null checks, your types are as validated as they can be. The only failure point is deserialization or an import which doesn’t type check. And deserialization has this problem in every language.

When you compile C to machine code the executed binary isn’t checking types. This is no different from Typescript that’s been compiled to JavaScript.

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#34

Post by indigo945 »

VorpalWay wrote: post #10
ysleepy wrote: post #6

I agree that the rust community frowns a little too much on the use of Arc/Cloning/Box. If you use swift, everything is ref counted, why subject yourself to so much pain for marginal gain. Tutorials and books should be more open about that, instead of pushing complex lifetime hacks etc., also show the safe and easy ways. The article gives Java a worse devx rank than Go and I can't agree. Java is at least on par with…

> I agree that the rust community frowns a little too much on the use of Arc/Cloning/Box As usual, this depends heavily on what you do. I had written a program where Arc reference counting was 25 % of the runtime. All from a single instance as well. I refactored to use borrows and annotated relevant structs with lifetimes. This also enabled additional optimisation where I could also avoid some copies, and in total I…

For the use cases outlined in the OP, a 36% performance gain for an optimization that complex would be considered a waste of time. OP was explicitly not talking about code that cares about the performance of its hot path that much. Most applications spend 90% of their runtime waiting for IO anyway, so optimizations of this scale don't do anything.

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#35

Post by alkonaut »

I also kind of wish Rust had a two-tier system where you could opt into (or out of) the full thing.

The lighter version he describes would make some assumptions that reduce not just the mental overhead but importantly the _syntax_ overhead. You cant have Arc if what you describe is an Animal and the readability is infinitely more important than performance. But if you could create a system where in the lighter Swift/C#-like syntax things are automatically cloned/boxed while in the heavier Rust they aren’t, then maybe you could use Rust everywhere without a syntax tax.

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#36

Post by sargunv »

teaearlgraycold wrote: post #33
Tade0 wrote: post #16

Regarding TypeScript: > but types lie at runtime (unsound) requiring you to add your own runtime checks. I don't recall doing that outside of situations when data is crossing system boundaries. The vast majority of languages have an unsound type system, yet people are productive in them. Over the years I've come to realise it's a form of nitpicking. You absolutely need it in some applications, but it's not an importa…

The main problem with TypeScript is the default compiler flags are not safe. I understand having things weak when you’re getting the ecosystem up and running, before you have wide adoption. You don’t want to throw too many red squigglies at early adopters and cause them to give up. But these days the default should not allow any. No implicit any. No explicit any. The stdlib should not use it. JSON.parse() should retu…

Even with strict flags on, there are failures. A trivial example:

  function mutateArray(
    arr: (string | number)[]
  ) {
    arr.push(1);
  }
  const a: string[] = ["one", "two"];
  mutateArray(a);
a is now a string[] with a number inside

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#37

Post by rounce »

nananana9 wrote: post #21

Most of the Rust code I've read is arc-mutex-slop. What this optimizes for is not actually having to deal with the pain in the ass that proper Rust is, but still allowing you to be in the cool kids club writing "blazingly fast software", all while writing what's pretty much Java or C#, but with a terrible non-functional garbage collector instead of a state of the art one.

> terrible non-functional garbage collector

What garbage collector?

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#38

Post by teaearlgraycold »

sargunv wrote: post #36
teaearlgraycold wrote: post #33

Earlier quoted context omitted.

The main problem with TypeScript is the default compiler flags are not safe. I understand having things weak when you’re getting the ecosystem up and running, before you have wide adoption. You don’t want to throw too many red squigglies at early adopters and cause them to give up. But these days the default should not allow any. No implicit any. No explicit any. The stdlib should not use it. JSON.parse() should retu…

Even with strict flags on, there are failures. A trivial example: function mutateArray( arr: (string | number)[] ) { arr.push(1); } const a: string[] = ["one", "two"]; mutateArray(a); a is now a string[] with a number inside

Very interesting. I’m shocked the typescript creators built a system with this failure mode. I guess the solution here is to have tsc change the type of “a” after the call to mutateArray, unless the arr argument is marked as readonly.

Is there a name for this failure mode?

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#39

Post by sargunv »

teaearlgraycold wrote: post #38
sargunv wrote: post #36

Earlier quoted context omitted.

Even with strict flags on, there are failures. A trivial example: function mutateArray( arr: (string | number)[] ) { arr.push(1); } const a: string[] = ["one", "two"]; mutateArray(a); a is now a string[] with a number inside

Very interesting. I’m shocked the typescript creators built a system with this failure mode. I guess the solution here is to have tsc change the type of “a” after the call to mutateArray, unless the arr argument is marked as readonly. Is there a name for this failure mode?

I'm not aware of a name, but I'm also curious if there is one because I had a hard time searching for it.

I came across it on ThePrimeagen's YouTube channel: https://youtu.be/u1WmiqlrqL0

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#40

Post by hackingonempty »

usrnm wrote: post #18
hackingonempty wrote: post #9

F# but not Scala? In TFA F# is only lacking in community and ecosystem. Scala is comparable in popularity to Go or Rust and has access to the entire Java ecosystem and JVM runtime. That should give it the five stars the author is looking for but its not considered. I think a lot of devs are missing out by not considering Scala 3. I use it with the Zio effect system which brings composable concurrency and transactiona…

> Scala is comparable in popularity to Go or Rust Do you have any numbers to back you up? That statement sounds very, very wrong to me

Not good ones, and Scala devs are keenly aware they have been going in the wrong direction compared to Go/Rust, in part because of articles like this.

RedMonk shows Scala is comparable to Go and Rust [0] You can see in this chart which plots the number of projects on Github and tags on StackOverflow (ha ha.)

The upper right most cluster has the most popular languages (C++, Java, Python, JS, PHP, TypeScript) then the next cluster has Scala with Rust, Go, Kotlin, R, Swift, etc... That cluster is clearly separate from the next less popular one which has Haskell, Lua, Ocaml, Groovy, Erlang, Fortran, etc... and then you can see the long tail is a big cluster covering the entire lower left half of the chat with a clear gap between it and the upper right half.

I don't think it is a "very, very wrong" statement.

[0] https://redmonk.com/sogrady/files/2025/06/lang.rank_.125.wm_... which comes from https://redmonk.com/sogrady/2025/06/18/language-rankings-1-2...

Post reply on HN