11 ms·

Thoughts on what a next Rust compiler would do

214 points by arunc 4y ago

echelon 4y ago
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.
- karmakurtisaani 4y ago
  Web3 or something useful?
  - deleted 4y ago
    [deleted]
- elabajaba 4y ago
  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 https://github.com/bjorn3/rustc_codegen_cranelift
TylerE 4y ago
I say this with great respect, but the thing keeping me from Rust isn't the compiler, it's the language.
- echelon 4y ago
  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 well for a systems language.
  - TylerE 4y ago
    The borrow checker. The syntax. It isn't a good fit for my needs. It'd be like using a forklift to move a few books. I'm not generally a fan of strong explicit typing/high ceremony in general.
    - MuffinFlavored 4y ago
      Curious, are you a fan of Typescript?
      - TylerE 4y ago
        Never used it. I don't even have the need to touch vanilla javascript that often.
        MuffinFlavored 4y ago
        What do you primarily program in, Java? C#? Python?
        TylerE 4y ago
        Python
        satvikpendem 4y ago
        Then that makes a lot of sense why you might not like types. I'd say give Type Driven Development a try, where you layout the data flows for a program through its types, then you fill in the actual code which becomes very easy. I wrote about this in another comment before (in Rust, but you can even do it in Python with its type hinting): https://news.ycombinator.com/item?id=34454158#34492209 https://news.ycombinator.com/item?id=34454158#34492209
    - smt88 4y ago
      > 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 explicit anymore. They infer the types, so you don't even write extra code. You just get better errors and speed.
- vore 4y ago
  I felt this way about Rust for a really long time, but after sitting down and doing a few projects with Rust I've really come to appreciate how much the language stops me from being a dumbass.
- WinstonSmith84 4y ago
  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 incrementally. Also, I find cross-compilation (from/to major platforms) really challenging on Rust, as opposed to Golang where it's for my use cases super straightforward
  - stefncb 4y ago
    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.
    - TylerE 4y ago
      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.
    - acedTrex 4y ago
      so you want Go then?
    - oconnor663 4y ago
      It's worth pointing out that if you say "Go except with Rust's guarantees for thread safety", a _lot_ of the complexity comes back. You need to pull in lifetimes and move semantics and the no-mutable-aliasing rule. You need the Send and Sync traits. You probably want Deref-based smart pointers too. (And you'd need to make extensive use of the new generics features that are already in Go.)
      - 4y ago
- LAC-Tech 4y ago
  It's the standard library & tooling for me. To be perfectly honest for must stuff I use rust for I'd prefer to have garbage collection. But the standard library and tooling I just too far ahead of the competition (diplomatically avoiding naming languages here)
- loeg 4y ago
  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.)
  - TylerE 4y ago
    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.
    - loeg 4y ago
      > Then we equally don’t need pro rust comments on literally every other thread Correct.
      - josephg 4y ago
        Eh. Every article about Go has the same thing - where regardless of the content of the article people discuss the pros and cons of the language itself. I think it’s a symptom of there not being enough places where adherents of different programming ecosystems can argue back and forth about our choices. I think there’s an unmet need in our community to have those conversations, and there’s probably something healthy in that. It definitely distracts from the specifics of the article though. The corresponding discussion on reddit is much more technical: https://reddit.com/r/rust/comments/10ld2vn/blog_post_next_rust_compiler/ https://reddit.com/r/rust/comments/10ld2vn/blog_post_next_ru...
    - jackmott 4y ago
      [dead]
- alphanullmeric 4y ago
  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.
  - JoshTriplett 4y ago
    > 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.
    - alphanullmeric 4y ago
      No default arguments, named parameters, variadic functions and generics, no C-style arrow operator, the whole default trait thing (why can’t you shorten it to just `..`?). And a bunch of awful reasoning to defend these decisions. Named function arguments are bad but `Iterator<Item=T>` is fine? Default arguments are bad but default trait implementations are fine? Something something implicit behaviour but type inference is ok? It’s to the point where idiomatic rust means writing a three different structs and enums to call a function.
  - spoiler 4y ago
    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/ https://doc.rust-lang.org/std/fmt/
    - tialaramex 4y ago
      Right, the canonical C "Hello, World!" uses C's formatted print, even though obviously it's not formatting anything, so it seems appropriate for Rust to do the same. It would be more impressive if Rust had an actual type checked variadic print format function like C++ 23's std::println - nobody should be under any false impression about how impressive that feature is, but the type safe macro is effective, that'll do pig.
