Location: Minneapolis, Minnesota, United States
    Remote: Yes (10+ years working remote) (or hybrid/on-site in Minneapolis or St Paul)
    Willing to relocate: No
    Technologies: Scala, Java, Typescript (Effect TS), Python, C/C++, PostgreSQL, AWS, HLS, Real-time ABR
    Resume: https://drive.google.com/file/d/19O9A3zMulkPWb61Ng9FsSZbCPHZms_Qy/view?usp=sharing
    Email: mark.kegel@gmail.com

But there are some obvious follow up questions that I do think need better answers:

Why is recovery made so hard in so many languages?

Error recovery really feels like an afterthought. Sometimes that's acceptable, what with "scripting" languages, but the poor ergonomics and design of recovery systems is just a baffling omission. We deserve better options for this type of control flow.

Also, why do so many languages make it so hard to enumerate the possible outcomes of a computation?

Java tried to ensure every method would have in its signature how it could either succeed or fail. That went so poorly we simply put everything under RuntimeException and gave up. Yet resilient production grade software still needs to know how things can fail, and which failures indicate a recoverable situation vs a process crash+restart.

Languages seem to want to treat all failures as categorically similar, yet they clearly are not. Recovery/retry, logging, and accumulation all appear in the code paths production code needs to express when errors occur.

Following programming language development the only major advancements I've noticed myself have been the push to put more of the outcomes into the values of a computation and then further use a type system to constrain those values. That has helped with the enumeration aspect, leaving exceptions to mainly just crash a system.

The other advancement has been in Algebraic Effects. I feel like this is the first real advancement I've observed. Yet this feature is decried as too academic and/or complex. Yes, error handling is complex and writing crappy software is easy.

Maybe AI will help us get past the crabs at the bottom of the bucket called error handling.

Their major complaint of the project approach is not getting signal on adaptability to new codebases. That has never been a first concern at any company I've worked at, and frankly if engineers are touching a new codebase every month then I'm getting a bit worried.

The goal here is to see if the candidate understands the domain (generic distributed systems) well enough on their own. For more senior roles I look to make sure they can then communicate that understanding to a team, and then drive consensus around some approach.

There is a subtle, but worthwhile, difference between "plausible" and "credible". Lots of stories are plausible. Few are credible.

In emotion laden cases like this we tend to want to believe stories we already agree with, or have some investment in. I'm no exception to that.

We need to not be misled by what is plausible, or confuse that with what is credible.

To your point about left and right, an interesting point I heard recently is that the left is coalition-driven whereas the right is consensus-driven (at least in US politics). Mapping this back to Haidt, one of his findings is that the left tends to greatly emphasize one or two of the "moral taste receptors", with the right having a roughly equal emphasis between them. It isn't clear to me how these two points might explain each other, but I do wonder if there isn't some self-reinforcement there. If there is, I wonder how/if that might explain political systems more widely.

Disney (Video Player Engineering) is seeking a Senior Software Engineer to help us deliver excellent streaming experiences for Hulu, Disney+ and ESPN+ as a developer of our client player. Our team is responsible for playback across several devices including gaming consoles, mobile devices and set top boxes. You will have the opportunity to lead in the design and implementation of our cross-platform C/C++ and Rust player that runs Disney+ and Hulu on these devices.

We’re looking for an experienced C/C++ or Rust engineer who has video player and cross platform development experience. You should have a passion for coding and debugging hard problems, and an eagerness to help us deliver seamless video to our subscribers. Being a Senior member, you will get to own large features, lead the technical direction of our work, and mentor and provide technical expertise to other engineers. You will work closely with other technical teams in the application layer and backend video services to deliver features.

https://www.disneycareers.com/en/job/seattle/sr-software-eng...

Feel free to DM me for more details.

Given that I've NEVER had what I would call a great interaction with a US border guard, it warms my heart to hear that at least they could be kind to some one ;-)

What I recently realized is that while compilers in the standard perspective process a language into an AST, do some transformations, and then output some kind of executable, from another perspective they are really no different than interpreters for a DSL.

There tends to be this big divide between what we call a compiler and what we call an interpreter. And we classify languages as being either interpreted or compiled.

But what I realized, as I'm sure many others have before me, is that that distinction is very thin.

What I mean is this: from a certain perspective a compiler is really just an interpreter for the meta language that encodes and hosts the compiled language. The meta-language directs the compiler, generally via statements, to synthesize blocks of code, create classes with particular shapes, and eventually write out certain files. These meta-languages don't support functions, or control flow, or variables, in fact they are entirely declarative languages. And yet they are the same as the normal language being compiled.

To a certain degree I think the biphasic model captures this distinction well. Our execution/compilation models for languages don't tend to capture and differentiate interpreter+script from os+compiled-binary very well. Or where they do they tend to make metaprogramming very difficult. I think finding a way to unify those notions will help languages if and when they add support for metaprogramming.