TypeScript never promised improving safety, maybe it’s a common misconception. But TypeScript has no runtime mode or information. You were always at the mercy of running and not ignoring the typechecker. Nothing stopped you from running ts-node or tsx on code with egregious type errors. TypeScript is more like a linter in that regard.
I think it's not fair to say that Typescript isn't about improving safety, just that the mechanism isn't the same as with other languages. Typescript had always allowed you to ignore the type checker (in fact, the default configuration will always attempt to emit compiled Javascript, even if the source Typescript has type errors). But if you run the type checker on every commit (via e.g. CI or a precommit hook), then you can be sure that the code you release is correctly typed, which will not guarantee it is safe, but makes it more likely.
I agree that it's better to think of Typescript as a linter that needs specialised annotations to work, rather than a type system like you might find in Java or Rust.
What, pray tell, would be the point of putting all that type information in there, and then have it checked (via tsc), if not for the sake of safety? What other use would this have in your opinion?
No, I don't think there really is. But to be execute is even more clear that it's just... executing the code, whereas I could maybe understand someone being confused that run implied some level of type checking.
This is misleading. It is not transpiling TS in JS, it is transpiling a subset of TS into JS. If my normal TS code can not be "executed" by Node, then it is not executing TS per definition but something else. If you are good with Node supporting and "executing" only a subset of TS and lacking useful features, that's fine. But don't tell people it is executing TypeScript. That's like me saying my rudimentary C++ compiler supports C++ while in reality only supporting 50%. People would be pissed if they figure it out once they try to run it on their codebase.
> node can find-and-replace type information with spaces from .ts files and try and executing them as if they were plain JavaScript
That’s what all the other tools like ts-node and tsx do already.
I’m not sure what more are you expecting to do?
Typescript is build time type checked, there is no runtime component to TypeScript. If you want type checking you run tsc.
I think this is a great step in the right direction by node. It will save transpiration on the server and improve stack traves and whatnot.
> Once you start using the type system more extensively I suspect this will blow-up in your face.
I don’t see why. There isn’t any more runtime information in “complex”
TypeSceipt types than in simple ones. It’s all build time - see above.
> What a missed opportunity to do it properly
Please explain in more detail what “doing it properly” means to you. Including the typechecker? If so that wouldn’t make sense - they would be competing with TypeScript itself, they shouldn’t, all the “third party plugins” rely on tsc for type checking.
> I think this is a great step in the right direction by node
I think it's the opposite. It will be a net negative, since people will now run TS by default without type checking. Wasting so much time chasing weird runtime errors - just to end up running the full blown TSC type checking again. They will also write very different TS now, trying to workaround the limitation and arguably very useful features like Enums, constructor properties, etc. This has real negative effects on your codebase if you rely on these, just because Node chose to support only a subset.
It's interesting to see the strategy now and to see people even gaslighting people into believing no type checks and less features is a good thing. All just because of one root cause - TSC being extremely slow.
Hmm I think two, since Google pays (paid) Apple to be the default search engine on iOS, it could’ve been said that WebKit and Safari development might have been partially financed with this money.
But I guess that falls apart when we treat Safari as dependent on Apple, which it is.
I wanted to mention MQTT (mqtt.org) as good lightweight protocol that has many implementations.
I was surprised author made no mention of it (mqtt.org) but come to think of it it might be because author is specifically looking for queues it seems and MQTT works better as a PubSub, and its durability story which seems the main focus of the author is way different with very cool features - QoS - for delivery reliability but still not a classic queue
My strategy was to start out by implementing the underlying storage primitives first, and then look into which transport to implement later. The transport of course can have a large impact on the required storage primitives, but in my case I built it the other way around since I knew what primitives I would need in my applications.
I've been playing with the thought of implementing (parts of) the Kafka API, but I honestly haven't considered the transport that much yet :)
Reading, 'ensuring that data is actually written and stays written is rather difficult', immediately reminded me of https://github.com/microsoft/FASTER (its not written in Go though), which is basically dealing with just that outlet ( except I think the KV store might be ram heavy, been a bit since I last looked at it )
Thanks for taking the time to tackle this research.
I think you should mention that „I looked” was done with help of your AI project. That does not spark much confidence given current state of LLMs and their „research”.
From your twitter article:
> So across the ~50 or so prominent whistleblower cases against big co's that I researched with futuresearch.ai, retaliation is common, harassment is rare but does happen, but murder is not.
I mean it all sounds fun but when you consider for example low-cost airlines in Europe (WizzAir, Ryanair) they’re really efficient without any of this, since their margins depend on it. Surprisingly their boarding isn’t as structured (only priority and then the rest) and they still only take around 30 mins total from first to last passengers being let through a gate in my experience. Their trick is probably some combination of motivated passengers, asking people to put stuff under the seat in from, remote stands that need a bus and flight attendants constantly announcing „please don’t block the aisle”.
Having not one more carry-on/roll-aboard than will fit in the overhead compartments is easily the most important thing to get right. Making the passengers pay for that space is the key.
This also explains why many airlines do the boarding group thing: because it rewards the frequent flyers with access to overhead bin space!
That's the reason that people want to board first!
So why not just charge for overhead bin space? Because it's unseemly and -anyways- hard to get right.
I flew Aer Lingus recently and the flight had exactly that: 1 free item of checked luggage, pay for hand luggage (except an under-the-seat-in-front-of-you personal item).
It worked great except that the bag-check process was absolutely terrible: every passenger had to go to the desk outside security. But other airlines have solved that issue (separate check-in and self-service-tag-printing+bag-drop-only queues make a big difference).
The thing I find funny about WizzAir/Ryanair is that because they have bundled the larger cabin bags with their priority boarding, when you show up, about 90% of the people are in the so called priority boarding queue.
> Surprisingly their boarding isn’t as structured (only priority and then the rest) and they still only take around 30 mins total from first to last passengers being let through a gate in my experience.
What's surprising about that? That's how you do quick boarding. Southwest has always done it that way. They start boarding 30 minutes before departure. And stop 10 minutes before.
What the long boarding line accomplishes is that it forces people to wait in a long line, which you can charge them to skip. Think of it as a mobile game with microtransactions, but for airplanes.
