3 ms·
> All of these other things could be done for C++. But, importantly, they haven't. I think programmers often under-emphasize the importance of culture, so I w
by aeturnum 6y ago
> All of these other things could be done for C++. But, importantly, they haven't.
I think programmers often under-emphasize the importance of culture, so I want to boost this line.
Lots of "debates" around programming languages are, I think, better understood as differences in beliefs about what a language should prioritize. C++ could add an allocation checker that provides stronger memory guarantees by outlawing certain operations (or requiring they be marked a'la `unsafe`). They don't add it because, I think, they view other additions to the language as having a higher "return" on allowing people to create high quality programs.
It seems to me that a lot of this comes back to first-principles about what makes a good programming language. These ideas are, to some degree, set before a line of code is written. The rust folks thought memory and concurrency safety were very important when they were designing rust - even though they couldn't have formed those opinions by using the kind of language they were making (because nothing quite like it existed yet).
I also think about "infamous" qualities of languages (generics in go, the GIL in python). These ideas exist within wider cultural beliefs about what makes a good programming language. In a sense, it's inevitable that most of the people working on cpython aren't too concerned about the GIL, because they chose to work on a project that has developed around the GIL and believe its limitations are worth the gains from being able to rely on its coordinating function.
The implications of this are, to me, that when advocate for languages to adopt features we'd like to see we should remember the wider cultural context. It seems silly to expect the current golang team to implement generics "the way the community wants" because they've spent years building a fully featured language that functions without generics. Culture runs deep and it's not an intellectual or professional flaw to value improvements differently than our peers.
- sk2020 6y ago>nothing quite like it existed yet. Cyclone has been around some 2002 according to Wikipedia. I don’t think a similar language (RAII + annotations + a mostly-mandatory validation step in the compiler) has had a well funded and sustained marketing campaign until rust, though. RAII also predates Rust by a couple decades. Rust is also not very similar to itself from its early days.
- aeturnum 6y agoOh, I didn't know about Cyclone - that's cool! I wasn't trying to say that rust isn't influenced by languages that came before it. I mean that, when they decided it was time to make a new language, the team would have had some understanding of what the language would be like. That understanding couldn't come from using the language itself (it doesn't exist yet). Instead, teams do cultural work to communicate & come to shared understandings about what the language they are making "should be like." That shared understanding survives past when the language is working and influences decisions to improve the language. It's just worth considering and talking about project culture! It's common for there to be many possible improvements to a language and have the culture of the project (or wider community) be what tips the scales.