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

Advice for the next dozen Rust GUIs

raphlinus.github.io

Post reply on HN
Print view View original

271–279 of 279 posts

Re: Advice for the next dozen Rust GUIs

#271

Post by kaba0 »

tjoff wrote: post #269
kaba0 wrote: post #265

Earlier quoted context omitted.

I don’t understand you completely. Most programs are not video decoders running a tiny tiny code on gigabytes of data, they contain quite a bit of code and many parts of it run irregularly. By not “paying attention” to memory allocations on these vast amount of cases, you get similar, or sometimes even better performance, safer and more correct software, faster. If it turns out to be a critical part, it is very easy…

I'd liken it to the Linus quote regarding data-structures https://lwn.net/Articles/193244/ And in what world is a GC safer and more correct? And no, please don't argue that it is faster in any meaningful way. > So in like 90+% of cases, a GC is a huge boost to productivity, and this is proved by their extensive usage in the industry. It is not a boost in productivity. And the reason for why it has extensive use in th…

Rust actually solves the problem, although by taking a huge toll in the form of the borrow checker. It is a very good idea, but just see this thread, it is not applicable everywhere - which is okay. Rust is a low-level language made for low-level programs where absolute control over the execution is needed.

Swift chose a different approach, but their tradeoff was lower memory overhead vs performance. It is likely a worthwhile goal for mobile devices, but that is a niche. And by the way, for all practical purposes RC is a garbage collection algorithm, it just tracks dead links instead of live ones.

So there is one solution for correctness and safety without GC, which comes with plenty of warts. How exactly GC is not a boost in productivity?

Re: Advice for the next dozen Rust GUIs

#272

Post by tjoff »

kaba0 wrote: post #271
tjoff wrote: post #269

Earlier quoted context omitted.

I'd liken it to the Linus quote regarding data-structures https://lwn.net/Articles/193244/ And in what world is a GC safer and more correct? And no, please don't argue that it is faster in any meaningful way. > So in like 90+% of cases, a GC is a huge boost to productivity, and this is proved by their extensive usage in the industry. It is not a boost in productivity. And the reason for why it has extensive use in th…

Rust actually solves the problem, although by taking a huge toll in the form of the borrow checker. It is a very good idea, but just see this thread, it is not applicable everywhere - which is okay. Rust is a low-level language made for low-level programs where absolute control over the execution is needed. Swift chose a different approach, but their tradeoff was lower memory overhead vs performance. It is likely a w…

The borrow checker does a whole lot more than replacing the GC though so it is very weird to point at it and say that the lack of a GC leads to that.

Modern C++ works very well too, but it is of course a huge language with a lot of legacy that makes it unsuitable or undesirable for a lot of things. But again, completely orthogonal to the GC.

That's a very shallow dismissal of swift... Oh, and Chris Lattner would not agree: https://atp.fm/205-chris-lattner-interview-transcript#gc

> How exactly GC is not a boost in productivity?

You claim that every other sentence but present nothing to stand on. The interview linked above shows some perspective if you care. You are not relieved from thinking about memory with a GC.

GC is a sensible response to C-style memory management, but not to any form of manual memory management.

The problem is that the options for non-GC languages are so poor, so the most reasonable language choice gives you a GC whether you want it or not. Hence my main point.

So it's not like you pick Go because it has a GC. But you might pick Go despite it having a GC.

Re: Advice for the next dozen Rust GUIs

#273

Post by kaba0 »

tjoff wrote: post #272
kaba0 wrote: post #271

Earlier quoted context omitted.

Rust actually solves the problem, although by taking a huge toll in the form of the borrow checker. It is a very good idea, but just see this thread, it is not applicable everywhere - which is okay. Rust is a low-level language made for low-level programs where absolute control over the execution is needed. Swift chose a different approach, but their tradeoff was lower memory overhead vs performance. It is likely a w…

