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

21–30 of 147 posts

Re: Thoughts on what a next Rust compiler would do

#21

Post by woodruffw »

packetlost wrote: post #9
echelon wrote: post #7

Earlier quoted context omitted.

What about the language do you dislike? It's a strongly typed Ruby with generics. Edit: trait-based OO is a breath of fresh air compared to tree-style class inheritance. Super flexible without having to overthink. Immutable by default is reassuring, Option/Result are fantastic null/exception replacements. Enums and match blocks are powerful and gracefully help ensure handling of all cases, have nice syntax, and work…

Huh? Rust shares very little with Ruby??? Are you thinking Crystal?

Crystal is directly inspired by Ruby, so I don't think is too far of a bridge!

I programmed Ruby for years before learning Rust, and aspects of Rust's library and language inspiration from Ruby are obvious to me: the closure syntax closely resembles Ruby's blocks, for example, and much of the core iterator APIs match their Ruby counterparts. It's a very different language overall, of course!

(Then of course there's the part where many early Rust contributors came from the Ruby community.)

Re: Thoughts on what a next Rust compiler would do

#22

Post by WinstonSmith84 »

baq wrote: post #5

How much faster can the compiler be? This is the top issue with rust IMHO - compile times are real bad.

Any reasons why it could not be as fast as the Go compiler? Maybe GC and the borrow checker could slow down a bit, but apart from that?

Re: Thoughts on what a next Rust compiler would do

#23

Post by TylerE »

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.

nim comes the closest of anything I've found, the infrastructure just isn't quite there.

ocaml has potential but I strongly dislike the numeric operators, and I'm not a huge fan of the syntax in general.

OCaml with python like syntax would be damn near perfect. I could even overlook the operator thing.

Re: Thoughts on what a next Rust compiler would do

#24

Post by choeger »

I agree that the C-model is keeping Rust back. But it's ubiquitous and extremely successful. Dynamic linking also practically gives us an ABI (a very simplistic one) for free, which is great for FFI and debugging.

So if I could choose, I'd invest money into a new ABI/linker that reconciles polymorphic languages with separate compilation without demanding a uniform object model. Not only Rust would benefit from such a linker.

I have no complete solution for how such a thing might work, but I think it's possible because the actual specializations that stem from monomorphization are very few. It might simply be possible to create one function for every possible monomorphization ahead of time. Even if this turns out to be futile, the actual specialization only needs to change very few things in the code, so monomorphization could effectively be handled by a dynamic linker.

Re: Thoughts on what a next Rust compiler would do

#25

Post by lalaithion »

afr0ck wrote: post #18
echelon wrote: post #7

Earlier quoted context omitted.

What about the language do you dislike? It's a strongly typed Ruby with generics. Edit: trait-based OO is a breath of fresh air compared to tree-style class inheritance. Super flexible without having to overthink. Immutable by default is reassuring, Option/Result are fantastic null/exception replacements. Enums and match blocks are powerful and gracefully help ensure handling of all cases, have nice syntax, and work…

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…

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.

Re: Thoughts on what a next Rust compiler would do

#26

Post by agumonkey »

WinstonSmith84 wrote: post #15
TylerE wrote: post #4

I say this with great respect, but the thing keeping me from Rust isn't the compiler, it's the language.

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…

I don't have much experience but after writing some tiny rust scripts and similar sized things in kotlin (trying kotlinc v1.7 that was supposed to be a lot faster than previous versions), rust managed to stay ahead.

it's true golang is smoother, but the language is a lot messier (idioms and typechecking).

Can't conclude anything yet, but it makes me think back of rust more often than others.

Re: Thoughts on what a next Rust compiler would do

#27

Post by bonzini »

WinstonSmith84 wrote: post #22
baq wrote: post #5

How much faster can the compiler be? This is the top issue with rust IMHO - compile times are real bad.

Any reasons why it could not be as fast as the Go compiler? Maybe GC and the borrow checker could slow down a bit, but apart from that?

The Go compiler is barely an optimizing compiler. Rust needs massive amounts of inlining to avoid the performance cost of abstractions, and after inlining the code needs to be cleaned up. In this respect it isn't unlike C++.

Re: Thoughts on what a next Rust compiler would do

#28

Post by alkonaut »

afr0ck wrote: post #18
echelon wrote: post #7

Earlier quoted context omitted.

What about the language do you dislike? It's a strongly typed Ruby with generics. Edit: trait-based OO is a breath of fresh air compared to tree-style class inheritance. Super flexible without having to overthink. Immutable by default is reassuring, Option/Result are fantastic null/exception replacements. Enums and match blocks are powerful and gracefully help ensure handling of all cases, have nice syntax, and work…

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…

> You really need extremely smart smart data structures and organisation and very smart algorithms to manage the concurrency. C is a language where you have all that freedom to do whatever you want leading to high performance and low latency.

But it leaves that work to the developer, thousands of hours of testing and reviewing to ensure no little corner case is missed.

I think the argument that unsafe is used making the language have “holes” is somewhat misdirected. When I see a rust implementation of a doubly linked list with unsafe I know exactly where I’m on my own (a few lines) and where the compiler does the job for me (the rest of it). It’s not as if that means safety or flexibility is out the window. It means “do the manual safety review on these two lines”.

Re: Thoughts on what a next Rust compiler would do

#29

Post by jolux »

afr0ck wrote: post #18
echelon wrote: post #7

Earlier quoted context omitted.

What about the language do you dislike? It's a strongly typed Ruby with generics. Edit: trait-based OO is a breath of fresh air compared to tree-style class inheritance. Super flexible without having to overthink. Immutable by default is reassuring, Option/Result are fantastic null/exception replacements. Enums and match blocks are powerful and gracefully help ensure handling of all cases, have nice syntax, and work…

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…

> Now, if you have to use unsafe every time you need high performance or scalable data structures, then Rust is as unsafe as C

That's not true, because you can wrap unsafe code in safe interfaces and use it from safe code.

Re: Thoughts on what a next Rust compiler would do

#30

Post by vore »

afr0ck wrote: post #18
echelon wrote: post #7

Earlier quoted context omitted.

What about the language do you dislike? It's a strongly typed Ruby with generics. Edit: trait-based OO is a breath of fresh air compared to tree-style class inheritance. Super flexible without having to overthink. Immutable by default is reassuring, Option/Result are fantastic null/exception replacements. Enums and match blocks are powerful and gracefully help ensure handling of all cases, have nice syntax, and work…

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 kinds of safety guarantees with a lot of discipline. With Rust, you can offload much of your discipline to the compiler.

Post reply on HN