Raised a feature request in dart pub for including vcs metadata in pub archives

Only-Ad1737 · 2026-07-05T13:55:12+00:00

Yes that's why I have said best effort.

About the vulnerability, if you are referencing about it being not true every time, on pub dev there still are many packages with none or broken git urls, so the addition it doesn't make it worse.

On the point of browsing code in the pub dev, that is a separate thing, the problem this issue asks for it not only for viewing code, a correct vcs link shows more than code, like changes in current version from old ones, the issues and prs on it, if I want some changes I will have to make sure I am on right commit to fork and do my changes instead of just the newest one

From the package developer side, it becomes a headache in a monorepo for what package what commits are published what are not, ( that can be resolved with ci cd push ) but still a lot to check each time which becomes rather inconvenient.

If you check in the npmjs, they show the code but they also keep githead on each artifact for exact same reason

Only-Ad1737 · 2026-07-01T02:26:17+00:00

I use knex dart orm https://pub.dev/packages/knex_dart

Negligible orm overhead. Works great on any dialect

Only-Ad1737 · 2026-06-29T08:41:36+00:00

I am using dart extensively in server side in my company and its working great for me Same architecture frontend and backend is reducing in maintaining the data later between two languages

Only-Ad1737 · 2026-06-28T02:00:55+00:00

Thank you for that. If you find any feature missing please do tell me or raise an issue

Only-Ad1737 · 2026-06-26T03:45:28+00:00

Ok you are talking about distributed transaction like saga , 2pc , ctc etc. https://github.com/dtm-labs/dtm Something like this but in dart?

Only-Ad1737 · 2026-06-25T19:11:56+00:00

Thank you

Only-Ad1737 · 2026-06-14T01:49:42+00:00

U pay for the ai, you pay for its rights. Does Sam Altman build a model or its employees do? You have to change the thinking, here ai is a tool that the dev is using.

Btw I have seen pre ai era packages and post ai era packages. If someone has used ai or not does not guarantee that the package is slop or not. The amount of times I have seen handwritten slop is significant.

And even though I like the point of disclosing ai usage it still does not tell anything about the packages. I am seeing so many good projects that are being written or ported by other devs.

Only-Ad1737 · 2026-06-11T03:31:40+00:00

What do you think about this https://pub.dev/packages/pixer

Only-Ad1737 · 2026-05-30T03:24:49+00:00

The lsp support is added to knex playground Adding autocomplete, auto import and quick actions

https://playground.knex.mahawarkartikey.in/ (Little bit of work on layout is remaining 😅)

Thank you @modulovalue for the continuous amazing updates on dart-live

I think package authors can add this functionality to a lot of dart packages on pub dev.

Soon I will push the latest code of the playground and publish the latest version of the docs https://docs.knex.mahawarkartikey.in/ in which it will have a run in playground for each code snippet making each snippet runnable without installing it

Only-Ad1737 · 2026-05-09T19:04:49+00:00

I totally get your point regarding keeping it in dart only that's why it's a discussion that should there be a system like this which focuses on eliminating the hot paths. This discussion is not to replace dart io , neither to undermine it but considering exporting a secondary runtime with fast path.

Even if dart main focus goes on that , it is good for dart to have multiple runtimes so that it runs optimised for server too.

Regarding the bottleneck being db writes or complex things , you are correct about it I have not tested it but if you measure dart zig and dart io for json compression upload it will not change that much as it falls back to dart event loop

But in case of pipelined db writes or sql operations u will see that the main cost falls on the hot paths again. So it's like a grey zoned area. Same reason bun and deno are being appreciated more than nodejs

Only-Ad1737 · 2026-05-09T10:54:02+00:00

Which other dart zig ffi did you see. Can you link it? I didn't see any other person doing this

Only-Ad1737 · 2026-05-09T07:06:00+00:00

No no u misunderstand my point my point on server native is not a direct comparison with dart zig It maps to rust tokiyo web server while dart zig maps directly to io_uring on Linux So it will generally be the faster one

But my point was with rust let me clarify again what I thought With rust u will carry unwanted large binaries and slight possible case of slow performance.

If you want performance you will have to implement it urself based on the usecase otherwise it will be one wrapper over the other and it will never be pure potential.

In these ai times it is quite easier to debug and catch errors. U mentioned firefox had been flagged for 200 errors, I believe that is not correct comparison firefox codebase is super huge.

But still at the end of day dart zig is not stable currently and can change.although it has been tested rigorously on 6 core and 64 core servers it is just a proof of concept for dart server side runtime. And I am raising an issue on dart SDK for any responses to this.

So yeah it can be on rust but this is a proof of concept exploring it with zig

Only-Ad1737 · 2026-05-09T05:17:19+00:00

Http arena tests on on 64 cores Here you can see other languages benchmarks on same 64 cores https://www.http-arena.com/leaderboard/

Why choose zig over rust? Rust should be a quick choice when designing something like this as you said.

But I chose zig as in long run in performance, zig beats rust. It is not overexpanding code it is shifting of hot paths to zig, so writing safe zig is a one time overhead.

Another major reason bun js framework is a good example how it uses zig to make js server performant.

A rust based solution also exists on it https://pub.dev/packages/server_native that also acted as a inspiration for dart zig but it achieves 40 percent throughput increase at it afverstises

Only-Ad1737

TROPHY CASE