Not sure if this is what OP is seeking, but I would be fine to have borrow checker removed, replaced with Garbage collector like Go/Python in such a language.

To build prototypes, I don’t want to fight with borrow checker and neither I care for efficiency much. But I do want the macro system, traits, lazily asynchronous runtime, cargo like package manager, easy build system, etc.

Rust has so many powerful features, but only because of borrow checker (IMO) we can’t use it for rapid prototyping like Python. With that replaced, this subset of Rust would be something which can be a great contender to Python/Go, etc.

I spend an inordinate amount of time at my C# day job adding documentation comments about exclusive access and lifetimes and ownership… things which are clearly important but which dotnet provides little or no useful support for, even though it has a perfectly good garbage collector. The dotnet devs were well aware that garbage collection has its limits, especially when interacting with resources managed outside of the runtime, and so they added language features like IDisposable and finalisers and GCHandle and SafeHandle and so on to fix some of the things GC won’t be doing for you.

I’d happily use a garbage collected language with borrow checking.

Did you read the original “Notes” post? I thought it did a pretty good job of explaining why Rust-like ownership semantics are not necessarily at odds with having a garbage collector.

Definitely a good pick! I haven’t learned it but I’m aware of some of its features, and it does seem promising.

Jeeze, I knew that simplicity was the goal (and I think they largely succeeded in that), but that quote is so explicitly condescending. “They’re not capable of understanding a brilliant language”?

I disagree slightly with the need to add full ADT support to the language to implement that style of error handling, because Pike et al. had no problem adding “special cases” to the language: in particular, return values are essentially tuples, but that’s the only place in the language with that concept. So they wouldn’t need to introduce user-definable enums and full pattern-matching to have better error handling. I can think of a couple approaches they could have used:

• Use compound-return-values as they currently exist, but have additional compiler-enforced restrictions:
  • There can be at most one error value in the return types, and it must be the last element in the "tuple"
  • when returning a non-nil error, the other values must be zero/nil
  • the compiler would require all errors to be checked, never ignored (Go should have at least done this, even without the other stuff)
  • Add the question-mark operator, which would do basically the same thing as in Rust: check if the error value is nil, discard it if so, return early if not
• Have a special “result” type that is quasi-generic (like slices and maps) and treated as a sum-type by the compiler, but which can only be used as a return value from functions. Provide some special variant of the switch statement to destructure it (akin to how type switches have their own bespoke syntax/keyword).

I believe you, but for it to be a fair comparison you’d need to compare to an alternative rewrite, not to the original software.

Rust has plenty of merits. It has a very readable functional style, single aliasing to reduce complexity, powerful libraries for stuff like generating serialisation code, and cargo is incredible.

However, expressing any complex graph structure in Rust is just painful, and so is refactoring code. Small changes in intent require complex reworking of data structures, because Rust forces you to be extremely specific about data layouts at all times. These issues crop up constantly in any complex project, and they really slow things down.

Although Rust is a nice language, you can now write functional code with immutable data structures in pretty much any modern, statically-typed language. C#, Kotlin, Scala, Swift, etc. It will be concise, quick to write, easy to modify and pretty fast at runtime.

Perhaps I’m mistaken in some way, but this has been my honest experience after many years using Rust.

… I am currently asking if there is a language that fits the description. And I’m clearly not the only one interested in such a language.

I personally have not found Rust onerous to learn, especially by comparison to C++. But a lot of people do find the learning curve steep.

I know Rust has these features, but they are intended to be features of last resort and it shows. It’s not a criticism; Rust pushes people relentlessly towards safety and performance, and is extremely successful at that.

I am imagining a language more like Pony, but with less of a focus on the actor model. I could use a language like that to write a high performance game engine with no GC pausing issues, and then write very high level gameplay scripts on top of it in the same language.

You could do that in Rust, but the Rust game engine space has already made it clear that most people feel the need for a scripting language.

Box<dyn Trait>

Now try to do that with a trait that isn’t object-safe…

I get your point, these things make fighting with the borrow-checker a little bit less annoying, but Rust is complex. I’ll happily accept that because I value high code-quality (to that point that I rather invest more time to get things right) but when that is not the goal and you want something higher-level and strongly-typed there are alternatives that work better (I’m just talking about the language itself, ecosystem alone for me is yet another pro-Rust thing)

“Faster/easier/less mental overhead” is indeed exactly what I mean by “convenient”.

Maintainability is very different from “convenience”, and I think we’re both in agreement that Rust makes the correct tradeoff by favoring maintainability over convenience. But that doesn’t mean that maintainability implies convenience!

I strongly prefer to write Rust versus “convenient” languages such as Python, Ruby, and (my least favorite, but the one I use most often professionally) Go. But that doesn’t stop me from appreciating the benefits of “convenience”; and I think that there is room in the language design space for a slightly different tradeoff: something that isn’t usable everywhere Rust is (e.g. it presumably wouldn’t ever be a candidate for inclusion in the Linux kernel) but still has many of the same maintainability advantages.

I’m curious if you were told that recently. I know that there have been stable releases of major features and libraries concerning concurrency and parallelism near the end of 2022. It may be much improved since you your source last looked. Or it could be a limitation in the implementations of these.

Fair points.

Go is a “small” language in the sense that it has an exceptionally small number of concepts (i.e. features and syntactic constructs); someone else in this thread made a comment to the effect that it takes almost no time to learn because there’s nothing to learn if you’ve already learned a different language. This is of course an exaggeration, but only slightly: Go was very intentionally and explicitly designed to be as simple as possible to learn and to use. As an example, it famously had no support for generics until almost 10 years after its 1.0 release. I think that when talking about the size of a language, some people do include the standard library while others don’t; Go has quite a large standard library, but you don’t actually have to learn the whole library or even be aware of what’s available in order to be productive.

I personally don’t think it makes sense to include the standard library in the “size” of a language for the purpose of this thread, or Boats’ original blog posts. The fundamental point is about the learning curve of the language and the amount of work it takes to produce working code, and a large standard library tends to be more convenient, not less. Common functionality that isn’t in Rust’s standard library tends to come from libraries that become almost ubiquitous, such as serde, regex, crossbeam, and itertools. From the user’s perspective, this isn’t much more or less complicated than having the same functionality available via the standard library. (Of course, a large standard library certainly makes languages more difficult to implement and/or specify; if I recall correctly, about half the size of the C++ standard is dedicated to the standard library.)

I don’t really know how to fairly compare the “size” of Rust and C++, partly because Rust is so much younger, and several C++ “features” overlap with each other or are attempts to replace others (e.g. brace-initialization as a replacement for parentheses). But I don’t think I’ve ever heard someone claim that C++ is “small” or “minimal” in this sense, so it’s in no way a good point of comparison for determining whether Rust is “small”.

Edit to add: for what it’s worth, if I weren’t quoting Boats’ blog post (which is sort of the “canonical” post on this concept), I probably would have opted for “simpler (to learn & use)” rather than “smaller.”