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

clear business model: pay for support/advice, the software is completely free.

That business model is what Redis Labs is trying to address. There’s a serious problem for companies with that model if a large hosting provider like AWS that more and more people are moving to can come in and offer a “as a service” version that cuts off the support revenue stream. At that point, AWS can benefit from the work that said company is doing without contributing anything back.

Open source software in general and open source business models often assume that you won’t have parasitic players in the market who derive value from the work of others but contribute nothing in return. The current system is going to have to change eventually to account for that.

It might end up being that all open source software is produced by companies that aren’t “product” companies. For example, Google spinning out K8S and not attempting to make money off the software. LinkedIn getting an advantage out of opening up Kafka etc. In that world, eventually, there will be very few companies like RedisLabs, CockroachDB, InfluxDB etc that are trying to be product companies. The large move “to the cloud” that is underway is a huge disruption to that previously OSS business model. I think a model that many will try will be to take an open source product and provide close sourced, additional functionality around those codebases (thereby sidestepping licenses like the AGPL) and doing managed hosting and as a service hosting within the big clouds like AWS, GCP, and Azure.

Note that Rust wraps on overflow and as far as I can tell this does not impact performance of Rust programs.

To remove all undefined behaviour in C would severely impact the performance of C programs.

This cannot be entirely true. As a reducto ad absurdum, it would be possible in principle to laboriously define all the things that compilers currently do with undefined behaviour and make that the new definition of the behaviour, and there would then be zero performance impact.

C compiler writers might argue that removing all undefined behaviour without compromising performance would be prohibitively expensive, but I’m not entirely convinced; there are carefully-optimized microbenchmarks on which the naive way of defining currently-undefined behaviour produces a noticeable performance degradation, but I don’t think it’s been shown that that generalises to realistic programs or to a compiler that was willing to put a bit more effort in.

I don’t get the point. The advantage of using integer wrap for C on processors that implement integer wrap is that it is high performance, simplifies compilation, has clear semantics, and is the semantics programmers expect. If you want to argue that it should be e.g. trap on overflow, you need to provide a reason more substantive than theoretical compiler optimizations that are shown by hand waving. The argument that it should be “generate code that overflows but pretend you don’t” you needs a stronger justification because the resulting semantics are muddy as hell. I’m actually in favor of a debug mode overflow trap for C but a optimized mode of use processor semantics.

There’s nothing obvious about it, and re-examining unfounded claims is not bizarre. We know that, historically, plenty of claims made were just plain wrong (consider the anabolic-catabolic “theory”).

Boys and girls had very different /roles/ since the dawn of time for obvious reasons. If you tried, as a girl, to play with the “wrong” toys you could see quite a bit of resistance.

I’m not saying this is wrong (I haven’t done any research so I don’t know) but it seems very likely that kids are pushed to play with specific toys by society. We label toys as boys or girls, we market toys as being played with by either boys or girls and we give kids toys that we associate with their gender.

I saw a video this year where young babies were placed in a room full of a range of toys. Each time the baby was dressed in either pink or blue and given a female or male name regardless of their actual gender and a babysitter was in the room as well to help them play with the toys. Each time the babysitter would tend to help the baby play with toys stereotypical for their perceived gender. After the babysitter was asked which toys they thought the baby liked and they would say the baby seemed to prefer the toys of the perceived gender regardless of what the babys actual gender was.

Now that’s not really a scientific study but it does seem to suggest that things are not as “obvious” as they seem. It’s a little hard to test because really you would have to raise a kid in an alternative society to see what differences it makes.

I haven’t heard that particular complaint, but one I hear often is that it’s quite absurd to have a genre lineup that resembles something like “action,” “comedy,” “drama,” and “not for men,” as if “not for men” were its own genre (it’s obviously not literally called that, but you provided your own example above). Deciding to use a “not for men” genre immediately creates its counterpart, “for men,” which is every other genre.

You logically have two choices here:

