> In html you can just view comments as another node in a uniform tree.
When you parse an AST with comments (or a CST), they do become "just another node in a uniform tree". Think about it - in HTML you have a tree of nodes but comments can be anywhere, which is exactly as obnoxious to deal with as a CST where comment nodes can be anywhere.
This is a terrible reason to not support comments. If it was really important, then probably you should support comments in only a couple of places, e.g. on attributes or on selectors.
But I don't think it is very important. I can't think of a single tool that loads CSS, rearranges it, and then spits it back out in a form that would benefit from comments.
Maybe you meant "they can be anywhere that a Node can be in the DOM", but I think that's more or less what the CSS "mistake" is suggesting should be true about CSS (just replace "DOM" with "CSSOM").
> h1, h2, h3 should not have different styles. it's an anti-pattern that leads to broken accessibility
How does that hurt accessibility? Are you saying people use h3 in order to get its style even when they didn't mean h3?
I think the opposite could happen too - if they all have the same style then people might just use h1 everywhere which is probably just as bad. People tend not to use elements that have no obvious use, like <output> which apparently has better accessibility but does absolutely nothing else, so nobody bothers. The whole "semantic web" thing failed partly because of this.
I mean, they aren't wrong. That is part of the purpose. Of course now we try and do it via CSS but it's definitely still fine to use <b> as bold and <i> as italic, even if the semantic pedants will insist that they mean "Bring attention to" and "Idiomatic" (that name's stretched so thin you can see through it!).
> Yeah because normal people never have to deal with alphanumeric strings...
Natural language tends to have a high degree of disambiguating redundancy and is used to communicate between humans, who are good at making use of that. Programming languages have somewhat less of disambiguating redundancy (or in extreme cases almost none), and, most critically, are used to communicate with compilers and interpreters that have zero capacity to make use of it even when it is present.
This makes "letter looks like a digit that would rarely be used in a place where both make sense" a lot more of a problem for a font used with a programming language than a font used for a natural language.
Legal language is natural language with particular domain-specific technical jargon; like other uses of natural language, it targets humans who are quite capable of resolving ambiguity via context and not compilers and interpreters that are utterly incapable of doing so.
Not that official State Department communication is mostly “legal language” as distinct from more general formal use of natural language to start with.
No, because normal people can read "l00l" as a number just fine and don't actually care if the underlying encoding is different. AI won't care either. It's just us on-the-spectrum nerds with our archaic deterministic devices and brains trained on them that get wound up about it. Designing a font for normal readers is just fine.
SiFive have had a very long time to create competitive CPUs and they haven't really managed it. I dunno what's going on there but I'm not sure I'd buy them either.
I mean... "as configured" can me either an allow OR a denylist. That sentence doesn't really prescribe doing it one way or the other..? You have to parse the denylisted elements because they will affect the rest of the parse, so you _have_ to remove them afterwards in the general case.
"Never" is an incredibly strong word, and in the bigger scheme of humanity, the universe, and the next billion or so years, _everything_ that we can imagine will happen.
It's an intellectually lazy argument to make. Like saying "we will never walk on the moon" in the 1900's.
Because a) we know human-level intelligence is possible because we can directly observe it, b) GPU development has clearly slowed a lot but it hasn't stopped, c) even if it had stopped that doesn't mean they can never improve ever again, d) GPUs probably aren't the most efficient architecture for AI anyway so there are more opportunities for development even without process improvements, e) we're clearly not that far off AGI.
This is the sort of thing that might have made sense in 2005, not 2025.
Correction: (a) we can observe the effects of human-level intelligence but we don't actually know what human intelligence is because intelligence is best described as a side-effect of consciousness (aka the experience of qualia) and science has yet to provide a convincing explanation of what that is exactly.
Especially when you consider that the author is apparently an "Assistant Professor at Carnegie Mellon University (CMU) and a Research Scientist at the Allen Institute for Artificial Intelligence (Ai2)".
I don't think unsafe Rust has gotten any easier to write, but I'd also be surprised if there was much unsafe except in the low-level stuff (hard to write Vec without unsafe), and to interface with C which is actually not hard to write.
Mostly Rust has been used for drivers so far. Here's the first Rust driver I found:
Drivers are interesting from a safety perspective, because on systems without an IOMMU sending the wrong command to devices can potentially overwrite most of RAM. For example, if the safe wrappers let you write arbitrary data to a PCIe network card’s registers you could retarget a receive queue to the middle of a kernel memory page.
> if the safe wrappers let you write arbitrary data to a PCIe network card’s registers
Functions like that can and should be marked unsafe in rust. The unsafe keyword in rust is used both to say “I want this block to have access to unsafe rust’s power” and to mark a function as being only callable from an unsafe context. This sounds like a perfect use for the latter.
> Functions like that can and should be marked unsafe in rust.
That's not how it works. You don't mark them unsafe unless it's actually required for some reason. And even then, you can limit that scope to a line or two in majority of cases. You mark blocks unsafe if you have to access raw memory and there's no way around it.
It is how it's supposed to work. `unsafe` is intended to be used on functions where the caller must uphold some precondition(s) in order to not invoke UB, even if the keyword is not strictly required to get the code to compile.
The general rule of thumb is that safe code must not be able to invoke UB.
Yes. I was objecting to the parent poster's "can and should be" which sounds like they think people just randomly choose where to use the unsafe decoration.
The situation seems reminiscent of "using File::open to modify /proc/self/mem". It's safe to work with files, except there's this file that lets you directly violate memory safety.
I can't say I got the same feeling. To me, the "Functions like that" lead-in indicated the opposite if anything since it implies some kind of reasoned consideration of what the function is doing.
All logic, all state management, all per-device state machines, all command parsing and translation, all data queues, etc. Look at the examples people posted in other comments.
Yep. Its kind of remarkable just how little unsafe code you often need in cases like this.
I ported a C skip list implementation to rust a few years ago. Skip lists are like linked lists, but where instead of a single "next" pointer, each node contains an array of them. As you can imagine, the C code is packed full of fiddly pointer manipulation.
The rust port certainly makes use of a fair bit of unsafe code. But the unsafe blocks still make up a surprisingly small minority of the code.
Porting this package was one of my first experiences working with rust, and it was a big "aha!" moment for me. Debugging the C implementation was a nightmare, because a lot of bugs caused obscure memory corruption problems. They're always a headache to track down. When I first ported the C code to rust, one of my tests segfaulted. At first I was confused - rust doesn't segfault! Then I realised it could only segfault from a bug in an unsafe block. There were only two unsafe functions it could be, and one obvious candidate. I had a read of the code, and spotted the error nearly immediately. The same bug would probably have taken me hours to fix in C because it could have been anywhere. But in rust I found and fixed the problem in a few minutes.
In normal user-mode rust, not running inside the kernel at all, you can open /dev/mem and write whatever you want to any process's memory (assuming you are root). This does not require "unsafe" at all.
Another thing you can do from rust without "unsafe": output some buggy source code that invokes UB in a language like C to a file, then shell out to the compiler to compile that file and run it.
Sure, but those are non-central to what the program is doing. Writing to the wrong register offset and hosing main memory is a thing that happens when developing drivers (though usually it breaks obviously during testing).
Right, you're not wrong that this is a possible failure mode which Rust's guarantees don't prevent.
I'm just pointing out that "your program manipulates the external system in such a way that UB is caused" is outside the scope of Rust's guarantees, and kernel development doesn't fundamentally change that (even though it might make it easier to trigger). Rust's guarantees are only about what the Rust code does; anything else would be hard or impossible to guarantee and Rust doesn't try to do so.
sure, I was thinking of large OO cores. "Correspondd to the instructions the cpu runs and their observable order" is how I'd characterize C as well, but to each their own.
When you parse an AST with comments (or a CST), they do become "just another node in a uniform tree". Think about it - in HTML you have a tree of nodes but comments can be anywhere, which is exactly as obnoxious to deal with as a CST where comment nodes can be anywhere.
This is a terrible reason to not support comments. If it was really important, then probably you should support comments in only a couple of places, e.g. on attributes or on selectors.
But I don't think it is very important. I can't think of a single tool that loads CSS, rearranges it, and then spits it back out in a form that would benefit from comments.
reply