alt.hn

4/11/2026 at 11:30:40 PM

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

 https://hamy.xyz/blog/2026-01_high-level-rust

by maxloh

4/12/2026 at 7:06:40 AM

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 transactional memory amongst other features. I don't think there is anything comparable in any of the languages listed in TFA.

by hackingonempty

4/12/2026 at 7:59:52 AM

> 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

by usrnm

4/12/2026 at 9:18:19 AM

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

by hackingonempty

4/12/2026 at 7:00:14 AM

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 go in every aspect of devx, and better in IDE support, expressiveness, and dependency mgmt.

by ysleepy

4/12/2026 at 7:27:35 AM

> 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 saved around 36% of the total runtime compared to before.

The reason Arc was so expensive here is likely that the reference count was contended, so the cacheline was bouncing back and forth between the cores that ran the threads in the threadpool working on the task.

In conclusion, neither extreme is correct. Often Arc is fine, sometimes it really isn't. And the only way to know is to profile. Always profile, humans are terrible at predicting performance.

(And to quite a few people, coming up with ways to avoid Arc/clone/Box, etc can be fun, so there is that too. If you don't enjoy that, then don't participate in that hobby.)

by VorpalWay

4/12/2026 at 8:37:47 AM

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.

by indigo945

4/12/2026 at 7:05:59 AM

Pretty sure by devx they mean something like syntax ergonomics. Because otherwise rust's devx first class (cargo, clippy, crates.io) so kind of a nonstandard definition.

I think it's fair to say Java's "syntax ergonomics" are a little below the rest / somewhat manual like rust or C++ by default.

by fyrn_

4/12/2026 at 8:10:30 AM

Yeah, but worse than Go?

by ysleepy

4/12/2026 at 7:48:38 AM

I am not sure the community frowns on these. In fact I use those in almost every Rust code I write. The point is that i can grep for those because Rust does not do it in a hidden way.

by dev_l1x_be

4/12/2026 at 8:38:31 AM

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

by alkonaut

4/12/2026 at 8:02:37 AM

Since programming is increasingly offloaded to LLMs and English is the main way engineers interact with code, it's interesting to see how LLMs reason in different programming languages.

In our benchmarking, we've found LLMs perform comparably between languages for one-shot coding submissions, slightly favoring more popular languages. But if you give frontier LLMs a harness and let them iterate / fix compilation errors, they actually significantly outperform in Rust. Meaning, they come up with more insightful ideas when developing Rust, than for example Javascript.

Scroll down to the language comparison chart: https://gertlabs.com/?agentic=agentic

by gertlabs

4/12/2026 at 7:01:22 AM

Crystal lang deserves a look given the article writer’s preferred language attributes. It has OO paradigms, elegant composability, efficient codegen etc.

by fork-bomber

4/12/2026 at 6:11:31 AM

C# has indeed finally gained sum types this year… in preview. We’ll see if anything makes it into C#15 but they’re closer than they’ve ever been.

by moomin

4/12/2026 at 6:55:31 AM

Type unions only at first, but there's more being planned.

by zigzag312

4/12/2026 at 7:56:07 AM

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 important requirement most of the time and it's given undue importance by some.

by Tade0

4/12/2026 at 8:37:09 AM

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.

by teaearlgraycold

4/12/2026 at 8:55:50 AM

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

by sargunv

4/12/2026 at 9:06:49 AM

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?

by teaearlgraycold

4/12/2026 at 9:19:10 AM

I think the problem is the union argument type - intuitively we read "array of strings OR numbers", but actually it means "array of strings AND numbers". Probably generics would be more appropriate here, with the type param constrained to string or number. Then tsc would also complain about pushing a number without checking the item type before.

by sally_glance

4/12/2026 at 10:01:27 AM

If it's an "array of strings AND numbers", then it should not be allowed to call the function with a string[], because those are different types.

by fainpul

4/12/2026 at 9:14:49 AM

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

by sargunv

4/12/2026 at 9:20:22 AM

I asked an LLM and it described the problem as "covariant typing of mutable collections" or "unsound covariance". I'm not mathematically educated in this area but that sounds right?

by teaearlgraycold

4/12/2026 at 4:58:27 AM

Based on your description, I think a good library for data structures that are intended to be used immutably would help with some pain points. Something with copy on write support or something like that. It's a powerful style, used it in haskell and it prevents a large class of bugs, almost down to just business logic bugs, which is what you want.

I like the style you're describing, thanks for sharing.

by fyrn_

4/12/2026 at 8:16:02 AM

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's not Java.

by bluegatty

4/12/2026 at 8:22:35 AM

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.

by loglog

4/12/2026 at 8:27:32 AM

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.

by bluegatty

4/12/2026 at 10:05:09 AM

There definitely is Kotlin without Java, and you can compile Kotlin code for use in jvm, ios/ipados/macos, android, wasm/js, and native.

by olcay_

4/12/2026 at 6:53:28 AM

Java have less of a DevEx score than C# is crazy work.

by vibbix

4/12/2026 at 9:43:05 AM

Reified generics, value types, nullable reference types, LINQ are only some of the things that would give C# an edge in DevEx today.

by mrsmrtss

4/12/2026 at 8:03:48 AM