1. Accept the dichotomy and make explicit the implicit labels: “action for men,” “comedy for men,” “drama for men,” and “not for men.” You’ll have to train your brain to see this everywhere, as the implicit labels are extremely implicit. Along with appeal to the targeted demographic comes license to exclude the other – after all, if your genre is “not for men” then you don’t care if your movie makes men uncomfortable (this is different than making it desirable for not-men). If your genre is “action for men,” you don’t care if your movie makes women feel uncomfortable. It’s not for them.
2. Reject the dichotomy, and distribute the “not for men” qualities into the core genres – “action for men” just becomes “action”. Along with this comes the lack of license to exclude. This has made some movie watchers/videogame players mad – even though there is still plenty of content around (and more being made every day), the consumers of the previously “for men” genres see this as dilution and loss. Some of the things they liked excluded people, and instead of trying to untangle the good from the bad (or learn to coexist with new expressions of things they liked before) they’ve decided to double down and defend everything.

Whichever decision you make will impact how you see the modern media landscape.

I would expect an article on the experience reports of production users to have quite a bit of nuance, but your article is mostly written in a binary style without much room for nuance at all. This does not reflect my understanding of reality at all—not just with Rust but with anything. So it’s kind of hard for me to trust that your characterizations are actually useful.

I realize we’re probably at an impasse here and there’s nothing to be done. Personally, I think the style of article you were trying to write is incredibly hard to do so successfully. But there are some pretty glaring errors here, of which lack of nuance and actual evidence are the biggest ones. There’s a lot of certainty expressed in this article on your behalf, which makes me extremely skeptical by nature.

(FWIW, I like Rust. I ship Rust code in production, at both my job and in open source. And I am not a huge fan of puzzles, much to the frustration of my wife, who loves them.)

I just wanted to say I thought your article was excellent and well reasoned. A lot of people here seem to find your points controversial but as someone who programs C++ for food, Go for fun and Rust out of interest I thought your assessment was fair.

Lobsters (and Hacker News) seem to be very favourable to Rust at the moment and that’s fine. Rust has a lot to offer. However my experience has been similar to yours: the Rust community can sometimes be tiresome and Rust itself can involve a lot of “wrestling with the compiler” as Jonathan Turner himself said. Rust also provides some amazing memory safety features which I think are a great contribution so there are pluses and minuses.

Language design is all about trade-offs and I think it’s up to us all to decide what we value in a language. The “one language fits all” evangelists seem to be ignoring that every language has strong points and weak points. There’s no one true language and there never can be since each of the hundreds of language design decisions involved in designing a language sacrifices one benefit in favour of another. It’s all about the trade-offs, and that’s why each language has its place in the world.

I really don’t see a reason to start a new project in C++.

Here’s one: there’s simply not enough lines of Rust code running in production to convince me to write a big project in it right now. v1.0 was released 3 or 4 years ago; C++ in 1983 or something. I believe you when you tell me Rust solves most memory-safety issues, but there’s a lot more to a language than that. Rust has a lot to prove (and I truly hope that it will, one day).

I have Factor running in production. Although I don’t really maintain the web app much - it just ticks along - Factor runs tinyvid.tv and has for the past few years. I originally wrote it to test HTML 5 video implementations in browsers back when I worked on the Firefox implementation of video.

As always, it depends on what you’re doing—I’d definitely be nervous if you told me you were shoving Factor into an automobile, for example—but Factor the VM and Factor the language are both quite stable and reliable. On top of doublec’s comment, the main Factor website runs Factor (and its code is distributed as part of Factor itself for your perusal), and it’s been quite stable. (We do occasionally have to log in and kick either Factor or nginx, but it’s more common that the box needs to be rebooted for kernel updates.) I likewise ran most of my own stuff on Factor for a very long time, including some…maybe not mission-critical, but mission-important internal tooling at Fog Creek. And finally, we know others in the community who are building real-world things with Factor, including a backup/mirroring tool which I believe is being written for commercial sale.

