I’m not convinced he really believes that OpenAI is going to roll out AGI in the next ten years, but I’m completely sure he’s determined that it’s a good marketing strategy to make people believe that he believes it.

These graphs only cover the demographic of 18-29 year olds, which historically do lean heavily towards progressive.

Speaking as an annoying Rust user, you’re being bigoted. I’m annoying, but the vast majority of Rust users are normal people who you wouldn’t even know are using Rust.

Don’t lump all the others in with me, they don’t deserve that.

There have been articles out there for multiple days now which spell out your same conclusion, but these CNN clowns keep pushing the same false narrative. It’s blatantly intentional misdirection at this point.

The official act could be to use the national guard to rescue a US citizen from wrongful imprisonment, but that’s the kind of thing that racist Republicans would start a civil war over in the name of “states’ rights”.

Best practice when using .unwrap() in production code is to put a line of documentation immediately above the use of .unwrap() that describes the safety invariants which allow the unwrap to be safe.

Since code churn could eventually cause those safety invariants to be violated, I think it’s not a bad thing for a blunt audit of .unwrap() to bring your attention to those cases and prompt to reevaluate if the invariants are still satisfied.

But only if pattern matching were included, otherwise they would be as unpleasant as C++'s std::variant.

This makes a lot of sense, but the functions were Rust bindings for plain C functions, they weren’t function pointers. Granted I could have put pointers to the function bindings into fields in a struct and stored that struct in the mutex, but the ability to anyhow call the bindings would still exist.

It’s a massive win, and I would question the credibility of any systems programmer that doesn’t recognize that as soon as they understand the wrapper arrangement. I would have to assume that such people are going around making egregious errors in how they’re using mutexes in their C-like code, and are the reason Rust is such an important language to roll out everywhere.

The only time I’ve ever needed a Mutex<()> so far with Rust is when I had to interop with a C library which itself was not thread safe (unprotected use of global variables), so I needed to lock the placeholder mutex each time I called one of the C functions.

Originally, a qipao was supposed to be a loose-fitting gown

Source for this? From living in Asia (not in China, but in a predominantly Chinese community), I’ve only seen qipao be form fitting, never loose. Even seeing older pictures of women in qipao, they’re always form fitting. And more often than not, women seem to use them to intentionally highlight their figure.

Chinese communities tend to have a strong conservative bend, but that doesn’t mean they’re puritanical when it comes to sexuality, especially the sexually suggestive.

I think the point is that Republicans detest the idea of being weird no matter what, so they would rage at the suggestion of being a good weird anyway. To them “good weird” is an oxymoron, even though they are actually very weird and not in any kind of good way.

Rust makes sense though.

Yeah the only way it would be that high is if it lumps C and C++ together. But at that point it may be an underestimate.

A better language wouldn’t have any need to use POSIX signals in this way.

I do think that specific point is catering too much to sloppy get-it-done-fast-and-don’t-think developers. It’s true that they are Rust’s most untapped demographic, and the language won’t reach the pinnacle of mainstream usage without getting buy-in from that group, but I really think they’ll be won over eventually by everything else the language and ecosystem offers, and .unwrap() won’t be such an unreasonable price for them to pay in the long run.

The ideas in the article are great, I’m just a little confused by some aspects of the author’s tone where it sounds like there’s an assumption that the Rust community isn’t interested in expanding the scope of the language to every conceivable use case domain and height.

For the 4 years that I’ve been paying attention the Rust language is advancing faster than I ever thought a language is able to, but more importantly that advancement has been sound and sensible. So far I haven’t seen a language feature make it into Rust stable and thought “Oh no that was a mistake”, even as features roll in at an incredible rate.

Compare that to the C++ ecosystem where I feel like almost every new language feature is arriving very slowly while also being poorly executed (not that I think the ISO committee is doing their job badly; I just think it’s effectively impossible to make new language features in C++ without gross problems so long as you demand backwards compatibility).

I fully expect everything in this very sensible list to make it into the language at a reasonable pace. I don’t object to the “bikeshedding” as much as the author here seems to because I’d appreciate if Rust can avoid painting itself into a corner with bad language design choices the way C++ has. If we’re talking about language ergonomics, I’d rather suffer some tedium now while waiting for a feature to be polished than be stuck in a corner forever in the future because a bad decision was made.

One example I can think of is I’m not convinced that his proposal around kwargs for function arguments is a good thing, at least not without some serious thinking. For example should it support the ability to reduce foo(a, b, x: x) to just foo(a, b, x) like what’s done for struct construction? If so then the optional arguments start to look too much like positional arguments and the syntax starts to get questionable to me. On the other hand if that simplification isn’t supported then that becomes inconsistent with other parts of the language. So this is something that I believe requires a lot of serious thought, and maybe the better answer is to have built-in macros for generating builder structs

That being said, the edition system of Rust could afford us some leeway on not being forever trapped with a bad language design choice, but I don’t think we want to rely too much on that.

Considering most JIT compilers for JavaScript are written in C++, I can’t conceive of a reason you couldn’t implement one in Rust.

Is part of your requirement that unsafe doesn’t get used anywhere in the dependency tree? If so you’d have to take away most of the Rust std library since many implementations in there have small strategic uses of unsafe under the hood.

In my entire software engineering career, which spans embedded systems to CAD applications, I’ve never encountered a case where GOTO is actually needed (but maybe some places where it can be used as a dirty shortcut to save you some lines of code).

As for arbitrary function pointers, if those function pointers are written in Rust then they’ll come with all the safety assurances afforded to Rust code. I suppose if you’re worried about the danger of running ussr-code with unsafe in it, you could probably have your JIT refuse to compile the unsafe keyword specifically.

I really don’t think that there is any perfect programming language.

You’d be wrong 🦀🦀🦀🦀🦀

I think a long time ago a vicious cycle began in the advertising space where predatory ads had more incentive to pay for ad space, so sensible people start to perceive ads in general as predatory. Now no sensible advertiser that’s trying to promote a legitimate product for legitimate reasons will do so by buying ad space, thus reinforcing the increasingly accurate perception that all ads are predatory.

Disclaimer that I have no experience with writing compilers myself, but conceptually I don’t see any obvious reason that someone couldn’t create a JIT compiler for Rust so that it can be treated like a scripting language and do rapid iteration…