> On one hand a really simple solution would be to make unsafe a first class citizen when it makes sense

I have pushed this several times in the past, but there's always been a lot of resistance to the idea. Though I've always phrased it as "let's allow the safety checks to be turned off", which isn't necessarily the best phrasing...

I wonder if it'd be better to just push to make unsafe easier to use: add sugar for ptr::offset, add a -> operator, relax the restrictions on casts, and so on. When I do OpenGL programming in Rust I drop into unsafe quite regularly, and it feels just like C, except for some annoying papercuts. It'd be nice to get rid of those papercuts.

Or better extend the language to allow making code partially safe in many ways. This would make the wrappers much better.

Make it easy to reason about useful kinds of partial safety. Make it easier to define properties of external systems that Rust does not control.

Can you elaborate this into a concrete proposal?

There might be an easy solution, they could provide more flexibility on using safety features, kind of like Perl did it, i.e. let anyone disable/enable a particular strict feature for a particular scope, for example "no borrowcheck;" or something. This will make it easier and more flexible for everyone, newcomers will be able to gradually learn more about the language and still get things done in the meantime, and power users will understand where satisfying the compiler is not worth it and will be more productive as a result without worrying about overly broad unsafe.

They have that with the "unsafe" blocks but like I said promoting it as something you should use when things don't fit borrow-checker goes against their primary goal of making things safe. I guess there are two camps, one that wants compile time safety guarantees - those people made Rust, and the other wants a C++ replacement with modern tooling and no legacy garbage - those are looking at Rust and getting discouraged by safety trade offs they are paying but not really caring for - and every Rust tutorial I've seen focuses on hammering this aspect instead of going "OK here is the equivalent of this C++ code with unsafe code - you now get a sane build system, package manager, modules, fancy syntax. Now if you want here's how to make it safe."

You're almost certainly not looking for Rust if you don't want your language to prevent a vast variety of bugs, and instead want something that allows and encourages you to design systems which make it easy to shoot yourself in the foot (which all C++ codebases I've ever seen have grown). I don't think language developers are interested in making such a language in general, as it's not interesting - you'd just be rehashing ideas from multiple decades ago with new syntax, and not making anything particularly easier to do.

>and not making anything particularly easier to do

Have you used C++ in the real world ? Dealt with it's insane build systems, build times, obscure semantics, etc. ? Not to mention there's nothing close to a sane package manager.

There's plenty of value of just rehashing the lessons learned in last 20 years of language design to a systems language.

    I don't think language developers are interested in making
    such a language in general...

https://inductive.no/jai/

:P

I'd argue go came from a desire to have a language that was completely uninteresting in terms of 'interesting ideas', and really just exists to Get Stuff Done.

I think more people are interested in that sort of thing than you imagine. Clearly.

Jai is designed on a bunch of false assumptions, which makes it hard to get excited about.

Or more precisely, the designer of Jai uses C++ as "C with classes" and then goes from that, which isn't fair. He also misrepresented a few things in regards to Rust, which he doesn't even know, but comments on etc. etc.

As I understand it, you can't disable just borrow checker somewhere where you don't need it.

It's subtle. Unsafe Rust is a superset of safe Rust; that is, all valid safe Rust code is valid unsafe Rust code.

  fn foo() {
      unsafe {
          let x = &5; // this is still going to get borrow checked
      }
  }

Since it's a superset, it gives you access to new tools, that don't interact with the borrow checker, rather than "turning the borrow checker off".

  fn foo() {
      unsafe {
          let x = *const 5; // this is not going to get borrow checked
      }
  }

(*const is not valid syntax: the way to not-borrow something is to coerce/cast it to an unsafe pointer within the statement, so that the borrow ends at the ;, e.g. give x an explicit raw pointer type in the first example.)

gah, i always mess this up, haha