The two main pain-points I tend to hit when using Factor in prod are that I need a vocabulary no one has written, or that I need to take an existing vocabulary in a new direction and have to fix/extend it myself. Examples are our previous lack of libsodium bindings (since added by another contributor) and our ORM lacking foreign key support (not a huge deal, just annoying). Both of these classes of issues are increasingly rare, but if you live in a world where everything’s just a dependency away, you’ll need to be ready for a bit of a change.

You can take a look at our current vocab list if you’re curious whether either of the above issues would impact anything in particular you have in mind.

My non-breezy answer is “anything you enjoy using it for.” There are vocabularies for all kinds of things, ranging from 3D sound to web servers to building GUIs to command-line scripts to encryption libraries to dozens of other things. Most of those were written because people were trying to do something that needed a library, so they wrote one. I think the breadth of subjects covered speaks well to the flexibility of the language.

That all said, there are two main areas where I think Factor really excels. The first is when I’m not really sure how to approach something. Factor’s interactive development environment is right up there with Smalltalk and the better Common Lisps, so it’s absolutely wonderful for exploring systems, poking around, and iterating on various approaches until you find one that actually seems to fit the problem domain. In that capacity, I frequently use it for reverse-engineering/working with binary data streams, exploring web APIs, playing with new data structures/exploring what high-level design seems likely to yield good real-world performance, and so on.

The second area I think Factor excels is DSLs. Factor’s syntax is almost ridiculously flexible, to the point that we’ve chatted on and off about making the syntax extension points a bit more uniform. (I believe this branch is the current experimental dive in that direction.) But that flexibility means that you can trivially extend the language to handle whatever you need to. Two silly/extreme examples of that would be Smalltalk and our deprecated alternative Lisp syntax (both done as libraries!), but two real examples would be regular expressions, which are done as just a normal library, despite having full syntax support, or strongly typed Factor, which again is done at the library level, not the language level. I have some code lying around somewhere where I needed to draft up an elaborate state machine, and I quickly realized the best path forward was to write a little DSL so I could just describe the state machine directly. So that’s exactly what I did. Lisps can do that, but few other languages can.

The threads are still green threads, if that’s what you’re asking, but we’ve got a really solid IPC story (around mailboxes, pattern matching, Erlang-style message passing, etc.), so it’s not a big deal to fire up a VM per meaningful parallel task and kick objects back and forth when you genuinely need to.

In terms of future directions, I don’t know we’ve got anything concrete. What I’d like to do is to make sure the VM is reentrant, allow launching multiple VMs in the same address space, and then make the IPC style more efficient. That’d make it a lot easier to keep multithreaded code safe while allowing real use of multiple cores. But that’s just an idea right now; we’ve not done anything concrete that direction, as far as I know.

Really off-topic, but isn’t Slava at Apple?

a few years ago

a bit of an understatement! The competing library was dropped in 2007.

I agree!

As for knocking D for emulating C++, I did not mean to suggest that doing so is a count against D as a language, but rather just as a count against replacing C. I already ruled out C++, if a given language is pretty close to C++, it’s probably also going to be ruled out.

It’s been a long time since I looked at nim, but generating C code leaves a really poor taste in my mouth, especially because of some decisions made in the language design early on (again, I haven’t looked in a while, perhaps some of those are better now).

As for Jai, yes it’s definitely targeted at game development; however, the more I look at it, the more it looks like it might be reasonable for a lot of other programming tasks. Again though, at the moment, it’s just vaporware, so I offer no guarantee on that point. :)

Can you please point out where Rust “claims C level portability”?

I agree that Rust needs a better multi-architecture story - as someone who does embedded development, I’ll play with Rust but I’d be very wary of using it “for real” - but lack of serious support for non-x86 [EDIT: non-Windows/-Linux/-Mac] is pretty well-documented.

[EDITed in response to sanxiyn’s clarification, thanks!]

How is that a benefit? I would agree if compilation to WebAssembly avoids GC, but Grain seems to require GC anyway.

That’s a good point…they’ve both tried to accommodate some real-world problems, while dismissing others. The vgo approach does seem more Go-y (Goful? Goesque?). The parallel with the Go regex library makes sense (can’t handle some languages that Perl regexes can, but never goes exponential, either).