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

Rewriting Rust

josephg.com

Post reply on HN
Print view View original

381–390 of 410 posts

Re: Rewriting Rust

#381

Post by FridgeSeal »

adastra22 wrote: post #372
Measter wrote: post #329

Earlier quoted context omitted.

Though we should also accept that some things are just hard. Though that's not to say that we should give up on trying to make them as easy to learn and use as possible.

I don’t know. This certainly isn’t provable. What’s the difference between a something being intrinsically difficult and something for which adequate UI just hasn’t been figured out yet? I don’t know anything that hasn’t been made simpler and easier over time.

Some things have inherent complexity. Different formulations or UX can alleviate some of this complexity, but often it is shifted around, or hidden - not actually solved.

Some solutions can definitely make a situation net-worse/net-more-complex, and occasionally we get advances in theory which can change the watermark on complexity, but it never _goes away_.

Re: Rewriting Rust

#382

Post by FridgeSeal »

josephg wrote: post #207
devit wrote: post #192

Earlier quoted context omitted.

You can make the struct generic on the type to have a field being an impl Trait type.

I know. Sometimes that can work. But that choice will ripple out to cause all sorts of other complications throughout your codebase. Now you have a Struct . How do you pass one of these structs as a parameter to another function? Do you need to make that function generic over all T? How do you embed that into another struct, in turn? Do you put generic arguments everywhere? And so on. Fundamentally, I don't want my t…

Am I right in understanding: you want some private, internal structure to be generic over some types, but you don’t want any wrapping structs to carry around that generic?

Could this problem be reformulated to use associated types, rather than full generics?

Re: Rewriting Rust

#383

Post by tempodox »

rowanG077 wrote: post #367
mirashii wrote: post #352

Earlier quoted context omitted.

But now you have to know at compile time what you're watching, which is not what cargo-watch or any of the similar commands like entr do.

Considering you have a rust file and the dependency why wouldn't you compile it? It's not like rustc is not available when you are using cargo-watch.

Anyway, doing all that just so you don't have to write a regexp has all the hallmarks of overkill. Keep it simple.

Re: Rewriting Rust

#384

Post by pdimitar »

withoutboats3 wrote: post #264
josephg wrote: post #239

Earlier quoted context omitted.

> The obvious examples you want to use work fine, but the feature needs to be designed in such a way that the language remains internally consistent and works in all edge cases. True. How long should that process take? A month? A year? Two years? I ask because this feature has been talked about since I started using rust - which (I just checked) was at the start of 2017. Thats nearly 8 years ago now. 6 years ago this…

I don't deny that Pin is complicated to use as it stands (in fact that is the entire thrust of my blog posts!), just that there is some magical easier solution involving Move and changes to the borrow checker. You wrote something on the back of a napkin and you imagine its better, whereas I actually had to ship a feature that works. The state of async Rust is not better because no one hired me to finish it past the M…

> I've devoted a lot of my free time in the past year to explaining what I think the project should do, and its slowly starting to move in that direction.

That's very intriguing. Do you have any examples? Willing to learn more.

Re: Rewriting Rust

#385

Post by josephg »

FridgeSeal wrote: post #382
josephg wrote: post #207

Earlier quoted context omitted.

I know. Sometimes that can work. But that choice will ripple out to cause all sorts of other complications throughout your codebase. Now you have a Struct . How do you pass one of these structs as a parameter to another function? Do you need to make that function generic over all T? How do you embed that into another struct, in turn? Do you put generic arguments everywhere? And so on. Fundamentally, I don't want my t…

Am I right in understanding: you want some private, internal structure to be generic over some types, but you don’t want any wrapping structs to carry around that generic? Could this problem be reformulated to use associated types, rather than full generics?

No. I have a function which returns impl Trait. The most common culprit for this is impl Iterator. (For example, a function does a map, filter or fold over something else and returns the resulting iterator).

I want to make another struct which slowly consumes that impl Iterator. So, the second struct is struct MyStruct { iter: (iterator returned from that function above) }.

