anowell

Thanks for the heads up. Will think on this and will probably just document the polyfill.

Good catch. Will get that added today.

github.com/howie-code/temporal-fun

Agreed. We've almost eradicated our usage of JS Date - fixing plenty of bugs along the way, and then I extracted thousands of lines of conversions and formatting from our production app (scheduling focused) into a temporal-fun package to make it Temporal more ergonomic for lots of common cases.

npmjs.com/package/temporal-fun

    Location: Seattle
    Remote: yes, but not necessary
    Willing to relocate: no
    Technologies: DevOps,  Kubernetes, Rust, Ruby, Typescript, Svelte, VueJS
    Résumé/CV: https://anowell.com/portfolio
    Email: anowell (at) gmail

Part-time only!

I'm bootstrapping a new business (a makerspace), but would love to complement it with a part-time role. 13 years of experience loving both IC and director type roles. Scaffolding/architecting new distributed system components, cloud operations, developer experience tooling, and mentoring have always been front and center for me, but I'm fairly versatile, even loving documentation and process development. Best fit is probably a role where I can help get something off the ground and mentor someone more junior to take ownership of it.

I'd take a pretty steep discount from my historical rates for the right part-time role and schedule flexibility.

This is roughly my story with the added note that I find that Github activity inversely correlates to how much Netflix I watch. I currently average about 3hrs /wk of TV time and probably about 15hrs/wk on personal projects.

(of course, I don't mean to undermine the argument for hesitating to jump to Arch on the grounds of maintenance. It certainly takes thinking about maintenance more often.)

fwiw, I find the long term support pretty minimal. I'm only slightly more conservative in my use of`pacman -Syu` than I would be with `apt-get dist-upgrade`. If I notice a kernel or DE upgrade, I might hold off until the weekend on the off-chance that it needs a bit of extra maintenance. I appreciate handling these changes in smaller batches, as opposed to the 6-month system-wide major upgrade cadence. Of course, if I was just jumping between LTS releases, maybe only dealing with serious maintenance every other year would be an appealing trade-off.

In addition to the other responses, the ecosystems around Rust ML (e.g. scientific computing) are still very early and the Rust ML community itself is still fairly small. Take a peek at arewelearningyet.com

This is solid. I'm an engineer at Algorithmia, and this caught our attention as the sort of project we love to host as a service on our algorithm marketplace. We've already made note of it for our team to consider adding (thanks to the generous MIT license), but I wanted to reach out in case you'd rather add, own, and optionally monetize it on our platform yourself. Either way, this was a great read with impressive results.

It would seem that your desire for a divine book is one that centers on human advancement and academic knowledge. If God's highest desire was for our self-advancement, perhaps the bible might look more like what you described.

Speaking strictly of infrastructure costs, stripping away any other value of our marketplace and platform, ignoring an on-premise deployment of our platform that uses your own AWS instances, and given a sustained workload that saturates system resources for the lifetime of your instance(s): yes.

For workloads where you aren't making full use of system resources at all times, then the economy of scale provided by our compute cluster often results in compute-per-second being more cost effective even before considering the costs of managing your own infrastructure. It fits into the "serverless" trend, FWIW.

Each algorithm in our marketplace has a cost calculator that breaks down the price using a per-API-call estimate. If you have a specific workload in mind, feel free to reach out and we'd be happy to further discuss the pricing.