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

151–160 of 523 posts

Re: The Rust I wanted had no future

#151

Post by anonymoushn »

ohgodplsno wrote: post #48
sph wrote: post #22

Earlier quoted context omitted.

I disagree. You can call an async function in Rust from a regular one, that's true, but the returned value still needs to be passed through an executor to be useful. Async without function coloring means being able to call `async fn add(a, b: usize) -> usize` from anywhere and having an usize back, whether you're calling from a regular or async function. If you need slightly different logic because of async, you got…

Not knowing about function coloring is a stupid dream and has terrible implications on the performance of your code, which is infinitely more important than you losing 2 minutes having to figure out that you really want to `runBlocking { callThatBlocksForADamnLongTime() }`. The insight that function coloring gives you is terribly important. Roman Elizarov (of Jetbrains, author of Kotlin and lead on Kotlin Coroutines)…

This comment reads like it's from an alternate dimension where "calling read(2) marks functions as async" is a common language feature. Over here, read(2) can block forever and normal functions can call it in just about every language.

Re: The Rust I wanted had no future

#152

Post by anonyfox »

FrustratedMonky wrote: post #148
jjtheblunt wrote: post #146

Earlier quoted context omitted.

Have you dismissed F# ?

I would like to second F#. It seems to have a lot of what people want, so why isn't it more popular?

Can I natively build self-contained binaries? One of Go's biggest advantages is the delivery chain from code to server (build for target arch, copy to target, ./run)?

Re: The Rust I wanted had no future

#153

Post by aardvark179 »

tinco wrote: post #124
layer8 wrote: post #82

Earlier quoted context omitted.

It’s about stack size. Programs that rely on tail calls (in particular recursive ones) may cause the stack to overflow when the language implementation doesn’t actually support tail calls, for example when using tail calls to recursively process a list that is larger than (some constant fraction of) the stack. With an infinite stack, it would just be an optimization, but in practice the stack is finite (and significa…

I thought on 64 bit systems the stack could basically be infinite for all practical purposes. Is this only a problem on more limited (i.e. <64bit) systems or am I misremembering when I last learned about stacks 10+ years ago?

It is always a problem, in the same way that holding on to huge objects is always a problem. Let's think about this in terms of a memory map, so ignoring limits of physical memory. On 64bit systems we actually have 48bits of usable address space, so that's 256TB. Now, the OS is going to need some workspace, but I think we can ignore that for this argument. So if you're only going to run 4 threads then each one could have a huge stack of 32TB, but if we wanted to run a huge server with a thread per connection then maybe we can only have 256MB per thread.

Now, 256MB is pretty huge, but we probably want way more memory kept for heap storage and similar things (because managing lifetimes purely on the stack will be hard and might require a lot of copying of data), so it will be less than that. Now, you may ask, "Why not start with small stacks and make them bigger as needed?" It's a good question, but since our stacks are contiguous areas of memory and we don't know what's in them, we still have to space them out in our memory map allowing for as much growth as is needed.

We might solve some of these problems by introducing segmented stacks, but this is one of those problems that crosses so many language, runtime, and OS boundaries that it's been hard to do in the general case, and it feels like gently nudging people towards writing code that can be tail-optimised is easier, just as it's easier to push people to use async than it is to provide systems and APIs that would allow for blocking code and a huge number of threads.

Re: The Rust I wanted had no future

#154

Post by californical »

jeltz wrote: post #144
anonyfox wrote: post #143

I love Rust and built some production code with it in the past. But nowadays I want something more simple so that not-so-senior developers can pick it up quickly, and I want flawless tooling, and willing to sacrifice a bit of performance. So basically I often end up with Go. Go is exceptionally great in tooling, ecosystem, any objective metrics like build times or crosscompilation... but I still don't like the langua…

Yeah, that is exactly what I want for when I build web applications. Something with an ecosystem like Rust's, with more advanced type system than go but which sacrifices some performance for ease of development.

I feel like Crystal is close, they just need more community to build out their ecosystem. Otherwise it seems like a perfect language (fun, simple to understand, compiled + fast, has types)

Re: The Rust I wanted had no future

#155

Post by anonyfox »

zidad wrote: post #149
jjtheblunt wrote: post #146

Earlier quoted context omitted.

Have you dismissed F# ?

Unfortunately a lot of people will dismiss C# and F# just because it has the Microsoft label. I do think they're missing out.

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

Re: The Rust I wanted had no future

#156

Post by foobarbaz33 »

inferiorhuman wrote: post #100
vsnf wrote: post #85

Earlier quoted context omitted.

Although all of those things are true, I think the main point being made is why choose Rust for that, instead of Go, .NET, etc, any of which offer everything you've outlined as being worth having, while having fewer of the downsides of Rust.

any of which offer everything you've outlined They don't, that's the "problem". Off the top of my head dependency management in Go is not best in class to put it charitably. .NET will tie you more closely to Windows. Sure, mono is a thing but you'll have more packages to choose from and fewer compatibility issues running .NET on Windows.

Mono? 2000 and late called and want their .NET implementation back. Now it's all about the .NET formerly known as "Core".

Re: The Rust I wanted had no future

#157

Post by anonyfox »

californical wrote: post #154
jeltz wrote: post #144

Earlier quoted context omitted.

Yeah, that is exactly what I want for when I build web applications. Something with an ecosystem like Rust's, with more advanced type system than go but which sacrifices some performance for ease of development.

I feel like Crystal is close, they just need more community to build out their ecosystem. Otherwise it seems like a perfect language (fun, simple to understand, compiled + fast, has types)

Already played with it, what has killed me are the outragously long compile times for nontrivial code and no "easy" way to crosscompile binaries, besides from some docker hack. Also its like a modern Ruby, which is great in general, but I really want ML-like functional style programming instead of OOP

Re: The Rust I wanted had no future

#158

Post by chrismorgan »

logicchains wrote: post #129
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…

The Rust async story would be much nicer if they'd put in the hard work up front to support higher-kinded types, as then it could have a monadic async API like OCaml or Haskell. I don't know anyone who's used async in both Rust and Haskell who prefers the Rust approach. It'd also fix oddities like why it's possible to write a function like the following in C++ but not Rust: template class MyContainer> int getFirstInt…

Are you aware of generic associated types, which landed in 1.65 (late last year)? To a considerable extent, they’re Rust’s answer to higher-kinded types. Less expressive in some ways, but fitting Rust way better, as basically a relaxation of a former restriction, rather than a new feature. If I’m reading your snippet right, GATs let you express exactly that, though minus `template`’s duck-typiness so you’d have to spell out what contract the container must adhere to.

Re: The Rust I wanted had no future

#159

Post by walljm »

anonyfox wrote: post #155
zidad wrote: post #149

Earlier quoted context omitted.

Unfortunately a lot of people will dismiss C# and F# just because it has the Microsoft label. I do think they're missing out.

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

Re: The Rust I wanted had no future

#160

Post by bazoom42 »

davedx wrote: post #61
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…

That being said... python had a BDFL and look how that turned out. I think designing and evolving any living programming language is just one of the hardest problems out there. Incredible blog post indeed, was awesome to read it.

> That being said... python had a BDFL and look how that turned out.

One of the most popular and succesful languages, and a major force in AI innovation?

Post reply on HN