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

71–80 of 122 posts

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

#71

Post by SIRHAMY »

Surac wrote: post #68

I would disagree with C# having a (-) at Types. The Type system is indeed the most impressing part of .net/C#. having written static analysers for many languages i find the c# type system the most logical and most easy to parse

C# is missing expressive types for me.

That might land with native unions but it's not there yet. There's workarounds with OneOf and Dune but those are kind of messy.

I think expressive types on dotnet are possible - I am a big fan of F# and those types are very good. So I think C# will get there but I can't say it's there yet.

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

#72

Post by SIRHAMY »

gertlabs wrote: post #20

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 error…

Anecdotally I think AI is quite good at langs with lots of training data: C#, TypeScript Rust.

I also think it's much better with languages with more guardrails and clear syntax: think expressive types (sum types), brackets, and linters / compile checks.

Rust has expressive types and lots of compile checks to avoid classes of bugs via ownership / lifetimes and I think makes it a very good tool for agents to use.

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

#73

Post by SIRHAMY »

Imustaskforhelp wrote: post #25

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.

Big fan of Gleam! I am keeping my eye on it.

Agree that the types accomplish basically exactly what I want.

If it gets a decent community / ecosystem I think it would be a frontrunner for sure, especially for web apps.

One potential issue is that the runtimes it targets are not that great at processing - they fanout well on BEAM but may not be the best for heavy processing. Not a deal breaker but smth that others like F#, OCaml, Rust can outperform in if the other attributes do well.

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

#74

Post by em-bee »

yearolinuxdsktp wrote: post #70
loglog wrote: post #29

Earlier quoted context omitted.

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’s closed-by-default design choice makes it worse than Java, and thus not strictly better than Java. It’s premature optimization, and a design-up-front-influenced paranoia/fear of any extension in not-designed-for places. But when I write code, I prefer to keep it open to extension, and in practice, I found a lot of value in extending decently written code, that would not be possible with Kotlin without having…

can you point to documentation or articles that explain this closed-by-default concept in more detail?

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

#75

Post by frizlab »

jackjeff wrote: post #22

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.

The tooling is getting better and better, thankfully. Just recently they published their official VSCode extension on open-vsx for instance. It’s getting usable now!

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

#76

Post by Imustaskforhelp »

SIRHAMY wrote: post #73
Imustaskforhelp wrote: post #25

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.

Big fan of Gleam! I am keeping my eye on it. Agree that the types accomplish basically exactly what I want. If it gets a decent community / ecosystem I think it would be a frontrunner for sure, especially for web apps. One potential issue is that the runtimes it targets are not that great at processing - they fanout well on BEAM but may not be the best for heavy processing. Not a deal breaker but smth that others lik…

> If it gets a decent community / ecosystem I think it would be a frontrunner for sure, especially for web apps.

There is! From my understanding, Check out the gleam discord server and communities around it.

There are some good web frameworks in Gleam like lustre. I feel like you are gonna love this guy's videos: https://www.youtube.com/watch?v=3kr4Ydx6GGU

> One potential issue is that the runtimes it targets are not that great at processing - they fanout well on BEAM but may not be the best for heavy processing. Not a deal breaker but smth that others like F#, OCaml, Rust can outperform in if the other attributes do well.

I can agree to that. Gleam as a language is still not the best for these things (currently) but it supports the ability to transpile to Javascript and I feel like there are multiple things that gleam can and might be doing to make things faster, so in a sense I am hopeful about their future!

I feel like gleam can be considered as the modern ruby in some sense if one bets on it and to be honest, ruby wasn't slowed by many of these things and even right now some major projects even backend wise are written in ruby (homebrew comes to my mind) so it depends but yea, personally I am a gopher fan. I really love its simplicity for the most part, There are some interesting projects in the golang world where people are starting to transpile to golang from a more rust-y flavour/feeling. Some were on Hackernews recently, I would recommend checking them out if you might have some free time to tinker around!

And thanks for responding to this comment and have a fun time tinkering, personally I really like to sometimes just print hello world in different languages, I don't know what there is about them but printing hello world makes me happy but as such I just know the very basics of a language and I haven't played with them to a deeper level but just basics and watching videos about new languages etc., I like learning about new languages even if I might not use them personally.

I recommend watching tom delande's video of rating languages as well, that video was one of the thoughts which had come when I was reading the article/the discussion: https://www.youtube.com/watch?v=-MbTj8DGOP0 I think you might enjoy it and have a nice day Sirhamy!

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

#77

Post by speed_spread »

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.

I strongly disagree with Kotlin being strictly better than Java. It pretends to fix things that haven't been problems in Java for more than 10 years while introducing a layer of syntactic complexity that's completely unwarranted. It just thrives on hype and Android development.

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

#78

Post by satvikpendem »

indigo945 wrote: post #34
VorpalWay wrote: post #10

Earlier quoted context omitted.

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

Adding a few borrows and annotations is not "an optimization that complex"; use Arc at first but then find those bottlenecks via profiling then fix them.

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

#79

Post by satvikpendem »

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…

With TypeScript 6.0 and above it is indeed much stricter by default.

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

#80

Post by dlahoda »

One can just use Lean4 and panic each time it asks proof. 5 of 5. Community is PhDs and geniuses. Types are values, full uniformity = simplicity. Perf > Swift because reference counters eliminated at compile time. AI likes types. Just panic when Lean4 asks for proofs. Backed by biggest corps out there. Macro are best of Rust and Scala.
Post reply on HN