Why is crypto.subtle.digest designed to return a promise?

Every other system I've ever worked with has the signature hash(bytes) => bytes, yet whatever committee designed the Subtle Crypto API decided that the browser version should return a promise. Why? I've looked around but I've never found any discussion on the motivation behind that.

Not sure if this is the right community, but I didn't see a general one. What search engine do you use? Besides Google increasingly spying on its users, the quality of its search results seems to have gotten significantly worse over the last decade. What search engine(s) do you use?

I have a subscription to Nature but most of the articles are totally beyond me. I’m thinking of switching to a comp-sci specific journal. I’m mainly interested in compiler design and implementation of JIT compilers and VMs like JVM and .NET.

I am a self-taught programmer and I do not have imposter syndrome. I have a degree in electrical engineering and when I thought that was going to be my career I did have imposter syndrome, so I'm not immune. I wonder if there's a correlation. It seems that many if not most professionals suffer from imposter syndrome; I wonder if that's related to the way they learned.

When I say self-taught, I don't mean I never took a class, I mean the majority of my programming skill was learned by doing/outside of classes. I took a Java class in high school that helped me graduate from procedural languages to OOP, and I took classes in college but with few exceptions the ones that were practical (vs theoretical) covered material I already knew.

My last job was at a company that designed and built satellites to order. There was a well defined process for this, and systems engineers were a big part of it. Maybe my experience there is distorting my perspective, but it seems to me that any sufficiently complex project needs to include systems engineering, even if the person doing that is not called a systems engineer. Yet as far as I can tell, it isn't really a thing in the software industry. When I look at job postings and "about us" blog posts about how a company operates, I don't see systems engineering mentioned. Am I just not seeing it, is it called something else, or is the majority of the industry somehow operating without it?

I am working on an application that has SDKs in multiple languages. Currently Java, JavaScript, Dart, and Go, but ultimately we'd like to have an SDK for every major language. Our primary test suites are written in Go, which means our other SDKs are not well tested. I do not want to write or maintain test suites in four or ten different languages.

What I would like to do is choose a language to write the tests in, define a test harness interface, implement that test harness for each SDK, and write the tests using that harness. Of course I could do this with RPC/HTTP/etc but that would add significant complexity. I'd prefer to write the tests in a language that has a meaningful degree of interop/FFI with most of the major languages. Lua comes to mind, since it seems like someone has built a Lua interpreter for basically every language in existence, but I have very little Lua experience and I have no idea how painful it might be to do this in Lua. I am open to other suggestions besides interop/FFI and RPC, though I don't want to take the approach of creating test templates and generating the tests in each language. I've done things like that and they're a pain to maintain.

I am not hating on Rust. I am honestly looking for reasons why I should learn and use Rust. Currently, I am a Go developer. I haven’t touched any other language for years, except JavaScript for occasional front end work and other languages for OSS contributions.

After working with almost every mainstream language over the years and flitting between them on a whim, I have fallen in love with Go. It feels like ‘home’ to me - it’s comfortable and I enjoy working with it and I have little motivation to use anything else. I rage every time I get stuck working with JavaScript because dependency management is pure hell when dealing with the intersection of packages and browsers - by contrast, dependency management is a breeze with Go modules. I’ll grant that it can suck when using private packages, but I everything I work on is open.

Rust is intriguing. Controlling the lifecycle of variables in detail appeals to me. I don’t mind garbage collectors but Rust’s approach seems far more elegant. The main issue for me is the syntax, specifically generic types, traits, and lifetimes. It looks just about as bad as C++'s template system, minus the latter’s awful compiler errors. After working almost exclusively with Go for years, reading it seems unnecessarily demanding. And IMO the only thing more important than readability is whether it works.

Why should I learn and use rust?

P.S.: I don’t care about political stuff like “Because Google sucks”. I see no evidence that Google is controlling the project. And I’m not interested in “Because Go sucks” opinions - it should be obvious that I disagree.

I am an experienced developer, but not an experienced manager. I'd prefer if organizing tasks was not my responsibility, but I work at a small company and no one else is inclined to do it. How do you organize miscellaneous tasks when using a task management system such as Jira? We're using GitLab, but it has the same basic features, such as epics, milestones, tasks, and subtasks.

I don't want to have miscellaneous tasks floating around in the ether, because things like that tend to get lost. But an epic is supposed to have a well-defined end goal, right? A good epic is something like "Implement this complex feature" or "Reach this level of maturity" - not "Miscellaneous stuff".

The majority of the work we do fits fairly clearly into specific goals, such as "Release the next version of feature." But what about bug fixes and other random improvements and miscellaneous tasks? How do you keep those organized?