I do have to admit that I haven’t checked what authors say about it, I’ve only seen Go users defending lack of library and version management. I’m glad to see that they weren’t opposed to it.

I mostly stopped watching after they went to implement polymorphic data structures by silently downcasting to interface{} after saying no one needs polymorphism.

This one is somewhat notable for being the first (?) RCE in Rust, a very safety-focused language. However, the CVE entry itself is almost useless, and the previously-linked blog post (mentioned by @Freaky) is a much better article to link and discuss.

That’d be a good meta tag proposal thread.

There are a lot of potentially-RCE bugs (type confusion, use after free, buffer overflow write), if there was a lobsters thread for each of them, there’d be no room for anything else.

Here’s a list a short from the past year or two, from one source: https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=Type%3DBug-Security+label%3AStability-Memory-AddressSanitizer&sort=-modified&colspec=ID+Type+Component+Status+Library+Reported+Owner+Summary+Modified&cells=ids

The fact that I can’t tell if this is a joke or a typo makes it a better joke.

I thought that BeOS was microkernel based on what so many said. waddlespash of Haiku countered me saying it wasn’t. That discussion is here.

Haiku has a hybrid kernel, like Mac OS X or Windows NT.

They’re what’s called hybrid kernels. They have too much running in kernel space to really qualify as microkernel. Using Mach was probably a mistake. It’s the microkernel whose inefficient design created the misconceptions we’ve been countering for a long time. Plus, if you have that much in the kernel, might as well just use a well-organized, monolothic design.

That’s what I thought a long time. CompSci work on both hardware and software has created many new methods that might have implications for hybrid designs. Micro vs something in between vs monolithic is worth rethinking hard these days.

Yes, but with most of a BSD kernel stuck on and running in the same address space. https://en.wikipedia.org/wiki/XNU

Everyone should be allowed to talk about Rust. There is no authority that deserves to have the power to decide which people can or cannot talk about Rust.

That said, it’s also fine to say that the author’s opinion about Rust is untrustworthy because it bears the hallmarks of someone who has read about Rust but not actually used it themselves in any meaningful way. I myself agree that it’s possible to write lots of useful rust code without running into situations where the borrow checker trips you up, and that some of Rust’s best innovations are the “small” things like the algebraic types, macros, Cargo, etc. that are now available in a non-GC systems language.

That’s exactly what I’d have suggested minus self-hosting part. Just try porting what already works.

Personally, I found the post interesting.

It’d be interesting to know whether LLVM was also compiled with AFL’s instrumentation. Obviously any findings from GCC’s optimizers would be “expected” to be found in LLVM, not rustc.

Maybe instead compare this compiler with just the parts of rustc it was based on. That version, too. From there, there’s a difference between team size, amount of time to do reviews, and possibly talent. Those could create a big difference in bugs. However, the bugs that should always be prevented by its static types should still count given the language should prevent them.

So, I’d like to see rustc vs mrustc in a fuzzing comparison.

they seem to be under some weird impression that they’ll be able to trap devs in their platform with their own, proprietary API

Is it not working quite well for Microsoft with DirectX?

Your involvement with rust will bias your opinion - rust team hat would be appropriate here :)

He is not claiming that memory safety in general is not an issue in C. What he is saying is that in his own projects he was able to limit or completely eliminate dynamic memory allocation:

In the 32 kloc of C code I’ve written since last August, there are only 13 calls to malloc overall, all in the sokol_gfx.h header, and 10 of those calls happen in the sokol-gfx initialization function

The entire 8-bit emulator code (chip headers, tests and examples, about 12 kloc) doesn’t have a single call to malloc or free.

That actually sounds like someone who understands that memory safety is very hard and important.

Not at all the vibe I got from it.

I agree with your point on attention. I just wanted to say maybe we should get a bit more credit here:

“compared to some of the smaller projects that don’t hit HN/Lobsters headlines regularly.”

Maybe HN but Lobsters covers plenty oddball languages. Sometimes with good discussions, too. We had authors of them in it for a few. I’ve stayed digging them up to keep fresh ideas on the site.

So, we’re doing better here than most forums on that. :)

I expected graphics to be the reason OP thought QBasic was the way to go, but then it was never mentioned so it seemed like a much less compelling argument.

you end up having to deal with gem and rvm and pip and virtualenv and on and on and on and fucking on. In QBasic you type CIRCLE and hit F5.

Racket can do just that.

You have to try teaching programming for yourself to see the tiny things that trip noobs up.

Racket is also made specifically for teaching.

And then VB6 made GUI’s about as easy. And like you said about QBasic, I’d click VB6, IDE loaded in a second, start project, type some code for the console thing if I wanted, press run, wait one second, results. Rinse repeat. The concept that mattered aside from speed is flow: the BASIC’s have a development flow that maximizes mental flow to keep people constantly moving. Pascal’s can do it, too, since they compile fast. Smalltalks and LISP on extreme end of it.

The other advantage of BASIC’s are that they look like pseudocode people write down before actually coding. BASIC is so close to pseudocode that they can do the pseudocode in BASIC itself or barely do a translation step. In the Slashdot and other comments, I see the “it looks just like pseudocode!” response show up constantly among people that started with BASIC. Something that shouldn’t be ignored in language design at least for beginners. Probably also DSL or HLL designers, too, trying to keep things closer to the problem statement.

Sort of, but also with the ability to read off native types in order and respect endianness and do seeking safely.

In general, you can do that sort of thing in Design-by-Contract with a certified and non-certified compiler. In debug mode, the contracts can all become runtime checks showing you exactly which module fed bad input into the system. That lets you probe around to localize exactly which bad box took input that accepted its preconditions, did something with it, and produced output that broke the system. When looking at that module, it will normally be a software bug. However, you can run all failing tests through both a certified and regular binary to see if the failure disappears in one. If it does, it’s probably a compiler error. Similar check running sequential vs concurrent in case it’s a concurrency bug. Similarly, if the logic makes sense, it’s not concurrency, and passes on certified compiler, it’s probably an error involving something else reaching into your memory or CPU to corrupt it. That’s going to be either a hardware fault or a privileged component in software. With some R&D, I think we could develop for those components techniques for doing something similar to DbC in software for quickly isolating hardware faults.

That said, I don’t think it was applicable in this specific case. They’d have not seen that problem coming unless they were highly-experienced, embedded engineers. I’ve read articles from them where they look into things like effects of temperature, bootloader starting before PLL’s sync up, etc. Although I can’t find link, this isn’t the first time sunlight has killed off a box or piece of software. I’ve definitely seen this before. I think a friend might have experienced it with a laptop, too. We might add to best practices for hardware/software development to make sure the box isn’t in sunlight or another situation that can throw its operating temperature. I mean, PC builders have always watched that a bit but maybe the developers on new hardware should ensure it’s true by default. The hardware builders should also test the effects of direct sunlight or other heat to make sure the boxes don’t crash. Some do already.