arcatek

> Somehow you are not wary of an organization that is 90% directed by one entity. It might be useful to know that 95%+ of the code changes in wasmtime are by people working in Fastly.

I'm not overly worried about some companies investing more in communities than others, that's true, as long as there's some level of oversight (those 5% you mention).

I also suspect that a lot of those Fastly employees you mention came after the Mozilla layoffs we heard about a year ago, which I think invalidates a bit your point as the responsibilities were then shared before being unfortunately moved in to Fastly in short notice. It makes sense it would take time to address that perfectly, considering the context.

> Google is the main pusher to Chrome, the fact that Google is a commercial entity doesn't make good or bad on how they move the ecosystem forward. It makes it more effective.

That's not a great example - Chrome famously pushes changes without any oversight, which leads to useless APIs in the best cases to downright harm to their users in the worsts.

- Not the same bakers (wasmtime is supported by the Bytecode Alliance nonprofit, which is behind the wasm specs, whereas wasmer is a startup)

- Not the same implementations, so not the same optimizations performances everywhere (you can see that a bit like clang vs GCC).

So which one to use depends on your tradeoffs. For me personally, I saw firsthand what an ecosystem tool could become once owned by a startup, and I would be very careful about this path.

There are more technical comparisons here and there if you look a bit (for example in /r/rust).

I've contributed to a lot of repositories, and I've yet to see a single one where tests aren't automatically run. I can only think of a single one where some benchmarks are run on-demand.

How do you think social engineering audits work? You first coordinate with the top layer (in private, of course) and only after getting their agreement do you start your tests. This isn't any different.

Getting specific consent from the project leads is entirely doable, and would have avoided most of the concerns.

It's almost like you need something to manage your packages to generate them.

Speaking of Yarn in particular since I maintain it, I strongly believe that more than speed we (package managers) need a good polish. And to do that, we need a community that feels empowered to make changes when they feel frustrated about something - which makes using JS / TS critical. By contrast, the UX of a bundler / linter is fairly straightforward (compared to Yarn's 46 builtin commands), so making external contributions easier isn't really necessary.

We now use it to build Yarn, and it's been working very well. Still some rough edges that prevent us from adopting it at work (like the lack of dynamic imports when the import expression references variables), but I'm slowly making progress in implementing workarounds for that through loaders, and the first results are encouraging. At its worst, with a Webpack/Esbuild hybrid approach, we get at least 2x better perfs.

Don't casinos ban players who for example know how to count cards? This would imply that skills may trump the house edge, and thus a bot that would know how to stop (ie how to hide their skill) could stay ahead.

I had this problem at first (I kept my source codes in a separate drive to be able to edit them from my Windows IDE), but nowadays I just keep all my code files in WSL and I don't notice the problem at all anymore. VSCode makes interacting with the box completely transparent.

I know it's the official reason, but it's also a really bad one - nothing prevents current JSON parsers to add some weird syntactic rules inside plain strings (similar to "use strict" in JS), but you don't see that happen. It's always been a completely hypothetical issue.

The only real reason why comments would be problematic is that they are a pain to preserve in a consistent way when editing a file, and thus would require extra work in parsers / serializers. Still, it would be worth the cost imo.

I can answer this a bit - I maintain Yarn, a JS package manager. While nowhere near Curl, it does have a fairly significant user base - at least a few million devs, from what I understand. For all this work, I received exactly two emails thanking me for my work during the past four years.

I also happen to maintain a little "Secret Santa" website, hosted on a GitHub page. Nothing too fancy, just a static app that lets you manage a Secret Santa without creating accounts. Well, every year, I receive 3-4 emails thanking me for creating it, which is even more surprising considering they often come from people that aren't from the tech world at all.

Perhaps for my happiness I should invest more in this side project than in a package manager used across the globe :)

I'm really disappointed in this change - we use an internal extension in my company to quickly jump from one place to another, and this change means that all our internal users will have to re-learn this workflow - with the expectation some never will, since <tab> is quite harder to reach on most keyboards than <space>.

Given how obvious is the accessibility issue, and how silent was the change, it's hard to read it as a positive change when it's clear that the deciding factor is that it's been deemed better to have users unintentionally reach Google than the search engines they explicitly decided.

GitHub searches are particularly bad. They always give you test folders and examples before and after actual relevant source code. You'd think they would know that folders named "test" should be in a separate section...

This blob is literally our open PR, applied to the various TS releases. You can rebuild it using `gen-typescript-patch.sh` (we actually have a GH Action that does this on CI, to prevent malicious uncontrolled changes), and the sources are auditable in my PR.

