undefined | Better HN

0 pointsshadowgovt3y ago0 comments

There's very little in the open source space that competes with, for example, npm + TypeScript + VSCode for usability (where "usability" here runs the gamut from package / dependency management to code comprehension / documentation / refactoring to debugging).

That kind of polished integration often costs money. In contrast, in the open source world we limped along with gcc + gdb for decades until Clang was able to force the issue (which was funded by Apple, Google, Microsoft, ARM, Sony, Intel, and AMD).

0 comments

4 comments · 2 top-level

OkayPhysicist3y ago· 2 in thread

That strongly depends on your definition of "usability". If it means appealing to the lowest common denominator, that's probably fair. Open source software tends to lean technical, because it's made by technical people for themselves. If it means being useful to the people who use it, then I don't think your argument holds water. NeoVim and Emacs at least fairly compete with VSCode, npm is not at all special in the world of package management (Julia's Pkg and Elixir's Hex come to mind as OSS superior offerings), and the world of programming languages is chock full of better languages.

To directly counter your "npm + TypeScript + VSCode", I counter with "Hex + Elixir + NeoVim".

shadowgovtOP3y ago

> If it means being useful to the people who use it, then I don't think your argument holds water

I recently worked on a project involving a couple Docker containers, one of which wraps a Postgres DB and the other extends it.

Some of the features of the extension are broken because the Postgres maintainers changed something key in their Docker image (they disabled the DB listening on localhost) and the scripts the extension generates assume localhost is accessible.

In the (volunteer, free) open source ecosystem, nobody is paid to have that be their problem to solve and so problems like that, to my observation, rarely get solved because these two groups are unrelated to each other and it's nobody's job to make sure "the whole offering" is easy to use.

(And as an ardent and frequent user of Emacs, I simply must see the config file someone claims to have put together that competes with VSCode for managing TypeScript projects. That's a hard claim to swallow without evidence; I've tried, and it's extremely non-trivial. Emacs just pulled in eglot for LSP support... Not that one couldn't self-install it earlier, but every time you have to mutate a system to one-off your own solution you increase the maintenance burden of that system.)

... I'll have to carve out some time to look at Elixir. In my world, of course, "Doesn't have a tool to compile to JavaScript that has made it to v1.0 yet" is a major strike against it, but my problem domain is specific. ;)

UncleEntity3y ago

> Some of the features of the extension are broken because the Postgres maintainers changed something key in their Docker image…

I’m not trying to set the wrong tone here but… how hard is it to modify a docker image that is used as a fundamental part of a production system? There isn’t someone who’s job it is to wrangle these things?

1 more reply

wprl3y ago

I found Dahl’s approach to packages with Deno very interesting. It decouples package management from the runtime’s tool chain. So a package manager isn’t needed. (Instead a proxy can be used as a cache similar to how an artifact registry would work.)

j / k navigate · click thread line to collapse