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

61–70 of 147 posts

Re: Thoughts on what a next Rust compiler would do

#61

Post by spoiler »

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.

You don't technically need the macro to print hello world. However, the macro is useful due to format strings, which are also type-checked (eg to checks if the args implement `Display` or `Debug`, etc).

The good thing about the default hello world example is that it introduces you to both language features without being overwhelming (IMO).

You can read more about format strings here: https://doc.rust-lang.org/std/fmt/

Re: Thoughts on what a next Rust compiler would do

#62

Post by nyanpasu64 »

lalaithion wrote: post #25
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…

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 a playground at https://play.rust-lang.org/?version=stable&mode=debug&editio.... It's not just dereferencing invalid */& that's illegal in Rust, but constructing and dereferencing valid &/&mut in ways that don't respect tree-shaped mutability. Rust's pointer aliasing rules invalidate otherwise-correct code, placing roadblocks in the way of writing correct code. There's so much creation of &mut (which invalidates aliasing pointers for the duration of the &mut, and invalidates sibling &mut and all pointers constructed from them), that's so implicit I don't know what's legal and what's not by auditing code. (Box used to also invalidate aliasing pointers, but this may be changed. The current plan for enabling self-reference is Pin, but the exact semantics for how and when putting a &mut T in a wrapper struct makes it not invalidate self-reference and incoming pointers, is still not specified.)

(I've elaborated further at https://news.ycombinator.com/item?id=33658253.)

Re: Thoughts on what a next Rust compiler would do

#63

Post by pcwalton »

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…

People come and go from every project. I haven't noticed any particular drop in momentum for the Rust compiler. (Also, the Rust compiler dev community is hardly "secretive and opaque"--just look at the amount of drama that regularly spills out into the open. I can't think of any compiler that's more openly developed than Rust, in fact.)

A brand-new Rust compiler may well never happen, but if it doesn't happen it's because the business value for a complete rewrite isn't there, not because of some mass departure of compiler developers.

Re: Thoughts on what a next Rust compiler would do

#64

Post by elabajaba »

echelon wrote: post #2

All of this sounds fantastic. I can't donate my time, but I'd be happy to donate money to anyone taking on this effort. On that note, I'm looking for more Rust crates and maintainers to donate to. I just started paying Bevy, and I'm looking for more areas of the Rust ecosystem that need it. This language brings me immense business and personal value, and I'm happy to give back.

Bjorn3 for all their work on cranelift and working towards getting it to be a better debug compiler for rust.[1]

cwfitzgerald for wgpu. He took over as the head maintainer after kvark left Mozilla to go to Tesla.

winit maintainers, they're a core ecosystem crate but don't get that much support because windowing isn't flashy.

[1] https://github.com/bjorn3/rustc_codegen_cranelift

Re: Thoughts on what a next Rust compiler would do

#65

Post by jackmott »

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.

[dead]

Re: Thoughts on what a next Rust compiler would do

#66

Post by spoiler »

matklad wrote: post #59
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…

Lifetime _syntax_ is lifted verbatim from OCaml.

Not quite used for the same thing, but Haskell also allows using 'x (for symbol names)

Re: Thoughts on what a next Rust compiler would do

#67

Post by nonethewiser »

mlindner wrote: post #32
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…

New syntax is pretty easy to pick up. It's just window dressing. What you're actually seeing is a trap a lot of programmers fall into where if something is unfamiliar then it's treated as if it's incorrect.

> What you're actually seeing is a trap a lot of programmers fall into where if something is unfamiliar then it's treated as if it's incorrect.

I said that I don't think it's bad or wrong.

Re: Thoughts on what a next Rust compiler would do

#68

Post by thagsimmons »

spoiler wrote: post #56
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?

I don't want to list specific contributors here. We often have no information on why people left the project - there might be all sorts of personal factors. I will say that my broader sentiment - that Rust's momentum has slowed, that it's not delivering on its commitments in a timely way, that there are concerns about it's ability to deliver in future - has been expressed publicly by high profile past core contributors:

https://github.com/rust-lang/rust/pull/96709#issuecomment-11...

I don't think Rust should tackle any ambitious project to rewrite the compiler while these basic concerns remain.

Re: Thoughts on what a next Rust compiler would do

#69

Post by nicoburns »

matklad wrote: post #59
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…

Lifetime _syntax_ is lifted verbatim from OCaml.

TIL. I haven't used OCaml yet.

Re: Thoughts on what a next Rust compiler would do

#70

Post by pizza234 »

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.

If one wants control over everything and manual memory management as safe as achievable (ie. systems programming), currently, this is the only (major) way.

IMO the market share for this profile is indeed small. Languages that trade off a part of that security for simplicity may have considerably more market share in the future, although on the other hand, the public may instead prefer a "fast-enough and dead-simple" language.

Post reply on HN