> I think enabling a language to be garbage collected in general, while making a borrow checker opt in for special, time critical functions is the best of both worlds.

I remain to be convinced that this is possible.

Rust's ownership model exerts huge design pressure on its standard library. There are some parts that just wouldn't work without ownership (like guards), and many that are far less ergonomic than they could be with GC (like iterators).

If you make a language GC by default with opt-in ownership, what does your standard library look like? It either isn't usable in ownership code, or it's crippled for GC code.

>I remain to be convinced that this is possible.

Check out D language with default GC and the ongoing effort opt-in ownership model:

https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in...

I think it would need to have a GC like Go’s that allows arbitrary interior pointers. Then most of the standard library could continue to take references, which would be allowed to point to GC or non-GC memory. There isn’t too much in the standard library that wants you to pass things to it to take ownership of that make sense to be shared. For example, the buffered reader structure wants ownership of the file it’s reading from, but it’s not like it’s going to make sense to read the same file descriptor at the same time it’s being read by the buffered reader.

I think the bigger problem is that GC pointers will have to work like Rust’s reference counted pointers do today, meaning you need to use mutexes, read-write locks, etc. to mutate anything behind them. Most shared-memory GC languages allow free data races on all member variables, and just provide unordered atomicity to prevent you from being able to cause a race that writes a bad pointer somewhere. Changing that would be a much stronger mismatch, and as long as that’s the case you’re still not going to be able to write Rust code like you would Java or C#.

The obvious solution is that the standard library would provide both options wherever appropriate, just like Rust has `borrow` and `borrow_mut`, `raw_entry` and `raw_entry_mut`, etc. You might be able to save some of this pain with some polymorphism, as some people suggest[0] for `&` and `&mut`, too.

It might also be a good idea to look at the standard library of Idris 2[1] — it has linear types and garbage collection, so it has many of the same issues you describe, and it also seems to solve them with duplication where necessary[2], at least sometimes.

[0]: https://github.com/rust-lang/rfcs/issues/414

[1]: https://github.com/idris-lang/Idris2/tree/master/libs/base

[2]: https://github.com/idris-lang/Idris2/blob/master/libs/base/D...

There would at least need to be some kind of interface of gc and non-gc methods. I would welcome any academic papers on this idea.

> If you make a language GC by default with opt-in ownership, what does your standard library look like?

I could see the opposite working out very well. Having a GC type you can box other types in.

https://github.com/Manishearth/rust-gc

Well, the idea would be that references and values alike could be marked to be excluded from the garbage collector and then used in a borrowed way. If you want to interface with the garbage collector, you have to do so in an explicit way. However, I have no idea how to do so.

> node ... the ecosystem is a joy to work with

I'm not entirely sure I've heard anyone express this before. What do you like about it?

Tools like ESLint or prettier are really top-notch. TypeScript itself is a really nice language, too. Its type system is pretty powerful, more than one would expect certainly. Going from TypeScript to Kotlin feels like such a downgrade in that regard. Also the wider JS ecosystem really has some great, high-quality projects that explore (or possibly reinvent, in a positive way) ways to do things in an elegant way.

I actually think NPM is an amazing tool. When comparing to many other dependency management solutions, NPM:

1. has a nicer user experience

2. gives a lot of confidence that a project will be reproducible across environments, with only a package.json file

Cargo is pretty close, but NPM is the gold standard for dependency management as far as I'm concerned.

I have some frontend developers in my team who think java is slow, but wait minutes waiting for NPM to finish its job. Our backend code builds 3x faster than our frontend code these days.

But is that because of npm, or is it because of their massive array of dependencies, plus webpack, bable, pollyfills and whatever 5 transpilers they have integraated into their project?

In my experience, it is both.

Last time I used NPM, it tended to download megabytes of dependencies for each project. If you used a package in, say, 10 different projects, you had 10 copies of it. Did they solve that issue?

It's good for isolation: i.e. in general if you copy a directory containing an NPM project to another location, in general it will just work, and deleting something elsewhere on the file system should never affect the project. In general I would argue this is a more important property for dependency managers to have rather than using the least amount of space possible.

