Hacker Newsnew | past | comments | ask | show | jobs | submit | dimitropoulos's commentslogin

it's interesting that in this article you see all three: TypeScript, Typescript, and typescript.

with all the hype around durable execution... what makes it difference from job queuing solutions like BullMQ or Agenda.js that rely on DLQ on top of Redis or Mongo? is it just a DX thing?


You can see durable execution as a combination of persistent state and queues (simplified example). With regular queues, the state is spread across many places from messages, runtime and external storages where the primary value is the reliability of the message processing and simple error management. Durable brings more advanced error management and end to end reliability with persistent state.


wow great example - I'm also baffled by this. is this just not a great example because it seems like it's reinventing the wheel


didn't the latest unreal release have something voxel related? cool to see more voxel stuff happening. we've come a long way since the Euclideon "unlimited detail" days.


the Doom in TypeScript types project wouldn't have been possible without Nick and Helion - I owe Nick a huge thanks! He helped with some of the more obscure parts of the engine and also helped make a super small WAD that is what the game eventually ran in.

Legend.


Doom in TypeScript types is amazing. Thank you for losing your mind for the rest of us :)


you're faulting a headline for being precise and accurate. there is no sense in which TypeScript is a runtime. TypeScript is literally a complier (targeting JavaScript, which has runtimes) and nothing more and has always been as such.


being technically accurate while still ambiguous is clickbait.


Most notably: a very prominent camera (the PYXIS 12K) was announced on Friday for $4,995 USD and on Sunday was changed to $6,595. Almost all other prices saw this 34% increase (but only for the US, all other countries are unaffected).


hi! author of the Doom thing, here. while I won't be the one to try, my answer is "absolutely yes, it will make a massive difference". Sub-1-day Doom-first-frame is probably a possibility now, if not much more because actually the thing that was the largest bottleneck for Doom-in-TypeScript-types was serializing the type to a string, which may well be considerably more than 10x faster. Hopefully someone will try some day!


> Sub-1-day Doom-first-frame

Love it :D


did you contribute to the current TypeScript codebase? (not intended snarky, just curious)


a couple of commits merged yrs back, things I stumbled on that I used as an excuse to learn more about internals


he went into more detail about C# in this one: https://youtu.be/10qowKUW82U?t=1154s


He says:

- C# Ahead of Time compiler doesn't target all the platforms they want.

- C# Ahead of Time compiler hasn't been stressed in production as many years as Go.

- The core TypeScript compiler doesn't use any classes; Go is functions and datastructures whereas C# is heavily OOP, so they would have to switch paradigms to use C#.

- Go has better control of low level memory layouts.

- Go was ultimately the path of least resistance.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: