myrrlyn

why isn't it inconsistent to allow creation of a record with missing components but to deny creation of a stack frame with missing components

good

yeah the actual titleholder to those is seattle

rustup is available in your package manager's repository

> C is an amazing language

[citation needed]

> the best way to use C is to use it to implement core algorithms and data structures

is this a joke. you literally cannot write containers in C unless you commit to heap-allocating everything and storing it as void*

> Most software engineers I know who have a background in EE love C, simply because it maps very well to what a processor actually does during execution.

lol. no it absolutely does not. i have a B.S. CpE and have actually built simple processors. the C execution model has nothing to do with how silicon operates, and modern silicon in particular goes to absurd lengths to put up a façade that c programs can use to pretend they're still on a pdp-11 while the processor goes and does other things.

easy example: here's a memory address. what happens when you try to read from it

lol.

given that the sole purpose of software is to do what people want, "it didn't do what i want" is automatically incorrect behavior

is this going well for you

?

> Rust must stabilize its ABI if it seeks to be a useful systems language.

? no it mustn't. what's the c++ abi

> Having multiple implementations is a sign of a healthy programming language

this is frequently taken as axiomatic but there's no actual support for it in reality. there are plenty of healthy single-implementation languages (go, rust, scala, erlang) and plenty of unhealthy multi-implementation languages (c, d, sql, javascript) to go alongside the healthy/multi (python, ruby) and unhealthy/single (php, i guess, i don't care about this quadrant very much)

why not

(there are none)

every time this comes up i just have to ask

- what do you think a language standard is or does

- what languages with standards do you think standardization has helped (this is a trick question! do not answer "c" or "c++"!)

- in which languages with standards is a plurality of code written to that standard? (this is also a trick question! do not answer "c", "c++", or "javascript"!)

PRs welcome!

yeah, bounds written on the type decl shouldn't be repeated on the impl. the current typeck is not smart enough to do that but the ever-"nearly there we promise" replacement is. it'll land one day. they promise

the reason for

> I still feel uneasy depending on so many other crates, but this seems to be a level of paranoia that others in the community don't share. Having 1000 dependencies sounds crazy to me! If there's a bug in even one of them that affects you then there's gonna be a lot of digging to figure out the cause

is that there is far, far more likely to be a bug in the version you write on your own to achieve the same goal than there is in a widely-observed library written by somebody who's chosen to specialize in that specific thing

> What slice of Rust users are both such noobs they haven’t heard of cargo-edit and can’t Google it, but also so advanced they are interested in implementing Future manually to deepen their understanding?

My colleagues. Many people are skilled programmers jumping into obscure problems with only a baseline level of familiarity with the greater environment.

I am the author of a library that requires knowledge and awareness of integers that are strictly not wider than the general purpose register on the processor; the fact that `usize` is "the largest GPR" on every target Rust knows about is great but I'd still appreciate a distinction between "this fits in exactly one GPR" vs "this fits in the address bus"

_especially_ since the library in question creates pointers that are wider than `usize`

the good news is that a vector of any object can be reduced to a vector of integers by `Box`ing, and then you only incur a miss when you access the data, but not during every step you take to find the data

this magical thinking about standards documents is one of the primary incentives to not have one

yeah this is a common pattern in runtime permissions modelling. it's a really cool trick and i hope it gets more awareness from cases like this

the unstated part here is that in the absence of a compiler-visible atomic modelling system, an atomic model is implemented in `core::atomic` and LLVM. similarly, a `kcore` library could provide atomic types just like the way the LKMM is defined as a library in-tree.

this is not a language limitation, as the language is able to emit LLVM atomic operations just fine. like allocations, it needs people with a defined goal (like the kernel) to provide a target for implementations to reach; proäctive creation of a model without knowing if it has an audience is not worthwhile, which is why it hasn't been done

unless you plan to run `rustc` as a kernelspace application, anything in tier 2 (`core`, `alloc`, maybe `std` all compile and likely pass tests) is sufficient

putting my marker on 2030 as implementing a tokio runtime in kernelspace

a replacement to `alloc` would define a `Box` structure and tag it as `#[lang = "box"]` but not define any crashy APIs. this would accomplish the goal, but is an annoying patch that `alloc` should work to obviate upstream

There is some work in progress to make it easier to tell Cargo to build `core`/`alloc`, which in turn would allow projects to maintain patches atop them like disabling floating-point or oom-panicking APIs entirely. I suspect that this effort will get a great deal of motivation from being a kernel requirement

lol

the main problem here is that C has the capability to declare mmap regions correctly: `volatile char[]` and Rust does not (`[Cell<u8>]` is close but not exactly right, and annoying)

most rust folks who use mmap don't mark the region as Celled, which means they risk UB in the form of incorrect behavior because the compiler assumes that the memory region is untouchable outside the single Rust program, and that's not true

(it's also not true generally b/c /dev/mem and /proc/pid/mem exist, but it's beyond Rust's scope that the OS allows intrusion like that)

for one thing, naming a C struct requires more words than naming a Rust struct; for another, the names of functions that operate on them