- pizza234 4y ago
  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.
baq 4y ago
How much faster can the compiler be? This is the top issue with rust IMHO - compile times are real bad.
- the_mitsuhiko 4y ago
  If you consider how much LLVM instructions are emitted and how much time Rust spends linking, the potential for speedups seems very significant.
- WinstonSmith84 4y ago
  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?
  - bonzini 4y ago
    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++.
    - sk0g 4y ago
      Does anyone particularly care if development builds inline much? If you can get Go-like compile speeds for development iteration, and the current ones for release, it would be the best of both worlds for me.
      - loeg 4y ago
        In fact, that's exactly why cargo's default for dev builds is -O0: https://doc.rust-lang.org/book/ch14-01-release-profiles.html#:~:text=The%20default%20opt%2Dlevel%20for%20dev%20is%20therefore%200 https://doc.rust-lang.org/book/ch14-01-release-profiles.html...
        gnuvince 4y ago
choeger 4y ago
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.
- tomsmeding 4y ago
  > 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.
  - choeger 4y ago
    > 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.
    - 4y ago
Animats 4y ago
There are already at least two Rust compilers, now that there's a GCC version. That's good; it means the language becomes stronger than the implementation. Right now, the weak points are mostly library side. Too many 0.x version crates where the API is still in flux.
- dgb23 4y ago
  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 props of the language. But the stability to hype ratio seems unattractive overall, even though the language and tooling are great to a large extent.
  - mr_00ff00 4y ago
    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.
    - satvikpendem 4y ago
      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 https://zero2prod.com
      - mr_00ff00 4y ago
        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.
thagsimmons 4y ago
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 secretive and opaque about its internal politics, so I don't know if there's any unified reason for the attrition, and I don't think it's useful to try to read the tea leaves. At this point, I'm just keen to be reassured that Rust has the momentum to complete things like async and shore up holes in the type system on a reasonable timescale.
- spoiler 4y ago
  > 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?
  - thagsimmons 4y ago
    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-1181969253 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.
    - kibwen 4y ago
      Most of the high-profile departures from the compiler happened in the wake of the 2018 edition (the first new edition since 1.0, and the edition that had to invent the very notion of "edition"), where a lot of people pushed themselves far too hard to deliver on what would be, in retrospect, far too aggressive of a release deadline. The edition just barely made it out in the 2018 calendar year, after getting delayed a handful of times, but it resulted in massive burnout among those contributing to its features, including the person who wrote the comment linked above. In practice Rust has actually been recovering quite nicely over the past few years after reaching a nadir of volunteer motivation in 2019; https://github.com/rust-lang/rust/pulse/monthly https://github.com/rust-lang/rust/pulse/monthly tells me that 178 discrete authors have contributed to just the rust-lang/rust repo over the past month.
bdickason 4y ago
I recently spun up a project in Rust (a small game using Bevy) and the main issues I ran into were around smart defaults for the compiler. I was surprised how many lines I had to add to my cargo.toml to just complete a simple game example. Some examples: It defaulted to the fully backwards compatible version (vs 2021) which threw errors as I went through some recent example code. (I think) I had to add a few lines to my cargo.toml so the compiler would not rebuild bevy every time I recompiled (when I only changed 1 line in my program).
- TheDong 4y ago
  > It defaulted to the fully backwards compatible version (vs 2021) "cargo init" and "cargo new" default to the 2021 edition, and have ever since it was stabilized: https://github.com/rust-lang/cargo/pull/9800 https://github.com/rust-lang/cargo/pull/9800 Either you accidentally installed a version of cargo from before the 2021 edition was stabilized, or you ran "cargo new --edition <something>", or you started by cloning an out of date project of some sort, in which case it's not really an issue with "defaults". > smart defaults for the compiler. I was surprised how many lines I had to add to my cargo.toml Normally this would be a pointlessly pedantic point, but cargo is not the compiler. This thread, the linked title blog post, they are about the rust compiler, not cargo. There's a close relationship, but cargo's defaults aren't necessarily related to what the "next rust compiler" might do.
  - bdickason 4y ago
    Thanks this is helpful! I started my project without cargo at first and tried to start writing code without a cargo.toml. I was surprised that cairo didn't default to 2021 until I specified it in the .toml file. Good point that cargo init/new would have solved this! I guess my point about the compiler was that it seems to rely on cargo.toml for many 'optimizations' that I would expect to be defaults. (Examples include the two i mentioned above). But I'm new to the language and understand that most people will just use `cargo init` and google a few other common cargo.toml settings to improve compile times.
    - 4y ago