Unfortunately, the iterator type doesn’t have a name. So currently that means it’s impossible to put this iterator in a struct.

This makes anything returned via impl Iterator (and impl Future and so on) second class citizens in rust. You are very limited in the ways you can use these objects compared to normal values.

My code is filled with hand written iterators that I could construct much more easily with map/filter/fold and friends. But I make them the long way simply so the resulting type has a name. The current situation is very silly.

Re: Rewriting Rust

#386

Post by leoedin »

kibwen wrote: post #290
leoedin wrote: post #153

Earlier quoted context omitted.

There's probably a similar amount of code in the execution path, but the Rust ecosystem reliance on dependencies means that you're pulling in vast amounts of code that doesn't make it to your final application. A C++ library author is much more likely to just implement a small feature themselves rather than look for another 3rd party library for it. Adding dependencies to your library is a more involved and manual pr…

> A C++ library author is much more likely to just implement a small feature themselves rather than look for another 3rd party library for it. This is conflating Javascript and Rust. Unlike Javascript, Rust does not have a culture of "microdependencies". Crates that get pulled in tend to be providing quite a bit more than "just a small feature", and reimplementing them from scratch every time would be needlessly redu…

My comment had nothing to do with Javascript.

Rust may not have "left pad" type micro-dependencies, but it definitely has a dependency culture. Looking at `cargo tree` for the medium size project I'm working on, the deepest dependency branch goes to 12 layers deep. There's obviously a lot of duplicates - most dependency trees eventually end with the same few common libraries - but it does require work to audit those and understand their risk profile and code quality.

Re: Rewriting Rust

#387

Post by withoutboats3 »

pdimitar wrote: post #384
withoutboats3 wrote: post #264

Earlier quoted context omitted.

I don't deny that Pin is complicated to use as it stands (in fact that is the entire thrust of my blog posts!), just that there is some magical easier solution involving Move and changes to the borrow checker. You wrote something on the back of a napkin and you imagine its better, whereas I actually had to ship a feature that works. The state of async Rust is not better because no one hired me to finish it past the M…

> I've devoted a lot of my free time in the past year to explaining what I think the project should do, and its slowly starting to move in that direction. That's very intriguing. Do you have any examples? Willing to learn more.

My blog is located at https://without.boats

Here are some relevant posts:

https://without.boats/blog/a-four-year-plan/

https://without.boats/blog/poll-next/

https://without.boats/blog/asynchronous-clean-up/

https://without.boats/blog/pinned-places/

Re: Rewriting Rust

#388

Post by simon_o »

lifthrasiir wrote: post #371
simon_o wrote: post #267

Earlier quoted context omitted.

That seems to be an absolute win to be honest. Not sure how you think this is helping your case. Maven Central people nuked the artifact that may have caused confusion, and if the owners try anything like that again, it's likely their domain will be banned from publishing.

Yes, but that's not unique to Maven because virtually all software repositories have such policies. If that's about the required amount of "moderation" you claim, I don't see how Maven can even be considered better than others.

Or maybe you don't want to.

If that's the hill you want to die on, good luck.

Re: Rewriting Rust

#390

Post by Arch-TK »

orf wrote: post #369
Arch-TK wrote: post #326

Earlier quoted context omitted.

> As I've noted elsewhere, you can't even safely use `char ` for file names in Windows; it should be `wchar_t ` in order to avoid any encoding problem. Yes, this is true. But I think the overhead of writing that kind of code would not be as enormous as 30k lines or anything in that order. > At the very least it should have checked for TTY in advance. I'm not even interested in terminfo (which should go die). Maybe. I…

> But neither of us has time for that. Indeed, so why waste it reinventing the wheel instead of using a high quality third party package? Or arguing about highly suspect LoC numbers pulled out of thin air as if it’s not an apples-to-oranges comparison, for that matter.

I mean there is an issue here with inflated line counts. It makes the whole solution more complex and more difficult to troubleshoot. It makes the binary size inflated. It likely makes the solution slower. And, probably most important, it makes auditing very difficult.
Post reply on HN