Comment by jerf | Hacker News Reader

Comment by jerf | Hacker News Reader

"It has also devolved into a situation in which many commenters propose to reverse previous decisions about the design of async/await on which we have already established firm consensus, or otherwise introduced possibilities we have considered and ruled out of scope for now. This has been a major learning experience for us: one of the major goals of the “meta” working group will be to improve the way groups working on long-term design projects communicate the status of the design with everyone else."

I'll be pretty intrigued to see what they come up with for that. I've been up closer to the Go developer's attempt to connect with the community, and while I'm not going to say they've done everything perfectly on their end, I've also been sort of frustrated by the way that they'll put up a request for comments about something in particular, and a good chunk of the community replies basically throw away everything they're talking about and rewrite arbitrary amounts of the language from scratch. By "everything", I don't just mean the direct proposal under discussion, but the goals of the proposal, the discussion of alternatives from other languages and how they are and are not relevant, as alluded to above the things already proposed and rejected for solid reasons, the context around the runtime and how it interacts with that... that is, not just the proposal itself, but all the thought and reasoning around it too. That wasn't really the question, so to speak. This frustrates everyone, on all sides, in various ways.

A lot of the problem is structural to what is being done; there's a lot of impedance mismatch between the core designers and the community at large for any language. It would be interesting to see some explicit thought around how to address that, from a community with Rust's experiences.

It's just means there is lack of trust to core designers. They haven't proven themselves to users, that they are capable of addressing their problems and align with their interests. Obviously core devs of Google backed language cannot do better. They can only gain that trust from users within Google, not outside of Google. Not sure about Rust though.

> Obviously core devs of Google backed language cannot do better. They can only gain that trust from users within Google, not outside of Google.

That's a non sequitur. Trust is not mandated by company boundaries. I for one trust in the competence of the Go maintainers, while at the same time having absolutely zero trust in Google as a company.

> I for one trust in the competence of the Go maintainers

That's fine. But ultimately Go employees do not work for you and cannot put much effort into proving they are good at solving problems for you, since the company doesn't pay them to do it. There will not be a track record in users eyes of their design decisions and not much trust from users they are even capable of doing it well.

> the company doesn't pay them to do it

It absolutely does. Google has a vested interest in making Go a popular language outside of Google: It improves sentiments towards Google by association, and it means that Google has an easier time onboarding new hires since they probably already know Go.

If they're paying people to develop tools for solving general purpose computing problems and presenting those tools out in the open, then they are doing something that is good for everyone.

It does not necessarily mean a lack of trust. It could be different incentives or priorities.

For example, some users might desire major redesigns of past work but not bear the cost of the rework. As such, they might perceive some small improvement without any (direct) cost.

Personally, I think some groups have moved so far in the direction of community involvement that they forget the practical implications of diversity. Leadership is hard for many reasons — one big reason is that leading sometimes means making some people unhappy. Still, this is much better than inaction.

Could you please give some examples? I think I follow Rust pretty well, but have no idea what/which-improvements/who/which-groups you could mean.

I don't want to name any particular people or groups, because everyone makes mistakes and has limitations.

I will say this: in my personal experience, I've been a part of groups that struggle in dealing with complex decisions. Many times they get bogged down when they don't find a clear answer that satisfies everyone or all criteria. In many cases, such groups don't have a clear leader or the leader lacks the skills, experience, and character to do what is necessary; namely, choose (and communicate) the least-worst decision that keeps the ball moving forward.

In such cases, it is not necessary (and unrealistic to expect) that everyone agree with every aspect of every decision. A leader needs confidence and persistence to make tough decisions, as opposed to abdicating leadership. Some examples of the latter include (1) ignoring a choice until some default decision is made implicitly or (2) simply choosing the idea from the most vocal person.

Put more broadly, in this context, leaders must balance four aspects: (a) scoping and framing a decision; (b) gathering diverse points of view; (c) building some degree of consensus or buy-in; and (d) making a decision. It appears to me that the Rust language team handled all four comprehensively.

"It's just means there is lack of trust to core designers."

I don't think that can explain the observations I've made. Either that or the sort of trust you describe is simply impossible, because I've never seen it in any language community I've been in.

I'd lean more towards a lack of clear description to the community for what they're looking for, and the community buying in enough that when communicating amoungst themselves they also do some lightweight enforcement of the expectations.

I wouldn't go that far. To me it looks like the usual bikeshed effect is at full force.

From what I've seen of Scheme they dont have this problem. Everyone implemented the feature they want or forks an implementation. And no one argues about syntax.

"And no one argues about syntax."

No one argues about the syntax, because everybody "wins" and gets their own syntax as a result, which is often held up as a key part of the explanation for why the Lisp family languages are wonderful and fun and mind-expanding and just awesome in every way... yet rarely escape from "niche" status and are yet to even threaten to break into the really top-tier languages.

Because languages like Rust and Go, and Python and Java and honestly almost every other non-Lisp family language, want more cohesion in their codebases, they need a different solution to the problem.

Fragmentation cannot really be an issue for adoption, as it happens after adoption.

So the Linux desktop will only become fragmented after the mythical "year of Linux on the desktop"?

I'd say fragmentation hurts retention, which only has secondary effect on adoption.

Yeah, but any language more popular than brainfuck has some level of adoption. Your language doesn't have to be super popular to start having adoptions issues.

"I'd say fragmentation hurts retention, which only has secondary effect on adoption."

I have no idea how you come to that conclusion. Any conceivable model for adoption I can imagine is a differential equation which contains "current adoption" as a term going into the first derivative. If people are leaving a language faster than people are coming in (and I speak in general, not claiming this about any particular language), retention is going to have major effects on adoption and the lack thereof.

http://winestockwebdesign.com/Essays/Lisp_Curse.html

That's just a meme from that Lisp Curse article and wherevernot; it's not spread by people who have actually worked in a Lisp code base.

Wasn't there a bunch of disagreement about R6RS?

There is some hearty discussion in the Scheme community about syntax, but less than in some other communities. Part of the reason might be that most new syntax looks like this, with no changes to the language grammar:

    (my-new-syntax-name arbitrary other stuff goes here)

Related to this, some things that would have to be primitives in many other languages can be implemented nicely by anyone as ordinary libraries in Scheme.

Reply on news.ycombinator.com