Carlos Ceron

> That said, it is still the case that most programs aren't penalized by GC much. But people do still work on operating systems, games, databases, video editing tools and such where getting great performance is really important.

This statement simply isn't true though, at least in the general sense. Sure, for old school atomic RC and compilers that didn't do RC elision etc it might've been true. But we can and have made smarter compilers, just like Rust has gotten smart about life times.

Like @netbioserror I use Nim, but for embedded and real-time stuff. There is a minimal overhead (one machine word per allocation), but using Nim's ARC "memory management system" gives me results comparable to Zig or Rust though with much less work. Technically ARC without the cycle collector isn't a GC.

There's no reason D and other languages with "memory management" couldn't do similar RC based systems. As the compilers get smarter it approaches the same result as Rust's manual lifetime analysis. In many cases compilers can be smarter than human programmers about memory.

Even then, there's occasions where in Nim one can and will reach for manual memory allocations. It's easy to do when wanted.

> 2. There will be things the language won't let you do, because it is garbage collected

There will be things that systems like Rust's lifetimes makes harder / less performant as well: https://ceronman.com/2021/07/22/my-experience-crafting-an-interpreter-with-rust/

> 3. There will be extra FFI…

The safety guarantees don't come for free. There are tradeoffs. That should be clear from the fact that Rust as a language is still changing, i.e. relaxing ownership rules and adding new mechanisms to the type system. If there were no problems, then there would be no language changes necessary.

Examples of people writing Rust code and hitting problems of expressiveness and performance:

My experience crafting an interpreter with Rust https://ceronman.com/2021/07/22/my-experience-crafting-an-interpreter-with-rust/ (I'd be interested in experiences from others who have implemented a GC'd language runtime in Rust)

Also see Why I rewrote my Rust keyboard firmware in Zig: consistency, mastery, and fun
https://news.ycombinator.com/item?id=26374268

You can argue about how much the tradeoffs matter, which is heavily domain specific. But you can't argue that the tradeoffs don't exist.

I don't spam C++ and I comment on C++.

There is no fight. There is made-up flame-war. Every war happen at HN and Reddit's Echochamber not at Real World.

Every languages has headaches. You won't find a perfect language ever.

You can't do serious Rust if you don't understand functional aspects.

I know C++, Haskell and Rust. Like many says Rust is a functional language disguised as imperative. There were case studies on Rust where a one with Haskell background more like to learn it faster than a one with C++ background.

The Rust book don't show you the functional parts at beginning to build your intuition but once you drive deeper you will realize what I meant.

https://ceronman.com/2020/09/17/is-rust-a-functional-language-in-disguise/

Nice article. A couple of years ago I also implemented Lox in Rust. And I faced the exact same issues that the author describes here, and I also ended up with a very similar implementation.

I also wrote a post about it: https://ceronman.com/2021/07/22/my-experience-crafting-an-interpreter-with-rust/

I ended up having two implementations: One in purely safe Rust and another one with unsafe.

Note that if you're interesting in the "object manager" approach mentioned, I did that in my safe implementation, you can take a look at https://github.com/ceronman/loxido

> Most “scripting” languages don't support annotations for checking parameters and return values

PEP 3107 introduced function annotations to Python 3. The following syntax is valid:

>>> def square(n: int) -> int:
... return n * n
...
>>> square(3)
9

Nothing is done with annotations by default. Here's an article discussing this "unused feature": http://ceronman.com/2013/03/12/a-powerful-unused-feature-of-python-function-annotations/

Well the original post is one example, obviously.

But, lots of examples below, all from the first few Google results of "coffeescript ambiguity":

http://ruoyusun.com/2013/03/17/my-take-on-coffeescript.html [section "full of surprises"]

http://ceronman.com/2012/09/17/coffeescript-less-typing-bad-readability/

http://johnbender.us/2012/11/27/math-envy-and-coffeescripts-foibles/ [this is a more formal analysis]