Sven Slootweg @joepie91@pixie.town

@serapath For example, strict typing without explicit type annotations, pattern matching (which seems to be stuck in spec hell essentially forever), but there are a lot of things that can't be implemented in JS or only in a compromise-filled way because it would break some pre-existing characteristic of the language

@Angle I think there's value to dedicated support groups, but I also think that it solves a different problem (capacity) than what I was describing (awareness of common user experience).

Probably both should exist in a sufficiently large project, though you can get by without dedicated support folks for a surprisingly long time, especially if you otherwise have your community management in order, as there are usually volunteers who take on that work unprompted 🙂

@Angle I think that's a good idea. I've written a couple of things to that effect, and so have others, but I don't think there's anything really comprehensive in the right tone yet, at least not that I've seen.

@Angle I feel that there is a frequently-overlooked option that doesn't necessarily increase work, but only *feels* like it does: developers interacting more directly with users, and providing non-judgmental assistance.

Very often developers take an attitude along the lines of "I don't want to have to deal with users, that's somebody elses job", or if they *do* provide support, it's often in a very patronizing way that scares people away and obscures a lot of the details of the problems that they run into.

I feel that if developers learn to change their attitude on this, and provide end-user support from the perspective of "if someone has a question, that must mean there is a problem with the UX or the documentation somewhere", that could meaningfully improve things.

This *seems* like it's demanding extra work from developers, but in practice I've found that it mainly helps to catch problems early and keep them from spiralling into problems *at scale* - by doing a bit more work upfront, it prevents a lot of confusion, miscommunication, remediation work, redesigns etc. down the line, and the end result is that in the long term it *reduces* the total workload.

The biggest hurdle here, I think, is actually convincing developers to change their attitude in these matters, because that "don't want to deal with people" tends to run pretty deep. The flipside is that this is a change that can be made today, in existing projects, without any extra organizational complexity or costs.

@jon Huh. I wonder how enforceable that actually is.

@serapath It does, but I'm already using that and it's not a cool new language :)

There have been a lot of interesting improvements in language design since then, some of which are difficult or impossible to backport into JS, so I'd like to experiment with some newer stuff too!

@jon Aren't they just using "TGV" as an abbreviation there? IIRC it stands for "train grande vitesse" or so, ie. "high speed train".

@mynameistillian I enjoyed the TV series and especially the movies, but I was a kid at the time, and I'm not sure I would *still* enjoy it today. I did play the shit out of the Gameboy games also though.

@Quenby I would explicitly add to that that it also doesn't matter whether you actually *have* work right now, as long as you *need* it

@bananas Specifications that determine how to convert from one (version of) a type to another, so that you can interoperate between nominally incompatible but semantically compatible types, which is one of the possible ways to deal with the nominal typing problem

@bananas Not unsolvable, though, and I'd be perfectly okay with stuff like "having to manually specify type adapters", because that still causes way less pain than juggling transitive dependency versions forever