The borrow checker does a whole lot more than replacing the GC though so it is very weird to point at it and say that the lack of a GC leads to that. Modern C++ works very well too, but it is of course a huge language with a lot of legacy that makes it unsuitable or undesirable for a lot of things. But again, completely orthogonal to the GC. That's a very shallow dismissal of swift... Oh, and Chris Lattner would not…

> The borrow checker does a whole lot more than replacing the GC though so it is very weird to point at it and say that the lack of a GC leads to that.

Well, yes and no. Sure, it helps with data races (but not with race conditions in general), but foremost it is a tool that allows for correct compile-time memory management. Compile-time memory management is only possible in a subset of programs, so rust as well has to use (A)RC at times. This is okay when used sparingly, but atomic increases are very expensive on today’s hardware.

I am familiar with RAII, but that is the exact same thing what Rust enforces at compile time, with the exact same shortcomings, so I don’t see how is it an argument against GC.

Reference counting can cause long pauses as well - as I said, it is the same problem, just looking at it from the other direction. If an object with many many references to plenty other objects die it can take quite a long time to deallocate, there are no free lunch. And then we haven’t even talked about cycles that need a similar background process to tracing GCs, without which it will leak.

Also, I have seen the interview, I believe this thread is about it: https://news.ycombinator.com/item?id=31139610

While I am all for research into better ways to do RC, please look at the discussion - it is not at all clear that RC would be better, and even theoretically a tracing GC will win.

Re: Advice for the next dozen Rust GUIs

#274

Post by tjoff »

kaba0 wrote: post #273
tjoff wrote: post #272

Earlier quoted context omitted.

The borrow checker does a whole lot more than replacing the GC though so it is very weird to point at it and say that the lack of a GC leads to that. Modern C++ works very well too, but it is of course a huge language with a lot of legacy that makes it unsuitable or undesirable for a lot of things. But again, completely orthogonal to the GC. That's a very shallow dismissal of swift... Oh, and Chris Lattner would not…

> The borrow checker does a whole lot more than replacing the GC though so it is very weird to point at it and say that the lack of a GC leads to that. Well, yes and no. Sure, it helps with data races (but not with race conditions in general), but foremost it is a tool that allows for correct compile-time memory management. Compile-time memory management is only possible in a subset of programs, so rust as well has t…

Yes and yes. Why on earth would "doesn't solve X" be an argument against that it does Z + Y ? Whereas a GC only does Z.

It was an alternative, that does less and doesn't put as much restrictions on the programmer compared to the borrow checker, as you complained about rust and equaled that with not having a GC.

And it is deterministic.

>While I am all for research into better ways to do RC, please look at the discussion - it is not at all clear that RC would be better, and even theoretically a tracing GC will win.

Win what and in what sense?

How every GC language has problems with GC tuning is in my opinion a clear indicator that the GC lost. With no real benefits short term and huge downsides down the line - even if you never hit any limits.

Re: Advice for the next dozen Rust GUIs

#275

Post by kaba0 »

tjoff wrote: post #274
kaba0 wrote: post #273

Earlier quoted context omitted.

> The borrow checker does a whole lot more than replacing the GC though so it is very weird to point at it and say that the lack of a GC leads to that. Well, yes and no. Sure, it helps with data races (but not with race conditions in general), but foremost it is a tool that allows for correct compile-time memory management. Compile-time memory management is only possible in a subset of programs, so rust as well has t…

Yes and yes. Why on earth would "doesn't solve X" be an argument against that it does Z + Y ? Whereas a GC only does Z. It was an alternative, that does less and doesn't put as much restrictions on the programmer compared to the borrow checker, as you complained about rust and equaled that with not having a GC. And it is deterministic. > While I am all for research into better ways to do RC, please look at the discus…

The borrow checker doesn’t give a complete answer to memory management, as dynamic allocation patterns by definition can’t be done at compile time unless you can solve the halting problem.

> How every GC language has problems with GC tuning is in my opinion a clear indicator that the GC lost.

Citation required. It Just Works in like 99% of cases, and it’s not like there is any solution that covers every edge case. Just look at the thread I linked, there is an example of C++’s RC lingering for a long time after the effective work is done freeing many things.

