thelittlenag
First, since data centers likely need some kind of treated (i.e. demineralized) water, and they want to use local municipal supplies, then they can do so only if they pay full market rate for that water. I would push for them to pay 1% to 5% above market rate to help offset other costs, but market rate at minimum. At no point should homeowners and/or residential customers subsidize this usage.
Second, commercial users (including data centers) should only get water produced by treatment plants in excess of residential needs. Plants can only treat so much, pipes can only carry so much, and priority goes to residential first.
Third, ground water is off limits for any commercial/industrial evaporative cooling uses. If data centers want to cool that way, then they need a different source of water.
Did I miss anything?
This feels both like a good write-up, but an argument for why you often need to reach for multiple solutions when creating distributed system. Sure a fallback can have issues, but in the example given (website -> cache -> db) I can't help but feel that a circuit breaker pattern should also have been in play to catch other types of failures.
Distributed systems are dynamic systems and rarely will one type of solution or pattern cover the entire space of possible failures.
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: [email protected]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.
My team is building the next generation of technology to manage and enhance the on-device playback experience for users of Disney+ and more. This product controls and optimizes video playback millions of times per day.
We are looking for a senior engineer who has demonstrable Rust experience and expertise. Bonus points for experience with TypeScript, prior work on embedded systems, and/or familiarity with control systems.
This role offers the chance to drive a high-impact, customer-facing, needle-moving project. It is ideal for someone who is excited by the opportunity to demonstrate technical leadership, steward all aspects of a codebase, has a track record of technical excellence, wants to dive deep into the mechanics of streaming video, and thrives in a highly distributed and collaborative environment.
Apply here: https://jobs.disneycareers.com/job/san-francisco/senior-soft...
The hiring process is setup basically to filter for folks who they think are the most likely to publish lots of papers, collaborate to push existing lines of inquiry, write lots of hopefully approved grants, and grow a lab into what is effectively a "successful small business". Quality is an after thought taken care of by what passes for peer review.
The incentives for everyone involved is just a complete and total mess. I'm reading tea leaves here, but my guess as to why she was never hired is that she was deemed "unable to get grants". Had she been, then she would have found herself hired immediately somewhere because universities are incentivized to play a numbers game and get as many folks in writing grants as possible.