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

181–190 of 523 posts

Re: The Rust I wanted had no future

#181

Post by bluGill »

Aardwolf wrote: post #104
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…

What I actually meant to ask is: given what you said, is supporting it then even a language feature, and not a compiler optimization instead? If rust says they don't support it, does it mean they don't even allow the compiler to do it? Obviously the syntax of the language itself already supports calling the function itself, and whether tail call optimization is supported or not doesn't affect the visible result afaik…

Its not that the compiler cannot do it, it is that you cannot be sure the compiler will.

Some constructs cannot be optimized for tail recursion. Languages with tail calls have guidelines of how to must write your code to ensure the tail call happens - often a seemingly small code change is the difference between tail call optimization happening or blowing up the stack.

Second, in at least some cases where the optimizer can apply tail calls you need to be guaranteed it will happen. Nothing stops a C++ optimizer from applying tail call optimization (I don't know if any do, but it is allowed in some cases), but the language doesn't require it, so even if your optimizer supports it you can never know that it happens - and more importantly you cannot be sure that after changing the code or upgrading your compiler you will still get it. Thus even if your optimizer supports tail code optimization you dare not do deep recursion.

If your language doesn't have support for tail calls you cannot do deep recursion with confidence. If your language does, then you can do deep recursion so long as you follow the rules of the language. (whatever those are - I'm not up on the latest research here, so I don't know the state of modern tail recursive languages are.)

Re: The Rust I wanted had no future

#182

Post by School-Cotton »

dist1ll wrote: post #126
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 said, I still hate async with a passion, it makes the language more complex and not very elegant (i.e. function coloring) Function coloring seems to come up a lot in these discussions, but I don't see a better way without providing a runtime. Could you propose an alternative approach to async, without sacrificing ability to write zero-overhead, high-performance bare metal systems?

They could have simply not added async to the language. I was happily using rust before async and it was perfectly fine.

Re: The Rust I wanted had no future

#183

Post by FeepingCreature »

p0nce wrote: post #90

> First-class & Interestingly like Graydon suggests this and 'tis something D has, you can only have `ref` for function parameters. This is something the users sometimes complain about, but I guess it has positives.

Yeah a lot of these features sound like he wants "D with lifetimes".

Re: The Rust I wanted had no future

#184

Post by [deleted] »

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?

[deleted]

Re: The Rust I wanted had no future

#185

Post by [deleted] »

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…

[deleted]

Re: The Rust I wanted had no future

#186

Post by tinco »

aardvark179 wrote: post #153
tinco wrote: post #124

Earlier quoted context omitted.

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…

Thanks, I didn't realise the usable address space was so "small", those numbers are well within reasonable usage so that's definitely too limiting to just say it's infinite and not worry about it.

Re: The Rust I wanted had no future

#187

Post by jjtheblunt »

anonyfox wrote: post #152
FrustratedMonky wrote: post #148

Earlier quoted context omitted.

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

Yes

Re: The Rust I wanted had no future

#188

Post by School-Cotton »

zamalek wrote: post #164
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 don't understand the big issue with build times: I have always found that they are almost instant for incremental builds (assuming you use lld or mold).

> I have always found that they are almost instant for incremental builds (assuming you use lld or mold)

They are not almost instant once your project grows to a certain size, which is still well within the bounds of a realistic single company’s project (I work on Materialize which is all in rust).

Re: The Rust I wanted had no future

#189

Post by bluGill »

twic wrote: post #121
PhilipRoman wrote: post #41

Haven't followed Rust too much, but I'm always surprised when I hear that Rust is too difficult or not ergonomic. As I understand it is meant to be a systems level language; something you'd use to write kernels, TCP stacks, browsers and ssh daemons. Anyone writing these things today in C or C++ already understands object lifetimes and Rust just adds a static checker for them. In such projects churning out lines of co…

> Anyone writing these things today in C or C++ already understands object lifetimes and Rust just adds a static checker for them. I've certainly seen seasoned C++ programmers saying this. Of course, a few of them of say they understand object lifetimes so well, they they don't need the static checker! > Why on earth would you try to rewrite python CRUD apps in Rust? This is one of the great mysteries of our times. I…

> Of course, a few of them of say they understand object lifetimes so well, they they don't need the static checker!

There is a difference between understanding lifetimes and being able to keep track of them. I have a lot of objects in my more than 10 million lines of code. Most of them have simple lifetimes that are easy to track, but a few for reasons (which may or may not be valid - often the reasons are it was built in C++98 and updating to modern lifetimes is hard when it is used all over) have complex lifetimes that are tedious to track. It isn't that I can't, it is that I get bored/make mistakes and the static analyzer wouldn't (Or course C++ can't be statically analyzed, but if it could the static analyzer wouldn't fail for the same reasons I fail)

Re: The Rust I wanted had no future

#190

Post by avgcorrection »

I haven’t cared about what Hoare thinks of Rust since 2015.

1. He hasn’t been involved in the language for a long time

2. His vision for the language was completely different compared to how the remaining developers ended up designing it. So if I ended up liking Rust under his “BDFL”ing then it would be for completely different reasons compared to why I like (and dislike) Rust today

Post reply on HN