deleted 4y ago
[deleted]

214 points by arunc 4y ago

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.

karmakurtisaani 4y ago
Web3 or something useful?
- deleted 4y ago
  [deleted]
elabajaba 4y ago
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 https://github.com/bjorn3/rustc_codegen_cranelift

TylerE 4y ago

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

echelon 4y ago
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 well for a systems language.
- TylerE 4y ago
  The borrow checker. The syntax. It isn't a good fit for my needs. It'd be like using a forklift to move a few books. I'm not generally a fan of strong explicit typing/high ceremony in general.
  - MuffinFlavored 4y ago
    Curious, are you a fan of Typescript?
    - TylerE 4y ago
      Never used it. I don't even have the need to touch vanilla javascript that often.
      - MuffinFlavored 4y ago
        What do you primarily program in, Java? C#? Python?
        TylerE 4y ago
        Python
        satvikpendem 4y ago
        Then that makes a lot of sense why you might not like types. I'd say give Type Driven Development a try, where you layout the data flows for a program through its types, then you fill in the actual code which becomes very easy. I wrote about this in another comment before (in Rust, but you can even do it in Python with its type hinting): https://news.ycombinator.com/item?id=34454158#34492209 https://news.ycombinator.com/item?id=34454158#34492209
  - smt88 4y ago
    > 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 explicit anymore. They infer the types, so you don't even write extra code. You just get better errors and speed.
vore 4y ago
I felt this way about Rust for a really long time, but after sitting down and doing a few projects with Rust I've really come to appreciate how much the language stops me from being a dumbass.
WinstonSmith84 4y ago
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 incrementally. Also, I find cross-compilation (from/to major platforms) really challenging on Rust, as opposed to Golang where it's for my use cases super straightforward
- stefncb 4y ago
  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.
  - TylerE 4y ago
    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.
  - acedTrex 4y ago
    so you want Go then?
  - oconnor663 4y ago
    It's worth pointing out that if you say "Go except with Rust's guarantees for thread safety", a _lot_ of the complexity comes back. You need to pull in lifetimes and move semantics and the no-mutable-aliasing rule. You need the Send and Sync traits. You probably want Deref-based smart pointers too. (And you'd need to make extensive use of the new generics features that are already in Go.)
    - 4y ago
LAC-Tech 4y ago
It's the standard library & tooling for me. To be perfectly honest for must stuff I use rust for I'd prefer to have garbage collection. But the standard library and tooling I just too far ahead of the competition (diplomatically avoiding naming languages here)
loeg 4y ago
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.)
- TylerE 4y ago
  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.
  - loeg 4y ago
    > Then we equally don’t need pro rust comments on literally every other thread Correct.
    - josephg 4y ago
      Eh. Every article about Go has the same thing - where regardless of the content of the article people discuss the pros and cons of the language itself. I think it’s a symptom of there not being enough places where adherents of different programming ecosystems can argue back and forth about our choices. I think there’s an unmet need in our community to have those conversations, and there’s probably something healthy in that. It definitely distracts from the specifics of the article though. The corresponding discussion on reddit is much more technical: https://reddit.com/r/rust/comments/10ld2vn/blog_post_next_rust_compiler/ https://reddit.com/r/rust/comments/10ld2vn/blog_post_next_ru...
  - jackmott 4y ago
    [dead]
alphanullmeric 4y ago
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.
- JoshTriplett 4y ago
  > 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.
  - alphanullmeric 4y ago
    No default arguments, named parameters, variadic functions and generics, no C-style arrow operator, the whole default trait thing (why can’t you shorten it to just `..`?). And a bunch of awful reasoning to defend these decisions. Named function arguments are bad but `Iterator<Item=T>` is fine? Default arguments are bad but default trait implementations are fine? Something something implicit behaviour but type inference is ok? It’s to the point where idiomatic rust means writing a three different structs and enums to call a function.
- spoiler 4y ago
  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/ https://doc.rust-lang.org/std/fmt/
  - tialaramex 4y ago
    Right, the canonical C "Hello, World!" uses C's formatted print, even though obviously it's not formatting anything, so it seems appropriate for Rust to do the same. It would be more impressive if Rust had an actual type checked variadic print format function like C++ 23's std::println - nobody should be under any false impression about how impressive that feature is, but the type safe macro is effective, that'll do pig.