If you really want to avoid it you can install everything as a global dependency, but it's not best practice.

This is still the case. There are some alternate package managers (pnpm, yarn) that handle this better, but they both break some tooling. In practice, I've found that it's not too big an issue—most people have plenty of disk space, and if you are running low you can just `rm -rf node_modules` on some old projects and install again next time you touch them.

Multiple points:

I really like how there's a package for everything. Many other languages have adopted this method, but for example in Rust, most packages are not as mature as JS packages are. The JS ecosystem is responsible for spawning services that fund Open-Source developers. Packages are also easy to install. I spent a whole weekend trying to install Postgres and Drogon (a http server) on C++ with conan/vcpkg, and in the end I could only manage with a docker container installing these dependencies via apt-get, which was exactly what I did not want.

Furthermore, NPM is the package manager among package managers. No other package manager comes close. Python has too many options, virtual environments and so on. Rust's cargo is good enough, but I really do not enjoy having to install a seperate package (cargo-edit) just to add a package via the command line instead of editing text files. C++'s package management systems are most of the time a total letdown or don't have widespread adoption. Not only that, npm also takes care of a package maintainer needs (semver, transitive dependencies, etc)

---

Many people express dissatisfaction about build tools and the like, but as someone who got into webdev at the exact time people began building larger applications on the client, I love them. Sure, when they first appeared they were a pain to work with, but most modern build systems are amazing. I can just include most files (MD, SVG, images) and work with as if they were JSON/JS files and don't have to worry about how it's done internally.

---

Prototyping is really fast and important if you work with startups or want to create a proof of concept for a customer. I can throw together a functioning backend with http server and database in a couple of days.

Modern JS frameworks are uncomplicated and can be minimal if you know how to use them. For example, my personal site (https://juliankrieger.dev/) is written in Gatsby and React.js, but it weighs only 20kb. Now, there's not much on it but all content is rendered server side and only rehydrated when I need it. For anyone interested in getting even better results on a personal homepage, I recommend looking at 11ty for a static site generator and htm/preact for an absolutely minimal React implementation that only ships javascript where you really need it.

---

I also like how it enables me to write scripts for personal use and at the same time I can use Node for larger projects. I've used python for this in the past, but a large python code base can be a beast of its own.

Moreover, not having to recompile dependencies on a code change is a welcome feature. My main problem with Rust are the large compile times. Node even enabled me to hot reload code under the right conditions, making iterative development an insanely fast process.

> I think enabling a language to be garbage collected in general, while making a borrow checker opt in for special, time critical functions is the best of both worlds.

Put everything you don't want to manage into Rcs, RefCells, Boxes and the like, and you'll more or less feel like you're using a (verbose) GCed language (with a loss of performance and safety as a natural consequence).

> I enjoy Rust and have been writing it for quite some time. However, I feel like server side languages still have a long way to go. Client-side languages in comparison have been only growing better

The fact you call them "server-side language" is a strong bias. Not everything is a client/server app.

RefCells and Boxes just throw the same errors at runtime instead of compile time.

RefCell is runtime "borrow checking" where a panic is thrown if the object is already mutably borrowed. Depending on your use case you might not even care about this behavior because you have other invariants that ensure that you're only borrowing mutably once, you just can't encode it in the type system. Otherwise, you would combine it with Rc[1]: Rc<RefCell<T>>.

Box, on the other hand, doesn't have any runtime cost. In fact, it's runtime cost is the same as a borrow: both & and Box<T> are just plain pointers, with the extra benefit of having compile time lifetime checking.

[1] https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...

(RefCell yes, but box no)

Woops, I guess I meant RC's and RefCells.

Fast, garbage collected with plans to add a borrow checker: dlang.

It is an absolute joy to write code in D. Only downside is people complaining it has garbage collection.

Has there been much progress with the D borrow checker? It always comes up in these threads but it seems to still be missing some key features (parameterized lifetimes for example). What’s the timeline for this landing in some form of “non-experimental”?