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

Thoughts on what a next Rust compiler would do

matklad.github.io

Post reply on HN
Print view View original

111–120 of 147 posts

Re: Thoughts on what a next Rust compiler would do

#111

Post by bobbylarrybobby »

JoshTriplett wrote: post #58
tcmart14 wrote: post #53

Earlier quoted context omitted.

For me, its the lifetime syntax I don't like the most. It doesn't feel "ergonomic" to type something like . Its mostly the ` I wish were different.

(Aside: it's 'a , not `a.) One of the hopes is that it's usually not necessary to write those lifetimes explicitly in most programs, unless you're doing something unusual. If you could go back and change it, what would you have used for the lifetime syntax?

Don't you need them anytime you have a struct with borrowed members? Even it just has a Cow you need the lifetime in the struct definition. Sometimes, but not always, you can elide the lifetimes in a function (iirc they have to occur at the outermost layer). But I definitely wouldn't call it unusual.

Re: Thoughts on what a next Rust compiler would do

#112

Post by afr0ck »

vore wrote: post #30
afr0ck wrote: post #18

Earlier quoted context omitted.

In real world software, you need lots of freedom in order to design high performance scalable systems. This includes using non-trivial data structures, and being able to access and organise memory in subtle ways. The Linux kernel is an example of this. Look at the reclaim subsystem in the kernel, for instance, and how it interacts in subtle and very complex ways with various other subsystems, the page cache, the gene…

As someone who has done kernel development work (though not Linux), not every part of a kernel is as filled with dragons as you make it out to be. Why would my e.g. filesystem driver need to punch a lot of deep unsafe holes down to the internals of memory management? Why can't I make use of a safe abstraction implemented using unsafe code to free myself from caring about those details? With C, you can only do these k…

Sometimes, you can't make hard walls between subsystems. Some filesystems need very close interaction with memory management to have very good performance. Some objects are accessed and manipulated in a racy way from logically independent places for scalability reasons. I am not against Rust, modularity, etc. But building very high performance systems is just something different.

Re: Thoughts on what a next Rust compiler would do

#113

Post by bombela »

afr0ck wrote: post #112
vore wrote: post #30

Earlier quoted context omitted.

As someone who has done kernel development work (though not Linux), not every part of a kernel is as filled with dragons as you make it out to be. Why would my e.g. filesystem driver need to punch a lot of deep unsafe holes down to the internals of memory management? Why can't I make use of a safe abstraction implemented using unsafe code to free myself from caring about those details? With C, you can only do these k…

Sometimes, you can't make hard walls between subsystems. Some filesystems need very close interaction with memory management to have very good performance. Some objects are accessed and manipulated in a racy way from logically independent places for scalability reasons. I am not against Rust, modularity, etc. But building very high performance systems is just something different.

You would encode that into types and expose a safe API. The usafe would still be local in scope.

For example you might build an abstraction named ReadWriteMutex that guarantees safe access at runtime.

I don't see a scenario where this would impede performances. The invariants to validate are the same. But rust would guarantee that it is memory safe.

Re: Thoughts on what a next Rust compiler would do

#114

Post by satvikpendem »

mr_00ff00 wrote: post #103
dgb23 wrote: post #80

Earlier quoted context omitted.

It seems in terms of web dev related crates, admittedly a niche for Rust, there have been quite a bunch of abandoned, unfinished projects and other stability issues. There also seems to be a general trend towards sophistication and away from simplicity. That’s a tradeoff that makes me personally wary, rather than excited at this point in my life. Much of that is to be expected, given the age and the unique value prop…

In fairness, I don’t think rust in web dev makes any sense outside of personal hobby projects. I’m not surprised there’s lots of abandoned and unfinished projects there. That’s not an important area.

For backend APIs it absolutely makes sense, not only for the safety guarantees but also its type system which makes data flows much easier to reason about. I recommend the book Zero To Production in Rust in particular for learning about this, I finished it recently and at the end I had a production-ready backend API.

https://zero2prod.com

Re: Thoughts on what a next Rust compiler would do

#115

Post by nneonneo »

stefncb wrote: post #17
WinstonSmith84 wrote: post #15

Earlier quoted context omitted.

Once you're done fighting with the compiler (Rust Analyzer), it's actually very enjoyable and one can be _relatively_ productive. The language allows so much flexibility that it's very easy to produce well organized code... But the compiler is really slow. Even an incremental build on a mid size project is never below 10s, whereas on a similar size project, Golang will take me less than 1 second to build incrementall…

My personal issue with Rust isn't the borrow checker. I actually find it quite intuitive. What I don't like is the extreme complexity of everything. There's just so much... stuff. What I want is a Rust, but with almost everything stripped away. Complexity similar to Go.

Memory management is hard. Thread safety is hard. Go (and Java, Python, …) pushes the complexity of the former to a GC, which has its own drawbacks. Few popular languages actually tackle the latter - most languages have safety problems there such as race conditions (in Go, Python, Java, etc.)