pizza234 4y ago
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.

baq 4y ago

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

the_mitsuhiko 4y ago
If you consider how much LLVM instructions are emitted and how much time Rust spends linking, the potential for speedups seems very significant.
WinstonSmith84 4y ago
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?
- bonzini 4y ago
  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++.
  - sk0g 4y ago
    Does anyone particularly care if development builds inline much? If you can get Go-like compile speeds for development iteration, and the current ones for release, it would be the best of both worlds for me.
    - loeg 4y ago
      In fact, that's exactly why cargo's default for dev builds is -O0: https://doc.rust-lang.org/book/ch14-01-release-profiles.html#:~:text=The%20default%20opt%2Dlevel%20for%20dev%20is%20therefore%200 https://doc.rust-lang.org/book/ch14-01-release-profiles.html...
      - gnuvince 4y ago

choeger 4y ago

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.

tomsmeding 4y ago
> 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.
- choeger 4y ago
  > 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.
  - 4y ago

Animats 4y ago

There are already at least two Rust compilers, now that there's a GCC version. That's good; it means the language becomes stronger than the implementation. Right now, the weak points are mostly library side. Too many 0.x version crates where the API is still in flux.

dgb23 4y ago
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 props of the language. But the stability to hype ratio seems unattractive overall, even though the language and tooling are great to a large extent.
- mr_00ff00 4y ago
  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.
  - satvikpendem 4y ago
    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 https://zero2prod.com
    - mr_00ff00 4y ago
      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.

thagsimmons 4y ago

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 secretive and opaque about its internal politics, so I don't know if there's any unified reason for the attrition, and I don't think it's useful to try to read the tea leaves. At this point, I'm just keen to be reassured that Rust has the momentum to complete things like async and shore up holes in the type system on a reasonable timescale.

spoiler 4y ago
> 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?
- thagsimmons 4y ago
  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-1181969253 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.
  - kibwen 4y ago
    Most of the high-profile departures from the compiler happened in the wake of the 2018 edition (the first new edition since 1.0, and the edition that had to invent the very notion of "edition"), where a lot of people pushed themselves far too hard to deliver on what would be, in retrospect, far too aggressive of a release deadline. The edition just barely made it out in the 2018 calendar year, after getting delayed a handful of times, but it resulted in massive burnout among those contributing to its features, including the person who wrote the comment linked above. In practice Rust has actually been recovering quite nicely over the past few years after reaching a nadir of volunteer motivation in 2019; https://github.com/rust-lang/rust/pulse/monthly https://github.com/rust-lang/rust/pulse/monthly tells me that 178 discrete authors have contributed to just the rust-lang/rust repo over the past month.

bdickason 4y ago

I recently spun up a project in Rust (a small game using Bevy) and the main issues I ran into were around smart defaults for the compiler. I was surprised how many lines I had to add to my cargo.toml to just complete a simple game example. Some examples: It defaulted to the fully backwards compatible version (vs 2021) which threw errors as I went through some recent example code. (I think) I had to add a few lines to my cargo.toml so the compiler would not rebuild bevy every time I recompiled (when I only changed 1 line in my program).

TheDong 4y ago
> It defaulted to the fully backwards compatible version (vs 2021) "cargo init" and "cargo new" default to the 2021 edition, and have ever since it was stabilized: https://github.com/rust-lang/cargo/pull/9800 https://github.com/rust-lang/cargo/pull/9800 Either you accidentally installed a version of cargo from before the 2021 edition was stabilized, or you ran "cargo new --edition <something>", or you started by cloning an out of date project of some sort, in which case it's not really an issue with "defaults". > smart defaults for the compiler. I was surprised how many lines I had to add to my cargo.toml Normally this would be a pointlessly pedantic point, but cargo is not the compiler. This thread, the linked title blog post, they are about the rust compiler, not cargo. There's a close relationship, but cargo's defaults aren't necessarily related to what the "next rust compiler" might do.
- bdickason 4y ago
  Thanks this is helpful! I started my project without cargo at first and tried to start writing code without a cargo.toml. I was surprised that cairo didn't default to 2021 until I specified it in the .toml file. Good point that cargo init/new would have solved this! I guess my point about the compiler was that it seems to rely on cargo.toml for many 'optimizations' that I would expect to be defaults. (Examples include the two i mentioned above). But I'm new to the language and understand that most people will just use `cargo init` and google a few other common cargo.toml settings to improve compile times.
  - 4y ago

deleted 4y ago

[deleted]