Readit NewsThat's a huge advantage, it's means all the obvious stuff will just work. LSPs, debuggers, version control, customisation.
As much as I like Emacs, it's an insane pain to make all these things work.
If your value prop is agents on a codebase, there's no point in trying to reinvent those. They have basically been solved.
He didn’t thought about… unplugging the bed?
There are lots of competing MLs you can use instead:
- F# (Fable)
- ReasonML
- OCaml (Bucklescript)
- Haskell
- PureScript
IMO the problem with Elm was actually The Elm Architecture.
I've heard someone at Microsoft describe it as a moonshot but also a retention project; IIRC it had a hundred plus engineers on it at one time, including a lot of very senior people.
Apparently a bunch of research from Midori made it into .NET so it wasn't all lost, but still...
Never heard this phrase before, but I can definitely see this happening at companies of that size
My background is not networking ( it’s math then hpc then broader stuff ) but I keep stumbling on similar problems ( including a beautiful one related to intel NICs a few years ago which led be into a rabbit hole of ebpf and kernel network layer and which surfaced later on the cloudflare blog), and the only tech company with which this seems to be a regular occurrence is cloudflare. Their space is a bit unknown to me so I guess I’m having a hard time projecting something onto the job offers.
I’d happily chat to someone working for cloudflare though - I guess this would help me understand what it is that actually happens over there. I guess I’m a bit intimidated by this unknown yet really good looking world :-)
Can't speak to the locations but the stuff you're interested/experienced in seems extremely likely to overlap with what they do. They do a lot of very deep technical things in all kinds of areas.
my recommendation if you want to talk to someone about it: search github/twitter/linkedin for ppl who work there on stuff you like, and just send them a message and ask for a 20 minute call!
have done it plenty of times, has always been extremely positive
> After this change, stacks larger than 1<<12 will build the offset in a temporary register and then add that to rsp in a single, indivisible opcode. A goroutine can be preempted before or after the stack pointer modification, but never during. This means that the stack pointer is always valid and there is no race condition.
Seems silly to pessimize the runtime, even slightly, to account for the partial register construction. DWARF bytecode ought to be powerful enough to express the calculations needed for restoring the true stack pointer if we're between immediate adjustments.
But isn't that the same thing here? The bug occurred in their production workflows, not in some specific debug builds, so with that seems pretty reasonable to call it a compiler bug?
You can store the state in the SSE connection and have the problems described, and if you don't like those, you can move thr state to something distributed/persisted.
Pubsub is just a layer on top of SSE or websockets, cause guess how it'd end up sending things to the browser