There is absolutely no evidence to support this assertion.

Instead there is plenty of evidence that currently there is a lot innovation in all niches of the programming ecosystem - from low level [Rust] to high level, and a lot of coder interest in all the options.

Also talking about "lowest common denominator" comes across as somewhat snobby - many world-class coders use high-level languages when appropriate. It's a matter of choosing the right tool for the job, not dumbing down.

> There is absolutely no evidence to support this assertion.

Consider the popularity of Javascript and Electron for Desktop applications.

I think that's more a function of "We want to access all demographics without paying to properly comply with the interface design guidelines of each platform individually. What 'write once, run everywhere including the browser' solution have you got for us?"

That wouldn't explain why even companies like Microsoft use webtech in their OS configuration GUI these days.

Good point. It's probably fundamentally a cost-cutting measure in both cases, where Microsoft just found it cheaper and easier for similar reasons.

(eg. Win32 isn't a convenient API, Qt has license fees while Electron does not, Microsoft has a history of making successor APIs that even they don't have proper confidence in, etc.)

And yet much of Google was built with Python for a very significant chunk of its life. Netflix and Uber were/are heavily leveraging JavaScript for core workloads. The machine learning ecosystem is largely dominated by Python. Stripe, GitHub, and Shopify are still investing heavily in Ruby. Almost none of this is/was for the sake of accessibility to beginners.

Your example cherry picks exactly one instance, ignoring the context of that choice. Such an assertion requires more than just anecdotal musings and ignores the tradeoffs that those teams made when choosing a platform.

Because it’s a first class development experience, cross-platform by default, V8 is really really fast, and toolkits that support “build your own toolkit” are non-existent outside the web.

I don’t want to make a “Windows app”, “A Mac app”, or a “QT app”. I want a rectangle and a high-level enough interface to build my own widgets. People who are single mode users obviously hate that every app looks and behaves different but most people are multi-mode and don’t care.

JS is only easy at the most superficial level and gets to be a mess once you go beyond small apps.

> Because it’s a first class development experience [...]

I'm going to have to disagree with that.

> People who are single mode users obviously hate that every app looks and behaves different but most people are multi-mode and don’t care.

I am going to have to strongly disagree with that. If that were true nobody would ever have wanted to do theming, which was a big deal before developers forgot how to make software flexible enough to support it.

> JS is only easy at the most superficial level and gets to be a mess once you go beyond small apps.

Oh, you mean like BASIC? A language designed specifically to be easy to learn? Lots of applications were made in BASIC because it was easy to get into and people just kinda dealt with the mess. Visual Basic especially has a reputation. Sound familiar?

> It's a matter of choosing the right tool for the job, not dumbing down.

In some cases, but there is definitely a trend of dumbing down stuff in the name of accessibility or ease of use. As long as the GUI does not limit me and I can still tinker with various stuff under, say, "Advanced", I am okay-ish.

Every time I hear the term "lowest common denominator" applied to programmers, I reflect on the number of network-accessible remote exploits that provide root access via the Linux kernel over the past three decades.

And yet the folks maintaining the network stack in the Linux kernel are not anywhere near what I or almost anyone else would consider the lowest common denominator programmer.

Sometimes you just have to accept that ALL humans are inherently bad at this, only some are worse than others at various points in their lives. The security and reliability of the product of our output should not be so largely dependent upon our ability to get a full night's sleep, reasonable working hours, and lack of personal conflict. To be sure, we should all strive for those things, but perhaps the choice of tools is correct in prioritizing mitigation of difficulties and vulnerabilities from meatspace.

Sometimes that's a borrow checker. Other times it's a garbage collector. And every once in a while, we need to break out an unsafe block (or the entire C language) to get a job done.

Considering how much more expensive people are than software or hardware, the trade off for easier/simpler access is increasingly straightforward.

While I strongly agree this doesn't seem to match the sentiment of the paper.

Which is prioritizing a lower barrier to entry for new programmers at the cost of safety checks that help prevent humans from making mistakes at runtime.

It seems to me if our conclusion is humans, no matter how skilled, are flawed, we should be willing to do absolutely anything to lower the barrier to entry except removing checks on correctness.

What makes you say that? What safety or correctness features do you think a garbage collector in Rust eschews? On the contrary, gc should make the language safer since it obviates the need for the "unsafe" escape hatch.

See https://users.rust-lang.org/t/bronze-gc-and-aliasing-problem.... The GC allows use after free bugs that are compile time exceptions in Rust.

But the gc is there to test the usability cost of Rust's memory management scheme. A properly written gc would of course not allow for use-after-free bugs.

The problem is that this study is relatively worthless, because the API used by this GC inherently introduces UB. If you have a correct API, the usability tradeoff might be very different.

Can you please point to some results in the study that would have been different if the tracing gc hadn't suffered from use-after-free bugs?

To phrase what my sibling commentor said but in a different way:

