social.noyu.me

‪i'm like this close to unfollowing someone i know because all they do is dunk on people‬

‪don't retweet this btw i don't want this to get seen by a ton of people who'll project things onto me‬

@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 ow ow oof owie ow

(i haven't burned out but it's like, there's a number of little problems with the language i've wanted to fix that i just never did because it'd be so much work)

@whitequark @mcc and so often even a seemingly tiny simple fix would actually be a lot of work for historical reasons

@hikari @whitequark @mcc YUP

@hikari @whitequark @mcc i want to write a blog post about this at some point, there's no way to ensure work gets done other than blocking stabilization, so stuff either ends up unstable for years or just never implemented because it looks like too much work https://github.com/rust-lang/rust/pull/96709#issuecomment-1181969253

also the rust culture is one of burnout, whole teams are burned out, and so the RFC process is where ideas go to die and you can't get anything done without knowing people personally and spending absurd amounts of time pushing for it yourself

@hikari @whitequark @mcc since this is getting boosted read @elizayer's fantastic blog post that goes into more detail on this https://medium.com/@ElizAyer/organizational-boundary-problems-too-many-cooks-or-not-enough-kitchens-2ddedc6de26a
she also gave a rustconf talk about it https://www.youtube.com/watch?v=n0VeZRTZFxE

@hikari @whitequark @mcc we definitely burned out.

also burned bridges, but that was after burning out.

@hikari @whitequark @mcc 👀 👀 You can also post an issue if you'd like. Happy to talk about it if compiler related

@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 @whitequark @hikari Yeah. Lots of new languages can call C, TypeScript can use JS libs, makes sense that the next gen might have something analogous going on with today's ecosystems.

@mcc @rf @whitequark decoupling the ABI from C would solve so many problems

@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 @hikari COM is everywhere

@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.

@mcc @rf @hikari that sounds... vaguely impractical

@whitequark @rf @hikari Why would I want to do something practical

@mcc @rf @hikari good point

@mcc @rf @whitequark @hikari This is part of what fueled the growth of PHP - it made it very, very simple to connect C libraries to a scripting language for building web pages.

@whitequark @mcc @hikari what examples of this stick out? I think the particular level of precision borrowck has does, plus a lot of design around trait objects and trait coherence (vs. importing impls/instances or such)

@whitequark @mcc @hikari Yes!

Also, I think in general we (programmers, culturally) want to believe the technological outcomes are due to *logic* and that the winning things are the best technically.

Surprise, the winning things often win because of outside reasons, and even within them many decisions exist for reasons besides technical ones!

@whitequark @mcc @hikari Example: C is "the language of the system" because of historic artifacts followed by decades of investment. Something else could be "the language of the system" just fine, and C having won that battle doesn't mean C is "how the computer works"

@alilleybrinker @whitequark @mcc @hikari Though when you start questioning ...

> C is "how the computer works"

... you suddenly have a lot of angry people at your throat who (perhaps correctly) believe that their retirement depends on this not changing.

@mcc @hikari I have been doing language design for 15 years, and I still love talking about literally every aspect involved in it.

But I literally never want to deal with Rust people ever again.
Seemingly their only motivation in language design discussions is to defend Rust and to assume that anyone not cloning Rust's approach 100% verbatim just means he/she haven't been crabsplained enough.

#LanguageDesign #rust

@mcc @hikari it’s frustrating how so many communities go this way. I’ve been in open source for nearly 28 years now, and I’ve seen this same scenario on repeat the whole time. We really need folks to start having “it’s a programming language; chill the fuck out” added to their code of conduct.

@mcc i think that attitude might come from the fact that newcomers often recoil at discovering this language is significantly different from ones they're familiar with, and saying something like “no really, this thing is good, please spend a while longer with it, you'll get it eventually” is important for them. but then this mantra gets repeated also at people who've gotten enough experience to really see where things fail. the eternally troublesome context problem

@hikari In my case, one thing that helped me get over that same hump without having to develop cult behaviors was I had spent time around compilers and taken basic steps toward writing my own compiler, so for a number of the early "wtf?" moments in Rust a compiler person went "consider how much easier this makes to write the compiler, and how much harder the compiler would be without it" and I immediately went oh no. oh no. oh noooo I see it now you'll never be able to fix this one :(

@hikari but also yes i think what you describe is a very real effect

@hikari @mcc It is also repeated a lot by people who have less experience than you do which makes it extra infuriating

@saagar @mcc yes! just as the recipient of the advice may be wrong, so too may be the giver

@mcc @hikari I'd there a language or major framework community that doesn't suffer from this, to some extent?

I absolutely know that kind of people in PHP.

@Crell @hikari Well… I guess some languages do not distinguish themselves enough from other languages for such arguments to even come up. Imagine defending a design decision in C#. You'd have to identify a design decision in C#. C# is so middle of the road on all things that will be difficult

@mcc @hikari Isn't C#'a primary design "2002 Java, but different enough syntax we don't get sued?"

@Crell @hikari Although it's true C# *started out* as an exercise in replicating Java with the serial numbers filed off, over time it branched into… replicating *every other* language that was starting to gain traction at any one time. This did end up resulting in the nice property of a language lots of different types of people can feel comfy in, but it's also at times like stumbling around a vast mansion where every room is dark except your own

@Crell @hikari occasionally finding yourself in front of a set of chained-shut double doors with a hastily scrawled sign pinned on saying "LINQ— *DO NOT OPEN*"

@mcc @Crell @hikari novices have so much reverence for the authors of frameworks and languages, it's hard to break the bubble that something popular isn't perfect

@evert @mcc @hikari Especially when the authors don't dissuade them, or even encourage it.