> 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
> 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)
- 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"!)
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
> 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