This paper is an experiment to see if a particular API could make using Rust easier. This specific API is not sound. This means that the paper's results are kind of irrelevant in a strict sense; this API cannot work in Rust, so it being easier is kind of a moot point. Maybe someone can take their API, make it sound, and then try again, and that's certainly good. But it is a serious flaw in the methodology.

Specifically, this API call is unsound:

  GcRefCell<T>::as_mut(&self) -> &mut T

It's not about the internals of the GC. It's about the API that it exposes to users.

The author has some ideas: https://github.com/mcoblenz/Bronze/issues/2#issuecomment-939... These ones are straightforward, and would probably work, but they would also introduce some friction, and removing friction is the entire point of the exercise. Is it too much? Maybe! It also maybe isn't. You'd need another study to figure that out.

> This paper is an experiment to see if a particular API could make using Rust easier.

According to the author: "The Bronze project is exploring the usability costs of the restrictions that Rust imposes."

That does not require a sound gc to explore. Maybe it would have been different had the goal been to see whether a gc can be bolted onto Rust. Yes, that might be difficult given Rust's semantics and how to deals with pointers. But that doesn't seem to be the goal of the author's research.

Again, it's not about the GC being sound, it's about the API that's being used. There's (imho) not a lot of value in figuring out if an API that can't be used is usable.

There are other GC crates that offer sound APIs. Research using those sounds very promising and good!

Then explain to me why it matters. If none of the toy examples in the research actually required multiple mutable references to the same objects, then why would it matter that the compiler allowed it? I think you missed the point of the research: to "explor[e] the usability costs of the restrictions that Rust imposes."

If they didn’t require it, then that would significantly strengthen the paper! They could have not exposed that API and it would be much more useful. I suspect that they probably did need it though. An immutable GC would only be useful by adding an interior mutability wrapper, which is exactly the kind of friction the paper is trying to avoid.

It matters because the rest of the Rust universe follows this pattern. If they coded their own standard library (and any other allowed libraries) and modified the compiler to not miscompile this usage, then that exploration would be valid. But you’re also going to get friction from miscompiles and fighting with other APIs that do have this property. So it would be more useful to either go all-out ok this idea that Rust’s uniqueness properties are a bad thing, or fix the soundness issues. The halfway step simply confounds too many issues to be truly useful, in my opinion.

I agree that exploring the space is a good idea and useful. My issue is with the methodology, not the concept.

The article does include a thorough description of the tasks. Afaict, none of them requires multiple mutable references to the same objects. It would be strange if any task did as it then wouldn't be implementable in plain Rust.

I think you are missing the point of this research. The author has, given his large sample size, persuasively demonstrated that Rust's borrow checker is confusing to newbies. Data from 428 students is a lot and an order of a magnitude more than many other programming language usability studies. This is in my opinion interesting research, even though I understand why Rust fans doesn't like his results!

> Afaict, none of them requires multiple mutable references to the same objects

They ask to store objects ("turtles") into a single Vec. Two turtles from that Vec can breed to create a child turtle stored in that same vec. Parents must retain a reference (a real ref, not an index or other workaround) to their children, meaning that children have multiple refs. Children can become parents themselves, so all the turtles are mutable.

There you have it: multiple mutable references to the same object. With proper Rust you'll need some kind of RefCell to implement this (convoluted) design. The runtime check will ensure a runtime panic if you try to make the same object mutable via different RefCells (trying to breed a turle with itself). With BronzeGc the compiler will believe that they are different objects, and UB-optimize accordingly.

I don’t think you understand why, given that as myself and several people have stated, the issue isn’t with the results. It’s with the methods. I have no opinion either way about the results, because as far as I can tell, they result from an incoherent premise, which means the conclusion is also incoherent.

> An immutable GC would only be useful by adding an interior mutability wrapper, which is exactly the kind of friction the paper is trying to avoid.

This would be the most idiomatic approach, yes. They could use a code transformation to automate the 'wrapping' and present an intuitive, frictionless interface to the developer.

Totally, and that’s one of the ideas floated in the issue. I think depending on how it could be done it may not even lost out on ergonomics in most cases, but I haven’t worked through it myself.

The problem isn't that the GC suffered from use after free. The problem is that the GC allowed the user to have 2 references to a mutable object which is UB in Rust (and a compile time error without unsafe code). The problem with the API is that without some pretty fundamental changes to the language, the only times a GC doesn't error, and Rust does is when the user tries to do undefined behavior. Removing the UB is also pretty much impossible because if you allow these references, you remove one of the main tools the Rust compiler uses to optimize code.

Having simultaneous mutable references to an object is UB in Rust because the memory manager cannot detect use-after-free errors. What you are talking about is not a feature but a limitation of Rust's borrow checker. But when using a gc multiple multiple references it not a problem at all so there is no reason to prevent it. This has almost nothing to do with performance. Restricting the number of mutable references to one does not mean that the compiler can emit significantly faster code.

