From Languages to Language Sets

andyferris · 2025-03-16T23:30:03 1742167803

One thing I'll note is we tend to use languages from different levels in different settings (front end, back end, systems) and we spend an awful lot of time writing glue code to get them to talk to each other.

A major advantage of the proposed approach is automated FFI and serialization/deserialization between languages in the same language set. RustScript would be able to accept a struct or enum from Rust or RustGC, and vice-versa. You could have a channel with different languages on either end.

You can also see that we _want_ something like this, e.g. we bolt TypeScript on top of JavaScript, and types onto Python. If JavaScript (or python) were designed so they could be more easily compiled (notably, no monkey patching) then they would support level 2 as well.

I have been thinking of level 2 or 1 languages that support the higher levels. This is a really good framing. (The problem with going the other way is the implementation decisions in the interpretter often constrain how the compiler can work, e.g. CPython is dominant because all the libraries that make use of the CPython FFI, and similarly for NodeJS. It is easier to interpret a constrained language than to compile a dynamic language designed with an interpretter in mind).

sitkack · 2025-03-17T00:46:49 1742172409

Back when I did some high perf Python, I’d define my data at C structs and bump allocate those structs in a list using the cffi.

It is not unlike defining your data model for SQL so that you can have sane data access.

gabrielsroka · 2025-03-17T01:06:44 1742173604

2022

https://hn.algolia.com/?query=From%20Languages%20to%20Langua...

teaearlgraycold · 2025-03-17T00:11:48 1742170308

I’m a strong supporter of adding an automatic GC to Rust. Although it seems difficult to justify as RustGC code wouldn’t be trivial to convert to traditional Rust. But going in the opposite direction should be trivial.

（评论） (comments)

（评论）
(comments)