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

51–60 of 147 posts

Re: Thoughts on what a next Rust compiler would do

#51

Post by tcmart14 »

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…

The slow compile times I look at as a trade off. Rust does a lot more during it's compile phase than most other compilers and there is a cost. Do I do all this static analysis and eat time here to hopefully reduce runtime bugs and subsequently the time to debug runtime bugs? It takes me a whole lot longer to debug something with a debugger than if the compiler can catch it.

I do 100% agree on your commends on cross compiling though. I also don't like how the target for linux has "unknown" in it.

Re: Thoughts on what a next Rust compiler would do

#52

Post by tomsmeding »

choeger wrote: post #24

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…

> 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.

This is true in only the simplest case. Already if you have a polymorphic function that sums the elements of an array, you'll be doing function calls to string concatenation if those elements are strings but would really like the vectoriser to produce nice SIMD code when specialised to floats.

Specialisation is something that should happen before the optimiser.

Re: Thoughts on what a next Rust compiler would do

#53

Post by tcmart14 »

nicoburns wrote: post #46
nonethewiser wrote: post #16

Earlier quoted context omitted.

Not OP but for me it's the syntax. I'm not even saying it's bad or could even be improved... I just don't find it intuitive. I've only sat down and walked through some of the learn rust book and tried to hack out a few small things. I'm not sure what it is - there just always seem to be random symbols that dont seem to follow conventions of other languages. Guess I am use to C-style (including C++, C#, JS) syntax and…

Interestingly very little of Rust's syntax is novel (the exception being lifetimes which of course don't exist in other languages). The closest language syntacticly is probably TypeScript (you'd be surprised how many programs are actually valid in both Rust and Typescript!). And where syntax doesn't match TypeScript it usually matches something else common. For example the `self` parameter in methods comes from Pytho…

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.

Re: Thoughts on what a next Rust compiler would do

#54

Post by [deleted] »

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…

[deleted]

Re: Thoughts on what a next Rust compiler would do

#55

Post by loeg »

TylerE wrote: post #49
loeg wrote: post #37

Earlier quoted context omitted.

That's fine. It doesn't have to be everything to everyone. We probably don't need this kind of comment on every single article about Rust, though. (Or similar generic "I don't like this language" comments on any article related to any programming language.)

Then we equally don’t need pro rust comments on literally every other thread Since a major thrust of the linked article is barriers to rust adoption it seemed relevant.

> Then we equally don’t need pro rust comments on literally every other thread

Correct.

Re: Thoughts on what a next Rust compiler would do

#56

Post by spoiler »

thagsimmons wrote: post #42

This sounds great, but I don't think Rust has the complement of highly skilled core developers needed to tackle something this ambitious. I'm a close observer of the Rust project, and my impression is that Rust's core development team has been hollowed out over the past few years - there's been a string of quiet departures, which sadly included some of the most powerful contributors. The Rust project is quite secreti…

> I'm a close observer of the Rust project, and my impression is that Rust's core development team has been hollowed out over the past few years - there's been a string of quiet departures, which sadly included some of the most powerful contributors.

Can you give more specifics on this?

Re: Thoughts on what a next Rust compiler would do

#57

Post by JoshTriplett »

alphanullmeric wrote: post #44
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.

It would actually be such an amazing language if it wasn’t so verbose. There are so many places where more concise syntax wouldn’t even hurt safety and they forgo it anyways. But here we are, where macros are required for a hello world.

> There are so many places where more concise syntax wouldn’t even hurt safety and they forgo it anyways.

Can you give some examples of this? If there are ways we could simplify the language without hurting existing use cases, we should consider doing so.

Re: Thoughts on what a next Rust compiler would do

#58

Post by JoshTriplett »

tcmart14 wrote: post #53
nicoburns wrote: post #46

Earlier quoted context omitted.

Interestingly very little of Rust's syntax is novel (the exception being lifetimes which of course don't exist in other languages). The closest language syntacticly is probably TypeScript (you'd be surprised how many programs are actually valid in both Rust and Typescript!). And where syntax doesn't match TypeScript it usually matches something else common. For example the `self` parameter in methods comes from Pytho…

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?

Re: Thoughts on what a next Rust compiler would do

#59

Post by matklad »

nicoburns wrote: post #46
nonethewiser wrote: post #16

Earlier quoted context omitted.

Not OP but for me it's the syntax. I'm not even saying it's bad or could even be improved... I just don't find it intuitive. I've only sat down and walked through some of the learn rust book and tried to hack out a few small things. I'm not sure what it is - there just always seem to be random symbols that dont seem to follow conventions of other languages. Guess I am use to C-style (including C++, C#, JS) syntax and…

Interestingly very little of Rust's syntax is novel (the exception being lifetimes which of course don't exist in other languages). The closest language syntacticly is probably TypeScript (you'd be surprised how many programs are actually valid in both Rust and Typescript!). And where syntax doesn't match TypeScript it usually matches something else common. For example the `self` parameter in methods comes from Pytho…

Lifetime _syntax_ is lifted verbatim from OCaml.

Re: Thoughts on what a next Rust compiler would do

#60

Post by choeger »

tomsmeding wrote: post #52
choeger wrote: post #24

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…

> 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. This is true in only the simplest case. Already if you have a polymorphic function that sums the elements of an array, you'll be doing function calls to string concatenation if those elements are strings but would really like the vecto…

> Specialisation is something that should happen before the optimiser.

That's true, but your example shows a very important point: These cases are limited and (in current languages) known by the compiler developers. I don't know a language that would allow a user-defined datatype to come with such specific optimizations. So for today's languages one could probably enumerate the special optimizations before specialization and then later only dispatch to the optimized code.

But even if we say that optimization must happen after specialization, I still think that these optimizations are general enough to be put into a dynamic linker. That's what all JIT engines do, after all.

Post reply on HN