> Having simultaneous mutable references to an object is UB in Rust

This is correct.

> because the memory manager cannot detect use-after-free errors.

... this is not. It is UB because the language declares it UB. It is absolutely to the core of the design of the language itself. All Rust code relies on this property to work. Something that breaks it is in fact broken, regardless of any other aspect of the program.

Quoting the article:

> those who [used the GC] required only about a third as much time (4 hours vs. 12 hours).

Surely you can devote a chunk of your newfounded time to find use-after-free bugs.

If that worked, people wouldn't still be finding use after free bugs in commonly used C libraries. The whole reason to use Rust is that it turns most of C's UB into compile time errors so that your code isn't horribly broken in the first place.

I don't know how to find use-after-free bugs in arbitrary code, no matter how much time I devote to the task. I just can't keep enough state in my head at once.

What does "use after free" mean in a garbage collected environment? Isn't the purpose of GC to automatically free after last use.

It means the GC design is fundamentally broken.

> A key tradeoff is that Bronze does not guarantee thread safety

Data races are currently prevented by the borrow checker. Any GC in order to provide equivalent correctness would need to do so as well.

If you read the paper, they needed to throw out the thread safety from Rust's borrow checker in order to make the GC work. That is a massive surface area for bugs they are opening back up to make the language easier for beginners.

I just added a clarification to the README about this. The main issue is that the current implementation keeps track of roots with a shadow stack technique (https://llvm.org/docs/GarbageCollection.html#using-llvm-gcwr...), which is not thread-safe. It wasn't worth the engineering work for this particular study since the tasks didn't require more than one thread. A practical implementation, of course, would need to be thread-safe.

I'm sure the GC implementation itself could be made thread safe. But the paper mentions that Bronze lets you have multiple mutable references to an object. Doesn't this open the door to the user's code having data races, whereas it would be safe by default in vanilla Rust?

Because their gc is a proof-of-concept created specifically for this research. It doesn't even deallocate memory. Most likely, they didn't have their students write any threaded code so thread-safety wasn't a concern. For a production ready tracing gc, of course they would add thread safety, it's not a big problem.

No, this is the fundamental tradeoff they made to make the Bronze'd Rust easy to use:

> Rust permits only one mutable reference to a value at a time... With Bronze, mutation is permitted through all references to each garbage-collected object, with no extra effort. A key tradeoff is that Bronze does not guarantee thread safety; as in other garbage collected languages, it is the programmer’s responsibility to ensure safety.

Allowing mutability anywhere is what fundamentally makes Bronze easier to learn, and more error-prone.

The paper's author has already explained to you how thread safety can be achieved in a production-ready gc. This is not something that is particularly difficult to engineer and is quite orthogonal to whether one chooses to use tracing gc, ref counting or Rust-like borrow checking.

But if equipping Rust with a GC makes it as easy as Python, Rust could become the language of choice because you have the low entry barrier and the option of making your code much more robust within the same language. That seems like a big win for everyone.

I think there can be an unproductive temptation to use a language as gatekeeper of a culture. If you want a culture with shared values about how to do things, there are plenty of ways to do that other than keeping the language from accommodating anyone outside of that culture. And your culture will be more accessible to people who genuinely belong in it, if it's visible from the places they already live (e.g. the Rust language).

The languages you dislike are popular because they make it easy for everyone to contribute, and as a result they have a bigger community and, perhaps even more importantly, a greater breadth and depth of libraries and packages than competitors. Rust could be competitive with these languages if it had a low floor and a high ceiling of admissible code quality and sophistication.

Appealing in theory, but not necessarily attainable in practice.

I use Rust to write CPython extensions... it's a well-known fact that GCs are solitary creatures and you're in for a lot of hassle if you want two different GCs to play nicely together.

I use Rust for all sorts of things because I like the high floor Rust sets for the crates I depend on, and I pair that with being more likely to rewrite or find an alternative for a dependency that uses `unsafe` in a context I don't feel it's merited.

A lot of what the borrow checker brings is fundamentally about requiring the programmer to be more precise about what they intend, rather than patching the cracks with extra CPU/RAM or waiting until runtime and hoping it won't come up.

My main concern here is the risk of Rust running into a more minor version of what happened to D, where you effectively had two language ecosystems and the one with a GC and all the libraries wasn't an alternative to C or C++ and wasn't a very appealing alternative to Java.

im not a great programmer but having used Rust and Python/Scala/Java, i have a hard time believing anyone can be as productive in Rust as they would be in a GCed language for many/most applications. Say building a typical backend or prototyping some linear algebra/ML, the memory management is just a very low level that is likely not a concern and takes away focus from the higher level.

I am much more productive in Rust vs Python and Java, it's not even close. Memory management in Rust is trivial, it takes up virtually 0% of my time.

Fear not! Experts will always be inclined to make tools that match their skill level. You can still buy longbows today!