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.

I am excited to write some Rust in the browser, and have been tinkering with what it might look to have a rust frontend framework with ergonomics comparable to what you might expect in other high level languages. (https://anowell.github.io/quasar/)

That said, I agree that more people will want to work in higher level languages, though I kinda suspect "most" are going to still prefer Javascript for the forseeable future - so I sorta see JS compiling to WASM as inevitable.

I've been wondering this myself, so thanks for the link. Looks like it lives under the label: "Proposals we might consider in the future".

I've been building a [super early/experimental] rust frontend framework (https://github.com/anowell/quasar), and going through Javascript to manipulate the DOM is the cause of plenty of frustrations and limitations, so I'll be keeping an eye on this.

(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.

You might checkout the literal optimizations that ripgrep does. IIRC, the underlying regex lib is optimizing a few classes of "simple" regexes with SIMD to achieve better perf than the first handwritten code in that article.

http://blog.burntsushi.net/ripgrep/#literal-optimizations

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.

The service operates at a higher level than EC2, and pricing is calculated on a per-second of compute basis. Comparing prices is going to depend a lot on the specifics of your workload and your affinity for managing infrastructure.

While I also generally prefer to choose open source services over closed source ones, it seems to me there is a place for both....

That said, over 75% of algorithms on the site are open source. Perhaps that's not obvious enough?

[disclaimer: I'm an engineer at Algorithmia]

[As one of the developers in charge of this feature...]

That's a fair question.

Rust was a personal itch, but it also provided a good test for supporting native compilation while providing an excellent dependency management story. We learned a lot from Rust that will apply to C/C++ and we're talking about how we want to address the dependency management story of that ecosystem (and we still need to build a C/C++ client library).

Scala support came alongside Java (and because we're a Scala shop). Ruby was low-hanging fruit because the client already existed. Coffeescript support would be pretty easy to add on top of Javascript pending some demand and interest. C# (on mono) and Go are both interesting languages for us to reasonably land that didn't make this round.

We definitely have more to announce on this front soon. And by all means, we love hearing our users request their favorite languages. :-)

It's a few years old at this point, but the 2013 Velocity talk "there is no talent shortage" is still one of my favorite resources on the topic: https://youtu.be/P_sWGl7MzhU

I spent an hour fighting with the Airport utility in WINE a couple months ago. It launched, but I had issues discoving the Airport. Eventually I caved and had a non-technical friend with a Macbook configure my router for me. </shame>

That would be me. Someone alerted me to the "30% worse than java" benchmark results, so I did some experimenting. It was my first attempt to optimize a bit of Rust, so I would love any feedback.

There's a lot of hate for whiteboard coding. Having been on both sides of whiteboard, code reading, and code pairing interviews, I like them all for different reasons:

Code reading: In <10 minutes, I can have a basic grasp on someone's ability to read, understand, and explain new code. Usually simple examples of <50 LOC in the language of there choice. I've used it a lot in phone screens (just providing URL to the code) and gained the reputation of being able to predict fairly well the quality of a code submission to a "take-home coding challenge".

Whiteboard: in ~15-20 min I can get a grasp on how someone takes a vague problem and works toward a solution and how they are to work with. I'm actually less concerned about code, and more about how they handle ambiguity, flesh out requirements, communicate issues, and think holistically without the distraction of a compiler/syntax-highlighter/etc. I think whiteboarding is slightly more about communication than coding and can provide a lot of context in a short amount of time. Of course, not all whiteboarding interviews are equal - I spent plenty of days complaining about certain whiteboarding interviews, and now I'm clearly biased to believe that mine take the good and leave behind [most of] the bad.

Code pairing. Takes ~1hr to understand and modify some piece of code in a meaninful way. (Maybe there are simpler versions - but in an effort to feel more "realistic", I've always focused on changing a requirement to the candidate's code submission). It's more realistic than whiteboarding, but it carries the [real-world] overhead of getting syntax right, finding docs for a specific function, and other surpries that come up (network issues, desktop crashes, editor problems, etc.). I've seen it work well when there are several interviews that focus on very different skills, but inevitbaly after such interview, I've often felt like I had a very narrow view of a candidate.

Great question. We currently only allow GPL-licensed algorithms to be open source as we continue to evaluate the best way to promote the virality of OSS licenses in compliance with license. However, some licenses (like AGPL) as simply too restrictive for us to support on the Algorithmia platform at this time.

While infrastructure usage cost is measured per second, algorithm developers currently set royalty costs per API call, so there is no incentive for stalling. We also provide a breakdown of your usage by algorithm to help you identify long-running algorithms.

You have effectively described the AGPL restrictions that explain why we do not currently accept algorithms licensed under AGPL.