News for hackers. Stuff that matters.

myrrlyn

Re:Lies we tell ourselves to keep using Golang on Friday April 29, 2022 @01:18PM (#31208012)
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
Re:Lies we tell ourselves to keep using Golang on Friday April 29, 2022 @01:10PM (#31207877)
good
Re:Lies we tell ourselves to keep using Golang on Friday April 29, 2022 @01:09PM (#31207866)
yeah the actual titleholder to those is seattle
Re:Lies we tell ourselves to keep using Golang on Friday April 29, 2022 @12:58PM (#31207673)
rustup is available in your package manager's repository
Re:C Isn't a Programming Language Anymore on Wednesday March 16, 2022 @08:31PM (#30706039)
> 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

Re:C Isn't a Programming Language Anymore on Wednesday March 16, 2022 @08:30PM (#30706032)
lol.
Re:Bugs in Hello World on Wednesday March 09, 2022 @11:37AM (#30616510)
given that the sole purpose of software is to do what people want, "it didn't do what i want" is automatically incorrect behavior
Re:Why doesn’t natural immunity count in the US? on Tuesday September 14, 2021 @06:27PM (#28532350)
is this going well for you
Re:I refuse to let Amazon define Rust on Monday September 13, 2021 @01:29PM (#28514201)
?
Re:GCC Rust Monthly Report #9 August 2021 on Tuesday August 31, 2021 @05:16PM (#28373786)
> Rust must stabilize its ABI if it seeks to be a useful systems language.

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

Re:GCC Rust Monthly Report #9 August 2021 on Tuesday August 31, 2021 @05:07PM (#28373674)
> 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)

Re:GCC Rust Monthly Report #9 August 2021 on Tuesday August 31, 2021 @05:00PM (#28373600)
why not
Re:GCC Rust Monthly Report #9 August 2021 on Tuesday August 31, 2021 @04:56PM (#28373552)
(there are none)
Re:Understanding Rust futures by going way too deep on Monday July 26, 2021 @11:39AM (#27960788)
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"!)

Re:Understanding Rust futures by going way too deep on Monday July 26, 2021 @09:39AM (#27959205)
PRs welcome!
Re:Understanding Rust futures by going way too deep on Monday July 26, 2021 @07:19AM (#27958083)
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
Re:Understanding Rust futures by going way too deep on Monday July 26, 2021 @07:17AM (#27958066)
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

Re:Understanding Rust futures by going way too deep on Monday July 26, 2021 @07:15AM (#27958054)
> 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.

Re:Static Integer Types on Thursday July 01, 2021 @12:25PM (#27700863)
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
Re:An RFC that adds support for Rust to the Linux kernel on Saturday April 17, 2021 @02:26PM (#26846328)
this magical thinking about standards documents is one of the primary incentives to not have one
Re:An RFC that adds support for Rust to the Linux kernel on Saturday April 17, 2021 @02:17PM (#26846274)
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
Re:Linus Torvalds on Rust support in kernel on Saturday April 17, 2021 @02:05PM (#26846185)
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

Re:Linus Torvalds on Rust support in kernel on Saturday April 17, 2021 @01:41PM (#26845991)
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
Re:Linus Torvalds on Rust support in kernel on Saturday April 17, 2021 @01:35PM (#26845948)
putting my marker on 2030 as implementing a tokio runtime in kernelspace
Re:Linus Torvalds on Rust support in kernel on Saturday April 17, 2021 @01:33PM (#26845923)
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
Re:Linus Torvalds on Rust support in kernel on Saturday April 17, 2021 @01:31PM (#26845907)
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
Re:Speed of Rust vs. C on Saturday March 13, 2021 @08:58PM (#26452080)
lol
Re:Speed of Rust vs. C on Saturday March 13, 2021 @07:48PM (#26451678)
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)

Re:Speed of Rust vs. C on Saturday March 13, 2021 @07:41PM (#26451632)
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

Older »