iamed2

I wonder if this means they migrated away from Honeycomb, which often lists Stripe as a prominent customer (e.g. "HelloFresh, Stripe, Slack, Fender, Vanguard, LaunchDarkly, and many more rely on Honeycomb" in most blog entries).

The terraform provider has returned

It's important to resolve changes to the package environment as a whole. Pip doesn't really do this, and as of a few years ago didn't even resolve multiple CLI-specified packages together, and this causes major compatibility and consistency issues.

Doing this correctly can be difficult to get fast, but performance does matter. Resolving Conda environments adds way too much time to CI jobs. The Pkg.jl resolver is pretty great and we never have to wait for resolution. It's my understanding that this was a non-trivial technical problem that went through a few implementation iterations.

Explainability on failure to resolve is a really useful tool that becomes more difficult the more features you add. Pkg.jl has struggled with this in some cases where it hides certain version restrictions (e.g. "by explicit requirement" is rough when your project hasn't set that particular requirement). Lots of people have spent lots of time trying to identify incompatibilities over the years, and we've had to rely on people developing arcane knowledge to interpret resolution failures.

Immutable, cached packages is important for avoiding spending a lot of time downloading. It's very important to completely distinguish different versions/configurations though, i.e. you don't want a configuration setting that affects which code gets put at `~/mypkg/packages/<pkg-version-id>`.

The package source should be reliable/redundant. People will install packages in the course of normal work (automated updates, testing, etc.) and will need an always-on package manager. GitHub has proven not to be reliable enough.

At the same time, an offline mode should be available.

Getting installation configuration options right can be a big value add. I love cargo's feature flag implementation, and even Python now has "extras".

Every package manager eventually regrets not adding a "yank" feature.

Enterprise users will always eventually want to see multiple sources (private and public).

I appreciate when package managers consider the audience for their output and don't output line-by-line progress meters when running in a non-interactive environment.

Querying the package dependency tree is really useful! Both dependants and dependencies, flat and recursive. Even better if there's a library to do this that you can script and experiment with.

Medications for anxiety and depression can cause brain fog and fatigue.

I still prefer to use Julia, but this is a good summary of the problems that affect me personally as an experienced user (although I do like dynamic typing for most of the work I do).

Invenia's approach to interface testing ("Development with Interface Packages" on our blog) does some of the things you suggest as a standard of practice, by providing tools to check correctness that implementers can use as part of package tests. ChainRulesTestUtils.jl is a decent example (although this one doesn't come with fake test types). I think this is typically good enough, and only struggles with interface implementations with significant side effects.

One little win could be publishing interface tests like these for Base interfaces in the Test stdlib. I appreciate that the Generic* types are already exposed in the Test stdlib!

I don't know if it's related at all to the decline, but "Line Goes Up" was released on YouTube at the exact peak.

I've only ever engaged on Twitter when companies do not provide an avenue for direct customer support in private, but this has become more and more important over the years. Twitter provides a platform for public shaming; if the company directs you to a private channel and doesn't respond effectively there, you can report back publicly that the company has failed to respond. The situation may be changing, but in the past this has resulted in internal escalation and my problem was resolved in a way that was not possible through official private channels (if those even existed).

IMO the best way to avoid publicly advertising when you've failed a customer is to provide a clear and effective private avenue for complaint resolution. Most people who are looking for a resolution will only resort to social media complaints when they're desperate, either because they can't figure out how to get help or they are being denied help and/or communication.

I'm interested in the shift in terminology. Previous coverage has referred to them as a software company or device manufacturer, but this round is referring to them as "hackers", which seems like a framing McDonald's would benefit from in lawsuit proceedings.

I'd be interested to know what size of team the Core Team wants to maintain and whether there are differentiated roles within the team.

Yes, this suggestion effectively addresses the biggest problem with the flow described in the linked post. Accidentally clobbering changes in the main branch used to be one of the top sources of bugs when I started at my current job (incidentally, switching to a rebase workflow helped with this, though I'm sure that wasn't the only route we could have taken).

There are two statements here regarding things that have happened:

> the Core Team placing themselves unaccountable to anyone but themselves

> we have been unable to enforce the Rust Code of Conduct to the standards the community expects of us and to the standards we hold ourselves to

It's possible that there were CoC violations that they were not able to moderate, that the actions available to them were limited (e.g., they would have initiated a ban but they were not able to ban a core team member), that a core team member intervened to prevent effective moderation, or that the core team prevented the mod team from being able to access official core team channels in order to moderate.

Seems to be a wide variety of possibilities and leaving the nature of the situation ambiguous* will likely make it difficult for a new mod team. I hope the now-former mod team are open and direct with new or potential mod team members about the environment they're entering.

* I do think it's right for the mod team to not reveal the specifics in public; that would likely provoke targeted harassment and make the situation much worse