loic-sharma

You might want to try Dart. It is simple, has great tooling, and compiles to native code.

Disclaimer: I work on Flutter at Google.

FWIW, the NuGet package format and the v3 server protocol are fairly simple and well documented.

If you import all packages on nuget.org? You’re likely looking at terabytes of data.

The import tooling can be used to migrate off another NuGet server implementation.

This project helps but isn’t enough alone:

1. Dart can’t cross-compile from Linux to iOS yet. You could use Dart’s interpreter instead, but that’d significantly regress performance.

2. Flutter iOS projects use the Xcode project format, you’d need to migrate that to xtool’s project format

3. Flutter hasn’t finished migrating its plugin ecosystem from CocoaPods to SwiftPM - any plugin that hasn’t migrated to SwiftPM yet likely won’t work with xtool.

> While the editor component is based off Monaco, the IDE is not a vscode fork and was written from scratch.

Interesting! What are the trade-offs here?

Your browser goes through extraordinary lengths to support this sort of thing.

Flutter Linux targets GTK3 and is currently investigating a GTK4 migration. Flutter also supports Windows and macOS.

This is incorrect. It was their query engine that was hard to optimize, not the language. InfluxDB has been working on a new query engine based off Apache DataFusion to fix this.

If you squint, this query language is very similar to Polars, which is state-of-the-art for performance. I expect Pql could be as performant with sufficient investment.

The real problem is that creating a new query language is a ton of work. You need to create tooling, language servers, integrate with notebooks, etc… If you use SQL you get all of this for free.

Skia relies heavily on runtime shader compilation, which is slow and causes frame jank but improves peak performance. Skia also supports much older devices than Flutter does.

There’s no free lunch, Impeller has a different set of trade offs that are a better fit for Flutter.

> Spammers just try to find something that ranks high in SEO and costs them nothing, if repository stops being that most will leave.

This is not true. Spammers will continue trying even if you are very good about removing spam packages. Source: worked on a package manager for 5 years.

> Most other package repositories don't have that problem to such degree

They do, you’re just not seeing it because they’re actively removing packages. That said, NPM is the largest package ecosystem and likely receives the most spam.

> Users will do the flagging for that so at least you won't have too many valid packages to verify

The trick is to have detection that’s accurate enough that you feel confident removing packages without human intervention.

Package managers have likely already built lots of tooling to detect potential spam and then bulk remove them. That’s how they manage thousands of spam removals per week in a reasonable amount of time. Nonetheless, human verification is necessary due to the “left pad problem”. This takes time due to the sheer quantity of spam.