deno_std VS windmill

For reference (for the issues you mentioned): 1. This issue was opened almost immediately to solve the weird .only function not working https://github.com/denoland/deno_std/issues/2979 2. That looks weird to me, will get back to you on this one since it should work I think 3. Generally polluting the global namespace isn't great, but because we're only polluting the namespace of a module (and we choose what parts to import), I personally find it quite freeing. I entirely understand how that might feel awkward. 4. you CAN specifying only writing to certain directories! --allow-write=/path/to/dir would allow that!

At least for the ones related to trees, it's just a renaming. Below is a link to the PR. When I initially implemented these trees, I chose the names BSTree and RBTree to keep the names short. I'm guessing the person that proposed renaming them did so to make it more obvious what they are.

https://github.com/denoland/deno_std/pull/2400

The standard library is separate from the runtime. It wouldn't break backward compatibility if you were to update. For example, if you were importing RBTree and upgraded Deno to the latest release, it would keep working just fine. You would only really need to switch to using RedBlackTree instead if there was a change made to it that you wanted.

I think the only time you would need to update your standard module imports to be able to use newer versions of the Deno runtime if the standard module were depending on runtime APIs that have a breaking change.

It is like Demo deprecating fs.exists().[1]

[1]https://github.com/denoland/deno_std/discussions/2102

This was fun to read through.

I would need to profile the code, but the startup time being bad for Deno seems like maybe a combination of the code in here being unoptimized:

https://github.com/denoland/deno_std/blob/0ce558fec1a1beeda3...

(Ex. Lots of temporaries)

And usage of the readFileSync+TextDecoder API instead of readTextFile (which is also a docs issue since it's suggests the first one). It seems the code loads the 100MB into memory, then converts to another 100MB of utf8, then parses with that inefficient csv decoder. The rust and go versions look to be doing stream/incremental processing instead.

But it there's some talk to reconsider it

Sorry to hear that. I want to provide expect API in deno_std in the future: https://github.com/denoland/deno_std/issues/1779

I just migrated the module to Deno and rewrote the test cases using the Deno test runner. Also contributed a bug fix to the test runner that I encountered during the migration. An npm version is still available and automatically generated from the Deno code via a small bash script (rewriting imports, adding an index.ts, etc.).

Much of Node.js is written in C, yet it's still called Node.js.

Deno has some JavaScript/TypeScript in it. On GitHub https://github.com/denoland/deno is 22.8% JavaScript and 13.2% TypeScript, and https://github.com/denoland/deno_std is 68.2% JavaScript and 31.6% TypeScript.

So to me it's misleading about the name, but not about what Deno is written in.

Look very similar to the script builder portion of https://github.com/windmill-labs/windmill, but not open-source, not self-hostable, and without open-source integrations (https://hub.windmill.dev/)

disclaimer: I'm founder of ^

If you need a job queue on Postgres, https://windmill.dev provide an all-integrated developer platform with a Pg queue at its core that support jobs defined in python/typescript/sql

windmill.dev - Windmill is an open-source developer platform to quickly build production-grade multi-step automation and internal apps from minimal Python and Typescript scripts. As a free user, you can create and be a member of at most three non-premium workspaces.

For an alternative to airplane.dev, you can checkout Windmill.

https://github.com/windmill-labs/windmill

"Open-source developer infrastructure for internal tools (APIs, background jobs, workflows and UIs). Self-hostable alternative to Airplane, Pipedream, Superblocks and a simplified Temporal with autogenerated UIsm and custom UIs to trigger workflows and scripts as internal apps.

Scripts are turned into sharable UIs automatically, and can be composed together into flows or used into richer apps built with low-code. Supported script languages supported are: Python, TypeScript, Go, Bash, SQL, and GraphQL. "

If you search HN, you'll find the creator of Windmill comment on comparisons to airplane.dev:

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

https://windmill.dev is a self-hostable OSS alternative to pipedream

(disclaimer: I'm founder)

I'm genuinely curious what server-side stuff on BC you are referring to. That may have been something added after our assessment. The way I'd generally approach something like that for any of the platforms would be using an external low/no code solution to process webhook data. But it would depend heavily on the use case. For a more developer friendly option I've been really impressed by windmill.dev. We use a mix of n8n and windmill for various needs.

Yes it goes in that direction, however note that you can already do this in a not too hard way.

Our openflow spec is both open-source and has a full openapi definition: https://github.com/windmill-labs/windmill/blob/main/openflow...

you can use that to generate client sdks in any languages and build your own dag with it. That's what one of our customer did building a reactflow to openflow library: https://github.com/Devessier/reactflow-to-windmill

It's not as good as the decorator way but we move fast and if you still have interest for it we could prioritize it (and ask for feedbacks :))

We have built an open-source generic workflow engine to run arbitrary scripts (https://windmill.dev) with a vscode extension to build the yaml using a low-code builder and each individual script in their dedicated python/ts files so you get your full editor assistants https://youtu.be/aSOF6AzyDr8?t=116

One of the area we are expanding next is a github app so you get exactly the same UX as github actions but running windmill workflows on your windmill workers.