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

The Rust I wanted had no future

graydon2.dreamwidth.org

Post reply on HN
Print view View original

201–210 of 523 posts

Re: The Rust I wanted had no future

#201

Post by tialaramex »

intelVISA wrote: post #132
Ygg2 wrote: post #17

Earlier quoted context omitted.

Performance, but with sanity. Say you use a vector in C++. You push one element and pop two. In Rust that's a None. In C++ the answer is UB (in my case 43).

The fatal mistake here is using the STL...

The safe thing Rust did here is affordable in Rust (Option is the same size as T for many T including all references) so they could afford to do it, whereas it's expensive in C++. Could it have been made cheaper in C++? Sure, but safety wasn't their priority so who cares?

That prioritisation applies to the whole ISO language, not only to the standard library.

Re: The Rust I wanted had no future

#202

Post by hayley-patton »

zozbot234 wrote: post #112
hayley-patton wrote: post #98

Earlier quoted context omitted.

I don't mean "effects" in the sense where you can have effect handlers which get delimited continuations and all; it'd just mark what could happen (like checked exceptions). But I can't think of any languages with that and not effect handlers; Koka, Eff, and Unison come to mind for effects, though their practical-ness may vary.

Do you really need effect handlers as a separate feature once you have async/await? It seems like you could easily encode one with the other.

An effect handler is allowed to invoke a continuation multiple times; I believe this is not possible with async/await.

Re: The Rust I wanted had no future

#203

Post by vips7L »

hadrien01 wrote: post #197
zamalek wrote: post #168

Earlier quoted context omitted.

C# is horribly OOP. I use it in my day job, and the frameworks wield OOP overcomplexity proudly. It has likely gone beyond Java as the posterchild for OOP: interfaces that are implemented once, classes that are instantiated once. You can't get away from it either, it is practically part of the stdlib and everyone cargocults it. Rust is imperative too, though.

The language doesn't push you towards interfaces implemented once, but many developers indeed persist doing it for no reason at all. With proper code review we're able to make that practice go away on the projects I'm working on.

Isn't this just mostly an issue with mock testing in C#? Developers cargo cult single implementation interfaces because its so hard to mock concrete classes.

Re: The Rust I wanted had no future

#204

Post by vips7L »

walljm wrote: post #159
anonyfox wrote: post #155

Earlier quoted context omitted.

Nowadays I program in a mostly Microsoft world (VSCode, Github, npm, typescript, GPT, ...) and I think its quite good, so no bias here. But the "shipping a native binary straight to the server that just works" is absolutely crucial for me

.net will let you do that now. You can ship precompiled binaries with Native AOT. ( https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... )

And even before native AOT you could use publish single and have a single binary.

Re: The Rust I wanted had no future

#205

Post by fzeindl »

sph wrote: post #6

Very interesting insight from Graydon, in hindsight I too would have loved something more towards ML than C++. I never liked the kitchen sink approach that I see first C++, now Rust moving towards, but I respect what Rust has managed to solidify into. It's a good language. That said, I still hate async with a passion, it makes the language more complex and not very elegant (i.e. function coloring). And now that I kno…

I hate async as well. Developers should have learned about communicating sequential processes and blocking queues and none of that would have been necessary. It creates a weird divide in every language. Just learn about threading and do it.

A nice talk about this: https://www.reddit.com/r/programming/comments/da141r/ron_pre...

Re: The Rust I wanted had no future

#206

Post by kaba0 »

mike_hearn wrote: post #91
ohgodplsno wrote: post #86

Earlier quoted context omitted.

Adding a disk read won't break my software, but it can certainly make my software non-portable. If it suddenly expects a disk write and I'm running on a ROM, I'm going to have a hard time. If it suddenly tries to contact google.com and I'm on an airgapped machine, I'm going to have a hard time. It's not even a matter of breaking the app actually, it's a matter of warning that "I'm going to go outside the realm of jus…

Blocking in Loom is primarily about waiting for network traffic, possibly with extensions to file IO in future - it doesn't suspend if you do file IO today. Loom does get rid of coloring, or rather, doesn't introduce more of it and lets you phase out what exists, so I'm not sure what exactly you mean by that. Kotlin suspend funs do not tell you they're about to touch network disk, that's the reason they use "suspend"…

> possibly with extensions to file IO in future - it doesn't suspend if you do file IO today

Wasn’t basically all of the JDK’s file APIs rewritten to io_uring-like calls to support Loom? I have thought that IO was definitely something that Loom handled.

Re: The Rust I wanted had no future

#207

Post by noelwelsh »

dorian-graph wrote: post #103
TurboHaskal wrote: post #9

Earlier quoted context omitted.

> I too would have loved something more towards ML than C++ I stopped paying attention to the language around 2012-2013 or so when the direction clearly steered towards the latter. You may want to check https://austral-lang.org/ out.

I was about to ask if there's any "Rust by ML" languages out there. Thank you.

O'Caml is heading in that direction. Jane Street are adding more control over memory layout and allocation, and multicore finally arrived recently.

Re: The Rust I wanted had no future

#208

Post by bfrog »

After reading this I'm really quite happy Graydon created Rust, but then conceded the path it has taken.

It really is an incredibly language and ecosystem, in large part, because of its performance potential.

To be clear, the only real options in this space were arguably C, C++, and maybe in some circles D in my mind. C++ and C by far had the mind share.

Had Rust gone the way Graydon wanted I don't think Rust would be so interesting in the OS and Embedded space. This is a space that it turns out is really ripe for change.

Embedded application are growing more connected, and more complex all the time. Security is a serious concern perhaps followed by or proceeded by performance depending on who you ask. Rust checks so many boxes off in this space its really hard to argue that it isn't a better solution.

Would you rather write a little embedded http server on an IoT device in C, C++, or Rust? What about an embedded networking stack? What about a mesh network stack? I know the answer I'd have every time for this myself.

Re: The Rust I wanted had no future

#209

Post by chronofar »

anonyfox wrote: post #150
zidad wrote: post #147

Earlier quoted context omitted.

You could try C# (or Kotlin if you have a MS bias ;-)). Both really nice general purpose languages, quite performant despite having a GC and great available tooling.

I think I still would have to deal with a lot of OOP and imperative code there, C# feels like a kitchen sink of stuff - right?

You can avoid quite a bit of OOP with Kotlin if you like, and with Arrow make some really nice functional code. Imo it offers a great balance of imperative vs functional, providing powerful tools for whatever style suits the project best.

Re: The Rust I wanted had no future

#210

Post by naasking »

javajosh wrote: post #162

Too bad graydon didn't get his way with build times. I've come to believe that the most important feature of any development environment is to minimize the built-test-debug cycle. Of course, a real system has many different ones, ranging from "language level" to "I have to redeploy and perform a complex series of actions in an app or 3". But at the language level I've found that build performance is of paramount impo…

> I've come to believe that the most important feature of any development environment is to minimize the built-test-debug cycle.

I think the next innovation in statically typed languages should be to somehow break the build-test-debug cycle. We basically have the same interface to programming as dynamically typed languages, despite having considerably more information available because of the types. This should be exploitable somehow to give typed languages more advantages, and change the very nature of the loop.

Post reply on HN