The policies around blanket ambiguity for rejections is to avoid any kind of messaging that could lead to potential legal retaliation. Frustrating, absolutely, but most employers just aren't willing to flirt with the risk.
I've landed on a similar hot take after one job offer got rescinded by a company that refused to give a reason, to anyone involved, and then wouldn't honor records requests. (But would send me a candidate survey.)
With any job, it would be one thing if it were at the applicant stage, and I hadn't talked to a person at any point. But with this one, there was an offer in front of me and there was no one at all who had both the capacity and the willingness to explain what had just happened.
If I started the job and they pulled this on day three, they would have to give a reason to an unemployment office.
I don't care how little inclination businesses have to tell the truth. Make them commit to the lie, in writing, somewhere that it actually costs something.
Also a lot of companies don't want to close off the option. It is amazing how you occasionally hear back long afterwards after they fail to hire the applicants that they wanted more than you.
As a kid I didn't get carsick at all. I could work on my laptop, read, whatever while my parents drove. As an adult, at some point I started to barely be able to do anything but keep my eyes on the road without feeling bad.
Turned these on recently, and they work bizarrely well...unfortunately. Downside is that I feel like I lost an excuse to avoid devices for a few minutes while traveling.
I had a few years (from 9-12, maybe) where I became carsick very easily, otherwise it hasn't been an issue for me*. In that same time period, I was extremely sensitive to the harsh florescent lights in my classroom, and had to read through a coloured plastic sheet and try my best to cover everything in shadow.
Remembering things like that makes you really thankful when they've just went away. Things do sometimes get better through for no clear reason!
* Except "simulation sickness" from certain 3D games like Minecraft.
I'm not sure if this is sarcasm, but I've been blown away by the thoughtful responses I've gotten from dang. They don't always come quickly, but I would expect that given how crazy I assume that inbox is.
I suspect the emails are triaged quickly and there is a low-priority bucket which may or may not ever get a reply. In my experience if there is a clear call to action and addressing the issue will have any sort of meaningful impact, it's unusual to not get a reply.
The product looks great and I'm really interested in trying it out. Very cool, congrats on shipping! Also...as a parent of young kids: this name made me laugh out loud. The OG image on the marketing site is a fun easter egg.
The new owner's plan is...to sunset the paid product immediately and give customers access to tooling to be able to continue generating SDKs on their own. From Stainless's post:
As we focus on Claude Platform capabilities and connecting agents to APIs, we’ll be winding down all hosted Stainless products, including our SDK generator. Starting today, new signups, projects, and SDKs will not be available.
If you’re a Stainless customer, visit app.stainless.com/transition for help transitioning from Stainless-managed products to other options. As always, you own the SDKs you’ve generated to date, and have full rights to modify and extend them however you wish.
As a customer, all-in-all, we were pretty pleased with the outcome. Stainless was a great partner to us, even in "the end," and I'm really happy for the team.
MoQ is “Media over QUIC,” although I suspect it’ll eventually go the npm path and just end up being MoQ means MoQ.
Depending on the use case you could think of it as an alternative to WebRTC with lower level control, but honestly it’s a lot more open ended than that.
That framing helps. When people compare MoQ with WebRTC, is the main attraction lower-level control over transport/media semantics, or are there cases where MoQ is expected to be materially better for latency or reliability?
I’m trying to understand whether it’s mainly a replacement for specific WebRTC use cases, or more of a building block for new kinds of real-time systems.
There's a few cases where WebRTC falls apart that I think MoQ could help with.
It doesn't work so well for having a low-latency broadcast. Your choices right now are - use WebRTC and deploy selective forwarding units, which are going to be something custom, and likely involve spinning up a bunch of geographically-distributed virtual machines, figuring out signalling and whatnot. Or - use HLS so you can use more standard HTTP CDN tech, but you gain orders of magnitude of latency.
MoQ should allow for a standardized CDN stack, meaning we should be able to have a more abstract service (instead of spinning up VMs, you just employ some company's CDN service and tell it where to get media from).
There's a lot of other little issues with WebRTC for certain, specific applications. Like - last I tried it, browsers will subtly speed up audio/video to keep everything in sync, and you can have scenarios where you'd rather just let the viewer fall behind a bit and skip ahead later (say you're listening to music, speeding it up isn't ideal).
Or - say you want to have a group call and capture each participant's audio individually and edit it together later for something like a podcast. It's been a while since I've tried this, but I recall it being pretty difficult to do that with WebRTC. I remember all the mixing would happen in the browser's libwebrtc and I had really limited control over things.
> use WebRTC and deploy selective forwarding units, which are going to be something custom
Would you mind explaining more? If you are doing WHIP/WHEP you should be able to drop in Broadcast Box/MediaMTX etc... and switch out servers and no one should notice. You can use browser/mobile/ffmpeg/OBS etc... get the same behavior. I care a lot about the broadcast space, want to learn about other problems.
> subtly speed up audio/video to keep everything in sync
Regarding SFUs - with something like HLS, I can really easily scale up using something like a caching CDN (not entirely sure if that's the right term). But the idea goes: I can distribute the HLS media playlist, and have my media segment entries prefixed with a caching/CDN service. The service will be configured with the actual origin server, and when a segment isn't in the CDN, the CDN fetches from the origin, on-demand. That was a nice option when I was doing owncast streaming since I really only paid based on viewership, and just had to make sure I had the correct cache-related headers on my media segments.
Or alternatively - I can push media segments up to a CDN and distribute that way, using an s3-compatible service, or just rsyncing to a server with better bandwidth, etc. One thing I didn't care for - again back when I was broadcasting with Owncast - was that I needed to make sure old media segments were expired, otherwise I would rack up an insane bill. I had a 24/7 owncast stream and if you're not on top of expiring media segments with your CDN, it gets expensive fast.
The overall idea is - serving HLS is ultimately serving files and there's a good amount of tooling for that, right.
Now that you mention it, I think WHIP/WHEP can solve some of that. I just don't know of any service where I can have that same cache/CDN-like experience, of either having the CDN connect to the origin as needed and fan-out, or where I can push up and let the service distribute. (though - now I'm googling for "webrtc sfu as a service" and see that is a thing!).
Didn't know about the playout delay extension.
Whether capturing individual audio is easier with RtpTransport or insertable streams - I'm unsure. Possibly? I just figure since MoQ is going to rely on things like WebCodec/WebAudio there's hopefully a bit more control over what happens with audio as it comes in.
I'll admit though - I've started noticing how often podcasts are clearly recorded using something that doesn't allow per-participant recordings and, I'm guessing as long as the quality is good enough most aren't worrying about it.
EDIT: feel like I should mention Pion rules, I used it a few years ago to put together an SRT-to-WebRTC thing and RTMP-to-WebRTC thing to use with Janus Gateway, it was so easy.
Ah...you're scratching at some scabs with this totally reasonable question.
We learned some tough lessons with media-chrome[1] and Mux Player, where we tried to just write web components. The React side of things was a bit of a thorn, so we created React shims that provided a more idiomatic React experience and rendered the web components...which was mostly fine, but created a new set of issues. The reason we chose web components was to not have to write framework-specific code, and then we found ourselves doing both anyway.
With VJS 10 I think we've landed on a pretty reasonable middle ground. The core library is "headless," and then the rendering layer sits on top of it. Benefit is true React components and nice web components.
