social.noyu.me

i think rust is great, easily my favourite programming language, and i agree with rust advocates on many things, but the sort of culture war-y way some people approach it gives me the ick, no matter which side you're on

@hikari The "if Rust does it a certain way, it must be right" attitude is infuriating and never more so than when you're actually trying to write Rust. It leads to really shallow thinking about the language.

What's really weird is I've stumbled into interacting with the actual Rust core devs and/or inventors a few times and they're all really nice, humble people who *don't act like this*. You ask about an odd decision & they either talk about complex tradeoffs or are like "oh that was an error"

@hikari Like, I want to be writing Rust, but there are a lot of things in it that come down to "this is a bad thing that was situationally necessary in order to achieve some other goal" and you want to figure out ways to cope with the bad thing and someone's coming along trying to convince you that the bad thing is Good Actually and it's just exhausting and unhelpful.

The only positive thing I can say on this front is I've also interacted with the Go community and they're even worse about this.

@mcc @hikari rust has sooooooo many tradeoffs in it where the root cause (there's no root cause) is that someone burned out trying to improve it and quit

@whitequark @mcc @hikari Rust is the product of a new programming language becoming much, much more feasible to create over decades. I'm hoping the same thing happening again will make it more possible for the space "near" Rust (using some of its ideas) to be more fully explored

@rf @whitequark @hikari Maybe, but also what I think about a lot is that one of the biggest barriers to making a new language is building a library ecosystem. Like the libraries are at least half of why I want to use Rust or TypeScript.

If I ever do a language project enough it's likely to be built on top of Rust in some way that reuses the ABI just so I don't ever have to learn or expect anyone else to learn a new library ecosystem again.

@mcc @rf @whitequark or rather decoupling ABI from languages generally. i want a universal cross-language native interface definition format

@hikari @mcc @rf @whitequark blank stare approximately once every decade someone reinvents Microsoft COM

@hikari @mcc @rf @whitequark And don’t get me wrong. COM is a great idea

Its also a terrible lowest-common-denominator thing almost by definition.

@hikari @mcc @rf @whitequark Fun fact of the day: Did you know that IUnknown made its way into CoreFoundation?

Its used as the backend for CFPlugin

@hikari @mcc @rf @whitequark (I think this one will amuse Hikari most of all)

@erincandescent @rf @mcc @whitequark …what???

@erincandescent @rf @mcc @whitequark okay tbf IUnknown is pretty minimal and i suppose they can't put a dependency on core foundation or libobjc inside core foundation

@erincandescent @rf @mcc @whitequark @hikari COM's focus on header files and RPC means it has no meaningful notion of in-register ABI, also known as "calling convention". This omission means that where relevant, it simply canonizes C or C++ ABIs.

Decoupling has not been achieved if it does not allow recompiling the same C source to be incompatible with itself without reference to bespoke compiler flags, beyond those in the decoupling mechanism itself.

@erincandescent @rf @mcc @whitequark i was considering mentioning COM actually. i was also thinking about WinRT

@erincandescent @hikari @mcc @rf @whitequark COM is still on top of the C calling convention!

@jrose @hikari @mcc @rf @whitequark Well, technically __stdcall.

But the C Calling Convention is Mostly OK. Having your ABI be defined in C headers sucks though.

@erincandescent @rf @mcc @whitequark @hikari that’s nothing, every 5 years we reinvent ASN.1…

@thias @rf @mcc @whitequark @hikari I would link to my post about that particular cyclical wheel reinvention but alas it was taken down by the taliban

@hikari @mcc @rf @whitequark I keep playing with writing down a syntax for it and then get bogged down when I realize the most interesting thing would be enums/ADTs. Though maybe what Rust picked for repr(C) enums is close enough.

@hikari @mcc @rf @whitequark LLVM is nearly this except where it isn’t at all. WASM is sort of this except it’s not actually native; it’s just easier to target than the JVM or CLR.

@jrose @mcc @rf @whitequark llvm is extremely not this in practice. wasm is maybe our only hope

@hikari @jrose @mcc @rf @whitequark brb, adding asm macro to wasm. :p

@hikari @rf @whitequark so like in the case of Rust the language is very tightly coupled to the "ABI" and if you generalized the ABI it would no longer capture what is useful about the language. Part of what's captured in a Rust function call is who is responsible for freeing any given piece of memory. How many languages even have a concept of someone being responsible for freeing memory, much less designating who it is?

@mcc @hikari @rf @whitequark Interestingly, one example of a language which has annotations for that is… Modern Objective-C!

@hikari @mcc @rf @whitequark You hit the nail on its head.

I have spent a lot of time thinking about this, and the current approach where every language puts its ABI into their own little defined-by-code silo is a dead end.

There are various existing ideas to look at, though my personal approach is basically saying "ok, what's going to happen if I write my own PT_INTERP?".

@hikari @mcc @rf @whitequark Wasm Components appear the be the best hope for that at the moment.