3 ms·

This lifetimes thing is maybe not even a top 3 mistake Rust makes. I hope successor languages can have a metaprogramming system that is less dreadful than proc

This lifetimes thing is maybe not even a top 3 mistake Rust makes. I hope successor languages can have a metaprogramming system that is less dreadful than proc macros, the ability for users to write libraries that are generic over user-provided writers, readers, and allocators, and the ability to bubble up errors from functions that call fallible functions from 2 different libraries without writing your own huge struct definition every time. It may also be nice if constructs that don't cause memory accesses and only ever do the correct thing or crash on the target cpu (such as integer division or pshufb without an address operand on any intel chip ever) were not unsafe. Placing "Well, LLVM says this arithmetic operation is UB and we won't bother to fix it" and "What if one day there's an x64 chip that does something other than crash if it encounters instructions from ISA extensions it does not have?" into the same bucket as "playing with raw pointers" is a bit weird.

anonymousdang 2y ago
[flagged]
conaclos 2y ago
proc_macros are so terrible and propagate attributes everywhere. It would be so much easier to write derive macros with reflection support. This would also avoid fragile code generation in some cases.
- estebank 2y ago
  Proc macros in Rust are objectively bad in a number of ways (limited to only dealing with tokens/no type system access, hard for newcomers to grasp and write, force a lot of attributes to be written to annotate specific items, etc.) but they exemplify "worse is better" perfectly. They are incredibly powerful and allow people to build amazing abstractions that are in some cases best in class. We want to have something better, but there isn't a pressing need to rush a replacement.
estebank 2y ago
Calling them mistakes is actively ignoring that there are design constraints and decisions that shape what the language looks and acts like. And that's without getting into "there are only so many hours in a day, a limited amount of people, so not everything is getting done at the same speed, if at all". It's the first time I hear your second point about intrinsics, for example, and it seems like something that could be done relatively straightforwardly, but introducing "inconsistency" for the benefit of skipping a single unsafe block sounds like the kind of RFC thread I wouldn't want to be a part of.
- anonymoushn 2y ago
  I don't really think the ownership-related concerns around thread-local storage that ruled out stackful coroutines are valid. Stacks and threads are orthogonal in the same way that futures and threads are orthogonal in the existing design for async. This design has caused a proliferation of dozens of fundamentally non-composable libraries addressing barely-different use cases and leaving many use cases unaddressed, likely wasting much more time than it would have taken to get this right. Various prior art has existed for decades. I accept that languages that are designed collaboratively by huge numbers of people through an RFC process are basically impossible to improve.
mst 2y ago
I think the UB thing is at least arguable in some cases, certainly. But I think the ISA extension thing is absolutely a good idea for the simple reason that if that ever changed you would be -screwed- and forcing people to Think Really Hard about their usage if ISA extensions is probably a net win anyway. Possibly they should be in a second "bucket of scary stuff" with a different set of hazard stickers applied, but using unsafe for all of it makes sense from the POV of 'unsafe means I am voiding my warranty inside this block' rather than anything more specific.
cryptonector 2y ago
> and the ability to bubble up errors from functions that call fallible functions from 2 different libraries without writing your own huge struct definition every time. Please, no exceptions. No exceptions. There was a language featured on HN recently that did a good job of making it trivial to build sum types for results/errors from disparate other sum types for results/errors. It can be made easy while retaining the idea of using a sum type for results.
- nmsmith 2y ago
  Do you remember what language that was? Or at least, how I'd find it? I'd be interested in checking it out.

anonymousdang 2y ago

[flagged]

conaclos 2y ago

proc_macros are so terrible and propagate attributes everywhere. It would be so much easier to write derive macros with reflection support. This would also avoid fragile code generation in some cases.

estebank 2y ago
Proc macros in Rust are objectively bad in a number of ways (limited to only dealing with tokens/no type system access, hard for newcomers to grasp and write, force a lot of attributes to be written to annotate specific items, etc.) but they exemplify "worse is better" perfectly. They are incredibly powerful and allow people to build amazing abstractions that are in some cases best in class. We want to have something better, but there isn't a pressing need to rush a replacement.

estebank 2y ago

Calling them mistakes is actively ignoring that there are design constraints and decisions that shape what the language looks and acts like. And that's without getting into "there are only so many hours in a day, a limited amount of people, so not everything is getting done at the same speed, if at all". It's the first time I hear your second point about intrinsics, for example, and it seems like something that could be done relatively straightforwardly, but introducing "inconsistency" for the benefit of skipping a single unsafe block sounds like the kind of RFC thread I wouldn't want to be a part of.

anonymoushn 2y ago
I don't really think the ownership-related concerns around thread-local storage that ruled out stackful coroutines are valid. Stacks and threads are orthogonal in the same way that futures and threads are orthogonal in the existing design for async. This design has caused a proliferation of dozens of fundamentally non-composable libraries addressing barely-different use cases and leaving many use cases unaddressed, likely wasting much more time than it would have taken to get this right. Various prior art has existed for decades. I accept that languages that are designed collaboratively by huge numbers of people through an RFC process are basically impossible to improve.

mst 2y ago

I think the UB thing is at least arguable in some cases, certainly. But I think the ISA extension thing is absolutely a good idea for the simple reason that if that ever changed you would be -screwed- and forcing people to Think Really Hard about their usage if ISA extensions is probably a net win anyway. Possibly they should be in a second "bucket of scary stuff" with a different set of hazard stickers applied, but using unsafe for all of it makes sense from the POV of 'unsafe means I am voiding my warranty inside this block' rather than anything more specific.

cryptonector 2y ago

> and the ability to bubble up errors from functions that call fallible functions from 2 different libraries without writing your own huge struct definition every time. Please, no exceptions. No exceptions. There was a language featured on HN recently that did a good job of making it trivial to build sum types for results/errors from disparate other sum types for results/errors. It can be made easy while retaining the idea of using a sum type for results.

nmsmith 2y ago
Do you remember what language that was? Or at least, how I'd find it? I'd be interested in checking it out.