Note that it gets applied regardless of the linker since it would cause the cache to change when going from a linker to another, and we wanted to make the experience smoother, but that it's a noop for non-PnP environments.

Regarding TypeScript, I think it's important to point out that we have a working PR in the TypeScript repository that we've been maintaining for about a year now. It's not so much special casing as being ahead of trunk. I still hope the TypeScript team will show interest eventually and we'll be able to streamline the development.

[1] https://github.com/microsoft/TypeScript/pull/35206

People finding sympathy in the CEO behavior should make an effort to remember the number of time they likely ranted about their landlords / network provider / post service / bank service / ... on Twitter. How would you have reacted if they had decided to ban you without even letting you take back your assets?

Closing a customer's account without following procedures, on the CEO's whims, just because they don't feel comfortable with your practices, with a passive aggressive "sorry it wasn't a good fit for you!", deleting data in the process, is extremely unprofessional. There's no good light for this.

In fact, the following story is a great example of the danger of this kind of practices: https://www.newsweek.com/bank-closes-accounts-criticizes-twi...

I applied with, I think, a reasonable use case, but no word either. I don't have much hope to try it in practice anytime soon.

Yarn already removes the need for node_modules without requiring to change interpreter and APIs, though.

Disclaimer: I haven't used Tailwind. Maybe I'm missing something.

> For example, if I'm working on a card and I want some text below the main text to have a smaller, gray font size. What do I name that class? "card-sub-text", "card-sub-title"? No - don't even worry about it - "text-sm text-gray-700" and move on.

What's the difference with "color: gray; font-weight: 700"? In this case I really don't have to care about the property order, whereas in your case I would guess you still have the cognitive overhead requiring you to know that "gray" comes before "700" (unless it's expected to be preprocessed away? what if I use text-700-gray?).

Hi everyone! I've been working on this project for such a long time, this is incredibly exciting. Feel free to ask any question you have regarding Yarn, package management, the Javascript ecosystem, open source projects, or cats!

> I used to do tech support and some people (not too many) wrote right out rude or nonsensical (like concluding I hate their religion just from the fact our service failed to suit their specific needs).

This isn't at all the same thing. You were paid to do your job, and at the end of the day you could just joke about those weirdos.

When working on an open-source project, everything becomes much more personal because your motivation is fuelled by your own personal attachement to the project. Imagine you're helping elderly people cross the street every day, and every once in a while they yell at you for not doing it better, whatever that means. At some point is it still worth it?

And of course you can't just put that behind you once you're back home, because this abuse happens at home. I remember this time where someone literally told me to kill myself while I was fixing a bug - at midnight - in a project I handle. Or the time I woke up only to see that during the night someone public had decided to openly send me literal fuck emojis on Twitter to right a perceived wrong. Good times.

So yeah - building a shell is the right solution, but it's hard and we really shouldn't have to deal with that in the first place.

Fwiw our PnP implementation is now much better than a year ago (it was still experimental, after all!). Expect to see more in this space in the next few weeks...!

I don't think there is any constraint that a single answer is true, otherwise the exercise wouldn't list "All of them" as a possibility.

Both are kinda true - Yoga started as a C library, but was ported over to C++ ~a year and a half ago.

What would you say are the current main limitations of this approach? What is Lucet not meant to be good at?

It would make sense to print the registry before asking for the new version in `yarn publish`, so that you get a chance to double-check that the publish target is what you expect. Will open a PR for the 1.16, unless someone beats me to it :)

The `postinstall` scripts would likely be better off without using those features, indeed. But in the end, your packages would be better off without `postinstall` scripts anyway ;)

> If you use either of these features your package.json will no longer work with NPM.

Yes and no. In the case of the `postinstall` script (which might indeed have to run on npm setups) you might want to refrain using those features. In any other case you simply won't use npm if you use them, because those are local scripts that only you and your team will use - and regardless of those features you should all use the same package manager anyway.

> Noooo, god no. Package management is a gargantuan, complicated task, and these languages all have their own solutions already.

We won't spend much time on it ourselves - as you mentioned other solutions exist and we have to pick our fights. Still, I believe this is a necessary move if we want to make our codebase clear and easy to contribute to. It's not so much about Yarn supporting everything than it is about making sure that we don't end up with a monolithic system hard to maintain.

Note that this is mostly about the command line syntax, not so much the commands themselves which will be executed just like now.

That being said, maybe we'll offer some builtin as well (possibly in a similar way to what CMake offers?[1]). That would be worth an RFC later on :)

[1] https://cmake.org/cmake/help/v3.2/manual/cmake.1.html#comman...