Isn’t this “high level rust” idea similar to swift?

Everything is ARC. Clones are cheap. But you still have a reasonable sound type system and no garbage collection.

I get it. Tooling on swift is meh the further you are from Apple, so I’m not suggesting it’s better.

But from a language point of view; is it not essentially a high level rust?

Ps. I don’t really know swift. Just asking where/why I’m wrong really.

by jackjeff

4/12/2026 at 8:17:22 AM

It's not ARC though. They use fancy threading mechanisms to avoid having to check on every access. Much faster.

by bluegatty

4/12/2026 at 8:01:48 AM

It is called OCaml.

by pjmlp

4/12/2026 at 8:07:33 AM

It is absolutely bizarre to not check DevX for Rust, it was literally the most loved programming language for years according to SO surveys.

by ai_slop_hater

4/12/2026 at 8:08:42 AM

When someone mentions High-level rust, gleam comes to my mind. Although the language is functional and not OOP, but at-least from the perspective of type-system its well written and it can also hook into the elixir/erlang ecosystem.

by Imustaskforhelp

4/12/2026 at 7:53:06 AM

No code examples? Wtf?

If you want to see high level rust, check out Dioxus. It's a web framework, and it's extremely React-like both in architecture but also ergonomics. I actually had AI migrate a JS project to Dioxus and I think it was something like 75% of the code. Pretty decent for a "low level" language.

by slopinthebag

4/12/2026 at 8:03:37 AM

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.

by nananana9

4/12/2026 at 9:04:08 AM

> terrible non-functional garbage collector

What garbage collector?

by rounce

4/12/2026 at 8:06:21 AM

> Most of the Rust code I've read is arc-mutex-slop.

Skill issue

by ai_slop_hater

4/12/2026 at 7:29:07 AM

Is this another AI article? What is said about Rust here has been said over and over again, and this brings nothing new to the table. They also always seem to be writing from a place of ignorance. If you're writing "high level Rust" the use of clone or Arc or whatever is negligible. If you're writing an HTTP service, your clone will be so fast it will make literally zero difference in the scope of your IO bound service.

Another observation is developer experience. Again, have you written _any_ Rust? I would argue that the reason Rust is such a joy to use is that the compile time errors are amazing, the way docs are handled are amazing, and so on. I know the eco system for something like Typescript is worlds better, but have you ever tried to _really_ understand what shenanigans are going on behind the scenes on some random hook from say, React? Their docs are so dismal and sparse and make assumptions on what they think you should know. Rust? You go to the doc gen, read what they think you should know as an overview, and if it isn't enough, I can click on "source" to dive deeper. What more could I possibly want?

Perhaps I'm just triggered. The discussion on Rust always seems to be fad or hype driven and almost always have very little to do with how it is to actually use it. If I have to read about compile times, again, I'm going to scream. Of all the languages I've used, it is one of the best in terms of a mature project needing new features or refactors. This is mentioned in some articles, but mostly we hear about "velocity" from some one dimensional perspective, usually someone from the web space, where it is arguable if the person should even bother trying to use Rust in the first place.

Apologies for the rant, but at this point I think Rust as a buzz word for article engagement has become tiring because it seems clear to me that these people aren't _actually_ interested in Rust at all. Who gives a shit what someone on Reddit thinks of your use of clone??

by dannersy

4/12/2026 at 8:26:58 AM

What triggered me was the proposed Arc<dyn TRAIT> as a quick fix. I was highlevel rustin along the learning curve as the article describes until i stumbled uppon dyn-compatible types and object safety.

It is too easy to trap yourself in by sprinkling in Sized and derive(Hash) ontop of your neat little type hierarchy and then realize, that this tight abstraction is tainted and you cant use dyn anymore. As a follow up trigger: This was when i learned derive macros :)

by throwawayqqq11

4/12/2026 at 7:28:05 AM

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 of C++ that solved memory problems the most recent versions of C++ don't have anymore, and only survives by aggressive marketing, full of grouping things together that don't belong together, like C/C++. And memory safety / use-after-free.

If C and C++ are basically the same because they have access to manual memory allocation then Rust/PHP are also basically the same.

And Rust's borrow checker only solves use-after-free which statistically are 10% of memory related vulnerabilities. Not "memory safety" of which 60-70% is just array out of bounds.

Really the worst two languages that both only survive in aggressive marketing.

by jurschreuder

4/12/2026 at 8:30:44 AM

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

by PhilippGille

4/12/2026 at 7:39:04 AM

You do not write Rust yet will make blanket absurd claims about Rust being overcomplicated or not solving your problems. The additional comparison of Rust to PHP is also ridiculous for so many reasons it might not be worth even discussing, because it just seems bad faith from the start.

You're missing a very fundamental point here, and this is usually something I find with long time C programmers. C is a great, but old language, with decades of overhead on context, tooling, and lib understanding that make getting in to writing C substantially more difficult than say, Rust. We are still humans, and Rust isn't entirely trying to solve C from a fundamental paradigm of handling memory from a technical point of view, but more from a programmer one. Your comment about solving memory bugs is predicated on perfect human usage of C to not write the bug in the first place, which is precisely one of the many problems Rust is looking to solve.

by dannersy