Public
- Public
- Network
- Groups
- Featured
- Popular
- People

Conversation

Notices

Embed this notice
Dan Luu (danluu@mastodon.social)'s status on Sunday, 25-Feb-2024 06:54:44 JST Dan Luu
in reply to

On a related note, I found Jonathan Shapiro's retrospective on BitC (which aimed to fill the niche Rust now occupies) interesting for similar reasons:
https://danluu.com/bitc-retrospective/
In conversation about a year ago from mastodon.social permalink
Attachments
1. The current outcome is extremely frustrating. While the blind spots here were real, we were driven by the requirements of the academic research community to spend nearly three years finding a way to do complete inference over mutability. That was an enormous effort, and it delayed our recognition that we were sitting on the wrong kind of underlying type system entirely. While I continue to think that there is some value in mutability inference, I think it's a shame that a fairly insignificant wart in the original inference mechanism managed to prevent larger-scale success in the overall project for what amount to political reasons. If not for that distraction, I think we would probably have learned enough about the I/O and the instance coherency issues to have moved to a different type system while we still had a group to do it with, and we would have a working and useful language today. The distractions of academia aside, it is fair to ask why we weren't building small "concept test" programs as a sanity check of our design. There are a number answers, none very satisfactory: Research languages can adopt simplifications on primitive types (notably integers) that systems languages cannot. That's what pushed us into type classes in the first place, we new that polymorphism over unboxed types hadn't seen a lot of attention in the literature, and we knew that mutability inference had never been done. We had limited manpower, so we chose to focus on those issues first...
  https://files.mastodon.social/media_attachments/files/111/988/499/244/780/784/original/fa582506a72b4eda.png
- Embed this notice
  Dan Luu (danluu@mastodon.social)'s status on Sunday, 25-Feb-2024 06:54:45 JST Dan Luu
  
  Nice post by Graydon Hoare (original creator of Rust) about his preferences in language design vs. the Rust team and the resultant differences that fall out of the differences in preferences: https://graydon2.dreamwidth.org/307291.html.
  It's rare to see someone who has a deep understanding of the trade-offs involved in major technical decisions write up their thoughts, so I thought this was a really great read even though I'm not really a "language person".
  In conversation about a year ago permalink
  Attachments
  1. The point is to indicate thematic divergence. The priorities I had while working on the language are broadly not the revealed priorities of the community that's developed around the language in the years since, or even that were being-revealed in the years during. I would have traded performance and expressivity away for simplicity -- both end-user cognitive load and implementation simplicity in the compiler -- and by doing so I would have taken the language in a direction broadly opposed to where a lot of people wanted it to go. Performance: A lot of people in the Rust community think "zero cost abstraction" is a core promise of the language. I would never have pitched this and still, personally, don't think it's good. It's a C++ idea and one that I think unnecessarily constrains the design space. ... Expressivity: Similarly I would have traded away so much expressivity that it would probably make most modern Rust programmers start speaking about the language the way its current critics do: it'd feel clunky and bureaucratic, a nanny-state language that doesn't let users write lots of features in library code at all, doesn't even trust programmers with simple constructs like variable shadowing, environment capture or inline functions. Ask people who worked on the early compiler what it was like. It was not easy or fun, and I was stubborn about adding cognitive or implementation complexity just to make it a few percent easier or more fun. I didn't mind making users write...
    https://files.mastodon.social/media_attachments/files/110/490/754/340/547/665/original/b603ff76c5a67432.png
  2. Untitled attachment
  esmevane, sorry repeated this.

Public

Conversation

Notices

Feeds