Maven / Java seem to have solved it well.

I was developing in Java right up until Maven became popular. We used to just download jars. What would you say is the main difference with Maven/Java vs NPM?

My recollection is that Java libraries were larger, higher-quality, more stable, and better-maintained, and you didn't need as many of them. A Java jar was not a "package" but contained dozens of "packages" developed together. Jars tended to be self-contained or mostly self-contained; small dependencies would shipped inside. The idea of making npm packages as small as possible, like practically putting each file in a separate git repo, and publishing it as a separate artifact, emerged shortly after NPM itself, and it was radical, and not really particularly good. Java also has a much larger standard library, and between the packages that come with Java itself, the packages that aren't technically part of the standard library but were written by Sun/Oracle, and well-known third-party utilities, you didn't need a lot of third-party packages. And if you needed something tiny like left-pad and didn't have it, you'd probably just copy and paste it.

> What would you say is the main difference with Maven/Java vs NPM?

Maven doesn't allow execution of arbitrary code at install-time, which curbs a large number of potential supply-chain attacks.

Because of the JVM and JARs being mostly self-contained Maven doesn't really need to worry about system or runtime dependencies (unless you're using Scala...). This allows Maven to be a 'dumb' package manager that relies on simple semantics (no hidden specially-generated indices, for example) and be fairly successful. Of course, there's an internal battle of whether Gradle or Maven is superior, but they both rely on the same distribution and packaging specifications.

Maven doesn't have this problem because maven central is too obtuse for hackers to use, and Enterprise Java developers don't ever update their dependencies. It's actually to their benefit, but it's for the wrong reasons.

> Maven doesn't have this problem because maven central is too obtuse for hackers to use

I have many gripes with Sonatype but Maven Central isn't really one of them. The fact you can publish a packages to the likes of PyPI, npm Registry, or Docker Hub with 0 friction makes those places very attractive to spammers and bad actors. Maven Central having a higher barrier of entry is a feature.

IIRC Brian Fox, the CTO of Sonatype, was actively involved with Maven in the early days and was part of the decision for Maven packages to use domains for namespaces. Namespaces are another valuable feature of Maven that makes supply-chain attacks like typo-squatting harder to pull off.

The real reason was the second one. That was just a cheap dig at their UX. Both were cheap digs, but also both true.

Lol, I knew you were mostly joking — but you also weren't wrong.

At the same time, some people genuinely shit on Maven Central and think that it's inferior to other registries.

There's a real problem with maven central and java in general that there's no correlation between the package name - which is nicely domain-name formatted - and actual domain names. If there were a clear "this is really thai domain name and DNS verified" and "this is compatible but not DNS verified" marker, it would be great.

I think golang has the best answer for this, where it's easy to impersonate but it has to be explicit.

Yeah, it's far from perfect but it does get a lot right. It's painful watching all these new package management tools like pip and npm completely ignore what came before them.

I think Go's approach is interesting, though it does rely on some magic that isn't immediately obvious. I agree that being explicit is a tremendous benefit: it avoids the attack used here, and makes it less likely for typo-squatting to succeed (e.g., `npm install axiod`).

Publishing to Maven Central is a bit of a pain, but the manual effort, doc jars, signed jars, etc. help with security and keep away low-effort packages.

Also, a pretty sophisticated way to manage transitive dependencies. Python is an absolute mess in this regard (as well as pretty much everything else with dependency management…)

My app update was rejected because my Upgrade screen was unable to fetch prices from their servers and instead showed an infinite spinner.

Would an infinite spinner also show up if the server was up but the connection was problematic? If yes, this would be about not handling network errors, which sounds like a decent rejection reason to me.

'Cancel culture' is a political thing and against the guidelines, since it could create flame wars and unwanted discussions that are rarely useful: https://news.ycombinator.com/newsguidelines.html

So it's more about the related topic than the webapp itselve. It's always been that way fyi

The red X is a vote to cancel and the green check is a vote not to cancel.

Who is voting? Nothing is clickable on Firefox...

Damn you got downvoted real quick.

Some of your questions aren't easy to answer. Maybe the first two were OK to ask. Others would probably require lawyers and maybe even courts to decide. This is a pretty cool new product just being shared on an online discussion forum. If you are serious about using it for a company, talk to your lawyers, get in touch with Github's people, and maybe hash out these very specific details on the side. Your comment came off as super negative to me.

> This is a pretty cool new product just being shared on an online discussion forum.

This is not one lone developer with a passion promoting their cool side-project. It's GitHub, which is an established brand and therefore already has a leg up, promoting their new project for active use.

I think in this case, it's very relevant to post these kinds of questions here, since other people will very probably have similar questions.

I think these are very important questions.

The commenter isn't interrogating some indy programmer. This is a product of a subsidiary of Microsoft, who I guarantee has already had a lawyer, or several, consider these questions.

No, they are all entirely reasonable questions. Yeah, they might require lawyers to answer - tough shit. Understanding the legal landscape that ones' product lives in is part of a company's responsibility.

Regardless of tone, I thought it was chock full of great questions that raised all kinds of important issues, and I’m really curious to hear the answers.

Definitely understand where you’re coming from, I think you're looking this through the lens of the way these types of programs have worked in the past.

With us, these are always your customers, we're just allowing you to launch your own capital program for them. We aren't having you "send us prospects." Instead, we're providing you the infrastructure so you can get them funded them on your platform. We keep them in your product and ecosystem, and your users never need to know who Lendflow is (if you wouldn't like them to).

We provide a lot as part of the program, including the technology, customer support and onboarding, dedicated phone lines and email integration, and the go to market sales and marketing collateral.We also provide the data and analytics for your program, so you can better run your service with us over time.

There are a lot of costs associated with these services, so the subscription keeps our incentives aligned with our platform partners and the small businesses we’re serving together.

Not sure I understand this. When someone chooses to factor with "me" (Lendflow under the hood) is it me making the factoring revenue or you?

That would be one way to model such a service, but certainly not the only way. Their pricing optimizes for a particular customer profile, and that may not be you.

I never understood that Google security blog post on how they could make 2 different PDFs with different content have the same SHA but now that you mention you can stuff bytes in a file unrelated to the PDF, it makes sense...

I'm ready for the downvotes but I don't think the App Store cut is crazy. They do reduce to 15% if you have long-running subscriptions with your user. Credit cards charge 3% to start. Apple handles distribution, updates, etc. Taking 15% at the end of the day isn't terrible. And hey, they made the super shiny beloved iOS platform too in the first place, not to mention the SDK that makes the apps even possible to build!

DHH is just trying to ride cancel culture to get enough people to tweet / complain towards Apple in hopes that they cave.

Not really the same comparison. That human will eventually be able to take care of itself and do a lot more for this world than the dog ever will. Pets don't always make sense, and I tend to agree with parent.

Or maybe Wag should just connect you one-time with someone reliable in your area. It seems stupid to have strangers all the time with your dog. As the top comment mentioned, people used to just get someone reliable nearby, but the tech has eliminated the need for social interaction and communication.

So don't own a dog unless you can take them for a walk every day without fail for the next 15 years without using a dog sitter / walker.