This is not to deny that Rust also has other sources of complexity. But, most of Rust’s complexity can be traced to its fundamental goals of safety and performance. If you’re willing to sacrifice one of those, there are much simpler and easier languages to use.

Re: Thoughts on what a next Rust compiler would do

#116

Post by vore »

afr0ck wrote: post #112
vore wrote: post #30

Earlier quoted context omitted.

As someone who has done kernel development work (though not Linux), not every part of a kernel is as filled with dragons as you make it out to be. Why would my e.g. filesystem driver need to punch a lot of deep unsafe holes down to the internals of memory management? Why can't I make use of a safe abstraction implemented using unsafe code to free myself from caring about those details? With C, you can only do these k…

Sometimes, you can't make hard walls between subsystems. Some filesystems need very close interaction with memory management to have very good performance. Some objects are accessed and manipulated in a racy way from logically independent places for scalability reasons. I am not against Rust, modularity, etc. But building very high performance systems is just something different.

But do you need this in the 99% of cases? Probably not. You can write productive, performant, and safe code in safe Rust fine.

If you do need to do something this exotic, the fundamentals don't change: you still need to take care of memory lifetimes, you still need to ensure thread safety, etc. I really don't think it's as all-or-nothing as you believe it to be.

Re: Thoughts on what a next Rust compiler would do

#117

Post by zozbot234 »

nyanpasu64 wrote: post #62
lalaithion wrote: post #25

Earlier quoted context omitted.

The key is that Rust lets you define safe interfaces, so you can separate your data races and union juggling, which need to be unsafe, from your business logic, which basically never needs to be unsafe.

"Object graph" architectures are common in C++ and sometimes necessary in Rust for business logic , when building GUI applications or emulators. But Rust doesn't allow mutating through a &/Rc, and throws a compile error if you create multiple &mut, and the workarounds are unreasonably boilerplate-heavy and RefCell carries runtime overhead, whereas C++ doesn't get in the way of making your code work. I've put together…

You can use UnsafeCell https://doc.rust-lang.org/std/cell/struct.UnsafeCell.html if you commit to manually enforcing RefCell's borrowing rules.

Re: Thoughts on what a next Rust compiler would do

#118

Post by zozbot234 »

josephg wrote: post #94
smt88 wrote: post #19

Earlier quoted context omitted.

> strong explicit typing/high ceremony If you think strong typing is "ceremony" then you probably spend most of your time writing (and documenting) code and not reading, refactoring, or collaborating on it. The time people spend writing unnecessary, buggy unit tests (that static analysis can do in better languages) is far greater than the time to just use the type system. Most languages don't even force you to be exp…

For what it’s worth, I agree with the GP comment when it comes to network services and for quickly prototyping things out. I’ve been writing in rust almost exclusively for the last few years, but I still reach for typescript from time to time. JS/TS just requires fewer decisions per line of code. As a pithy example, in javascript I don’t have to decide whether I want a String / &str / SmartString / Rc , etc. It’s jus…

Rust programs take more effort to write initially, but less effort throughout the software lifecycle. Unless you're writing code just to throw it away and not even run it once (which practically doesn't ever happen, at least not intentionally) Rust front-loading the effort is the right trade off.

Never mind that some of these choices you can just avoid by thinking in general terms and deferring optimization for later. Just passing String and FnMut everywhere will be a lot more efficient than whatever the JS translates to on the machine.

Re: Thoughts on what a next Rust compiler would do

#119

Post by mr_00ff00 »

satvikpendem wrote: post #114
mr_00ff00 wrote: post #103

Earlier quoted context omitted.

In fairness, I don’t think rust in web dev makes any sense outside of personal hobby projects. I’m not surprised there’s lots of abandoned and unfinished projects there. That’s not an important area.

For backend APIs it absolutely makes sense, not only for the safety guarantees but also its type system which makes data flows much easier to reason about. I recommend the book Zero To Production in Rust in particular for learning about this, I finished it recently and at the end I had a production-ready backend API. https://zero2prod.com

Rust isn’t as safe as GCed language and you don’t need systems level speed on a backend API.

Rust’s safety is better than C/C++, but memory vulnerabilities are found in cargo packages because of unsafe code.

Re: Thoughts on what a next Rust compiler would do

#120

Post by satvikpendem »

mr_00ff00 wrote: post #119
satvikpendem wrote: post #114

Earlier quoted context omitted.

For backend APIs it absolutely makes sense, not only for the safety guarantees but also its type system which makes data flows much easier to reason about. I recommend the book Zero To Production in Rust in particular for learning about this, I finished it recently and at the end I had a production-ready backend API. https://zero2prod.com

Rust isn’t as safe as GCed language and you don’t need systems level speed on a backend API. Rust’s safety is better than C/C++, but memory vulnerabilities are found in cargo packages because of unsafe code.

> you don’t need systems level speed on a backend API.

I do, actually.

> but memory vulnerabilities are found in cargo packages because of unsafe code.

Forbid unsafe in your config and you're good.

Post reply on HN