Re: Advice for the next dozen Rust GUIs

#276

Post by tjoff »

kaba0 wrote: post #275
tjoff wrote: post #274

Earlier quoted context omitted.

Yes and yes. Why on earth would "doesn't solve X" be an argument against that it does Z + Y ? Whereas a GC only does Z. It was an alternative, that does less and doesn't put as much restrictions on the programmer compared to the borrow checker, as you complained about rust and equaled that with not having a GC. And it is deterministic. > While I am all for research into better ways to do RC, please look at the discus…

The borrow checker doesn’t give a complete answer to memory management, as dynamic allocation patterns by definition can’t be done at compile time unless you can solve the halting problem. > How every GC language has problems with GC tuning is in my opinion a clear indicator that the GC lost. Citation required. It Just Works in like 99% of cases, and it’s not like there is any solution that covers every edge case. Ju…

Did I say it did? The operations are deterministic but dynamic memory is not. But that alone is quite important. Lucky for the non-GC crowd though, as the languages often give you a stronger control over what is allocated on the stack and not.

It is an axiom at this point. GC battles are not exactly unheard of on HN. Don't worry, it gets fixed in the upcoming release - has been said for decade after decade.

No there is no solution that covers any case. But you pretty much always have to think about memory, so the appeal of using a GC when the only argument in its favor is that you don't have to think about memory is quite unclear.

Re: Advice for the next dozen Rust GUIs

#277

Post by sfink »

runnerup wrote: post #55
raphlinus wrote: post #27

Earlier quoted context omitted.

“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” — Antoine de Saint-Exupéry I will one hundred percent agree with you that my approach is not a good one if you want a pretty good GUI in a reasonable amount of time. For that, an incremental approach, especially adapting some existing successful design, woul…

Last part might be worth an edit. I saw his comment as constructive well meant criticism rather than callous, thoughtless, or mean spirited. Also love the work you do and enjoy following it. Your treatises on Oklab are the #1 place I send programmers of all skill levels to understand color.

As another anecdatum, I thought the last part was beautifully done and completely deserved.

The dismissive complaint was not without merit, but wow did it assume that the commenter's use cases are all that matter and all that need be considered. The world of UIs is much, much, much bigger than that, and awash in unsolved or badly-solved problems that matter a lot to many people.

I agree with the complaint, fwiw, when applied to an important subset of the design space. I even think it's useful to try to understand where the limits of that subset are, and why.

But saying that exploration is pointless because we're all happy living on this here big island and there's nowhere else that could possibly be better so why bother looking, it's all good except we still don't know why people keep dropping dead, but that's an acceptable drawback to what is otherwise a paradise on Earth—hang on a sec while I scrape off these leeches, they're so silly sometimes—and the people who think otherwise are just malcontents who ought to be out catching fish for the rest of us to enjoy.

Re: Advice for the next dozen Rust GUIs

#278

Post by pjmlp »

dataangel wrote: post #263
pjmlp wrote: post #260

Earlier quoted context omitted.

The reference counting code that can be proven to be unnecessary, given the execution flow of the code. Rustc doesn't possess such knowledge about library types.

Rust is capable of eliminating unnecessary count increments and decrements for Rc fairly often. The compiler doesn't usually need specific knowledge -- if there is a +1 and then a -1 LLVM is smart enough to cancel that out on its own. I'd actually be curious to see examples where it doesn't.

Me too, because that is the usual hoping the compiler does the right thing, tied to LLVM, and not part of language semantics.

Re: Advice for the next dozen Rust GUIs

#279

Post by pjmlp »

buildartefact wrote: post #270
pjmlp wrote: post #260

Earlier quoted context omitted.

The reference counting code that can be proven to be unnecessary, given the execution flow of the code. Rustc doesn't possess such knowledge about library types.

I mean, how often are you cloning an Rc? It’s not like c++ where passing a shared_ptr to a function is going to copy it. Most of the time you’re going to move it.

In GUI designers, everywhere.
Post reply on HN