By now there is more than one story how some open source developer wasn't hired because their skills with the project they created was not sufficient for the job.
I’m 100% sure that if he was being considered for a domain expert role in some domain related to this (e.g. TypeScript) his score in a typical whiteboard interview wouldn’t have been a deciding factor whatsoever. This is a standard hiring track even in big tech. Sometimes you’ll even be exempt from these interviews altogether.
But if he was being considered for a mid level generalist role, yeah, none of this would’ve mattered. And why should it?
> But if he was being considered for a mid level generalist role, yeah, none of this would’ve mattered. And why should it?
As someone who has been on the hiring manager side, I'll state the obvious: because it demonstrates insanely good problem-solving skills that would transfer to nearly any challenge.
Maybe the catch was in saying that left right labels are arbitrary, could be called node1 and node2 as well, inverting is not necessary per se, just visit it in node2, node1 order if needs to be flipped - ie. no physical rearrangement is necessary.
leetcode seems to agree with your definition [0]. the meme isn't to say that inverting a binary tree is particularly difficult - anyone familiar with coding challenges and trees could trivially produce a solution. the meme is more pointing out how ludicrous it is that senior/staff/principal interviews can hinge on these types of problems, despite the engineer proving their proficiency by doing something like running DOOM in typescript types or writing homebrew [1].
> "We've decided to prioritize other candidates, as you are strong in the fundamentals but lack the kind of experience in Vue that we're looking for."
I have a nuanced view of your particular example. I've been in this industry for almost 30 years. I cut my teeth writing C/C++, had an interest in language theory and frameworks and was brought up to care about portability. I always wanted to be able to easily transition from one language to another, or one framework to another.
And I always assumed this was the case for other engineers in our field as well.
However, I have worked for startups that like to move really fast, and hired talented developers who passed our technical screenings (read: "had the fundamentals down") under a "framework agnostic" hiring policy ... only to see them display stunning degrees of incompetence trying to learn our tooling.
The problems that compound this are:
- When you enter a new company with a large codebase that you have to ramp up on, you're not only required to learn the language or 3rd party frameworks and libraries that they use ... you need to ramp up on THEIR "framework." Depending on the complexity of the system, there is a lot of domain specific knowledge and custom supporting code that will have been written. Try to learn the ins and outs of Angular change detection, for example, while also ramping up on a massive codebase that does things in weird ways for legacy and historic reasons.
- Every business, but some more so than others, has time pressure. You need to be able to write functional, easy to maintain code but also get it shipped yesterday. If you come into a company unfamiliar with the languages and tools that they use, you are essentially coming in handicapped. Expectations that you can deliver are very high, despite the time that you need to ramp up. Maybe you're one of those 10x'ers who can learn all the ins and outs of a new tool in a week or two before starting your position and then apply that knowledge at the level of someone whose been working with the tool for years and has learned all of the hidden footguns ... but if so, you are a rare specimen indeed. The industry can save itself a ton of inefficiency if it takes a "better not take a chance" attitude.
- All problems are people problems. It's not that the company needs people who know how to code in the language or tool ... they need someone who has worked on enough different projects with that tool that they can navigate the completely fucked up ways that THIS company uses it. Because THIS company will for sure have years of active development behind it by developers of all sorts of different experience levels ... and some of those developers did it the right way while others found creative solutions and did things weird. The company doesn't need someone who can write the Hello World tutorial in the language or framework, they need someone who can evaluate the good decisions vs the bad ones in an existing codebase.
Yeah that’s obvious and probably good. You’re trying to make a machine that reliably adds employees to your company in a way that minimizes nepotism or corruption.
Faced with the immutable fact that the chief executive cannot watch everything, that there will be pockets within the organization where people will sell access to a $300k job, and where others will hire from their family, their tribe, or so on: you make a system that is meant to prove some minimum standard while constraining your interviewers.
One thing that is not immediately obvious is that the Big Tech hiring process is to constrain your hiring team in who they bring on.
Startup executives are close to the road so they can tell if the rubber’s good much more easily.
The hiring process is designed around the constraint of executive attention. As are most things in firms.
>> @TimMattison
>> If this guy goes for a big tech interview they're still going to ask him how to invert a binary tree
> @MichiganTypeScript
> So actually in the "why" video, you're going to hear about exactly that! I was looking for a job during working on this and absolutely got some disappointing rejections, and one was because of my lack of skillset on things like this in a big tech company's interview. I literally failed the technical screening. Oh well.
He's also one of the principal organizers of SquiggleConf, a conference focused on devtools that takes place in Boston: https://2024.squiggleconf.com/about
What I'm saying is, if he still happens to be looking for a job, any employer reading this should be falling over themselves to recruit this man.
I got to watch Dimitri posting internal updates about his progress on this, and it has been utterly mindblowing. This is genuinely one of the most amazing things I've ever seen done with code. Absolutely legendary feat! (And also an incredible amount of persistence.)
Nothing will ever top this for typescript types. This is the pinnacle. An entire virtual machine and system memory with garbage collector in types.
Turing Completeness is one level, but being able to run Doom is the real test of whether a programming environment is complete and robust. Absolutely stunning to see TypeScript's type system get there.
(author here) _yes I realize how ridiculous what I'm about to say is considering the project I just shared_ but I actually strongly disagree, haahah. there's this thing I learned of called "the turing tarpit". my position is that just because something could theoretically be done with infinite time and infinite resources, doesn't mean you can even approach the throne of doing it for real in a human lifetime.
And if I'm just totally wrong on this, then you have your answer on why I never gave up on this project. I never once, ever, at any point, lost hope that it wouldn't work (HOW COULD IT?!).... right up until the very instant when I couldn't deny it anymore and it was on the screen in front of me.
Of course you're right, and I should have put quotes around "just". It would be amusing to calculate how long it would take to render the Google home page via Doom via TypeScript; I'd guess much longer than the age of the universe.
I wonder if there are any small changes/improvements to TS that would make this orders-of-magnitude more efficient to run? It would be fun to go implement some random TS feature with the secret sneaky goal of making it run Wasm better.
What I don't understand is how this thing does keyboard input.
At 3:42, the video simply says, "And, yes, there's a way to do keyboard input," without elaborating on how. What sorcery is that? There must be something outside the type system translating keyboard input into TypeScript types…??
(author here) pause on that screen and look at the code displayed on the right (as well as the note at the bottom!) the way to do keyboard inputs is basically exactly what people do for tool assisted speedrunners. Some people at this point in the message just went "oh cool!" and others went "you liar! that's not the same thing!". There was SO MUCH to say in 7 minutes in a short video like that, but rest assured, I'll go into depth on that in the next videos. The pong stuff that's shown is real (only the animating part was the creative liberty) and it's in the open source codebase.
I haven't checked the DOOM one, but for the Pong example, the keyboard input is prerecorded. As in the sequence of the keyboard key press are sequenced in a TS array[0].
If I had to guess, it's a file with an array of keys pressed (or unpressed) at some time interval (say 0.1 seconds). Then a VS code extension can append to the array every 0.1 second along with any key-press states at that time. The compiler updates the game state whenever this array gets updated.
However, I'm guessing this is why we see a demo of pong and not doom. Doom probably just can't keep up with this.
No idea if I'm remotely on the right track here though.
If I heard him correctly he stated that it takes A LOT to just render a single frame. It's not playable. It can run DOOM, but you can't actually play it.
Not only is Dimitri an amazing engineer - he's also great at building community and event/video production. Michigan Typescript meetups and videos have a level of polish that goes over and above
In the YouTube comments he stated nonetheless that he still bombed big tech interviews, specifically the technical portion, probably because of some ridiculous LeetCode problem he did not memorize beforehand. It just goes to show how these procedures do not effectively determine who is actually a good engineer or programmer. If this guy can't land a job while achieving this, then something is not quite right with the interview process.
hi! yep! this definitely happened. I do mention it in the next "why" video, but it's good feedback to know this is interesting to people because I could say a bit more about what those rejections were like - specifically the one where I failed the technical screening.
I'm actually really excited to share that part of the story because I hope it can be a small thing in the back of people's mind to help them if it happens to them. It can happen to anyone. Interviews are SUCH a lossy process and most engineers I know don't have any training on how to do interviews at all - yet we just assume they know how to evaluate people's skillsets.
Those interviews select for the type of person that believe it is worthwhile to dump tons of time into studying minutia to succeed at those types of interviews.
The purpose of a system is what it does, after all.
Amazing work. I'm interested in the choice of WASM - presumably any target that can run DOOM could've been used? Of which there are innumerable choices I assume. Was it for symbolic reasons or genuinely the most useful target?
WASM is one of the easier platforms to port as the Virtual Machine is well documented and there are actual implementations in many languages that can be used for debugging and comparing the results.
Typescript is for me one of the most overengineered programming languages. Why did JS not follow the way python and php did? Integrate types in the main language but make it optional.
When typescript came out, you were seen as weird for wanting such a thing. I once had a VP of engineering dm me to tell me to stop discussing typescript in the company dev channel around 2015 (if you're reading this, that was a dick move). Nowadays you're kinda odd man out if you don't want types. So the idea of adding types even optional ones probably wouldn't have gone down well. The closest we ever came was es4 which of course never landed: https://evertpot.com/ecmascript-4-the-missing-version/
i envy dimitri's ambition and capabilities. i want to be able to dedicate that much effort and more into something I'm passionate about. mostly personal discipline/skill issues but MAJOR props to dimitri and this awesome project.
(author here) that was one of the 1st-week "ok, but THAT'S surely a good reason this can't work..." until I dug in and (to my great surprise) found a way.
Throughout the video and while appreciating this unbelievable feat I kept thinking "how could someone have the motivation necessary to tackle such an insurmountable undertaking" ?
And then he said it: "All I wanted was the specific reason DOOM can't run in a type system but every time I hit a roadblock I always came up with some ridiculous workaround. I clung to that belief that it couldn't work and that doubt fuelled me the whole time."
Beautiful. I wonder if I can trick myself to one time attempt the impossible.
Brilliant. The TS type system is a true marvel of modern software engineering. Its a shame that it hasn't just been developed into a proper fully fledged runtime at this point. Something like Deno is the closest we'll get it seems.
Honestly every time I worked on TypeScript codebase and the type definition "any" started popping out more and more often, I felt I'm starring into the abyss.
That was the tipping point in transition from "we are serious and use static typing instead of lame JavaScript" into "ok we lost control over this thing".
Sure, there's many other ways to type it, but none adds any kind of additional safety or strictness over Record<any, any> which was my point that `any` is the correct type in many cases, except when it widens a type.
But in my case it's not widening anything, in Record<A, B>, B can already be `any`thing.
People tend to see it as an unsafe escape hatch (which is how it is abused), but it's just a set of all possible types.
I hope he learned something useful while doing it and it seems like he did, because, although regarding all the comments here I'll likely be alone in my assessment, I just see a massive waste of time & effort? He described it as "a brutal year-long journey of 18 hour days" and he didn't bootstrap a company, he wrote Doom in Typescript types...?! The "epic" doom music underlying his story just makes it seem even more comical to me.
Maybe it's just me, don't want to crash the party. Carry on
Kinda seems like you do wanna "crash the party". I disagree that this is a "waste of time" of course, the value I see here is manyfold:
1. Learning how to do self-directed learning, managing time, etc
2. Learning, at an expert level, about dozens of complicated (not to mention in-demand) CS subdomains
3. Doing something that nobody has attempted, and few people could realistically accomplish
4. Having fun on the journey of taking a ridiculous idea from conception through to a truly functional implementation
5. Sharing something you've built with the world
It is, of course, not everyone's cup of tea, but if someone wants to spend a not insignificant fraction of their life building something unique (and beautiful, in its own way) and sharing it with the world, to the detriment of quite literally nobody else, I support them in their adventure.
I guess you have to ask yourself, what truely gives value in life? The answer is that value is subjective, and this person is wasting his time no less or more than you or I.
Recreating the WASM runtime makes you learn a crap ton of useful stuff no matter what you use as your host compiler. In this case, the host being the typescript compiler happens to also add a wow-factor.
imagine how amazing it would be if every major browser tomorrow suddenly dropped support for JS entirely and said that they only run typescript now. It will be a hard but absolutely mind blowing transition
What would be the point? Why waste time parsing and ignoring types? Types are for static analysis during comp time, they have nothing to do with the runtime and they don't provide "type hints" to the runtime about types, and code isn't optimized based on static typing analysis. Or should the browser do that? In that case which version of TypeScript? And by version I actually mean which tsconfig? Sorry for being picky but can't image why we would want something like that. If all we wanted was a compiled runtime like flash/actionscript was then I wonder why we killed flash
I wonder if there will come a time when the HN audience will stop being amazed that some system is Turing complete, or that any Turing-complete system can run Doom (barring resource constraints). Maybe I’ve just seen it too often. The fact that TypeScript’s type system is Turing-complete was shown back in 2017 [0], and then of course you can run Doom on it.
There’s a difference between a _system_ being Turing complete and something actually _using_ that Turing-completeness to make something arbitrary run on it. You can’t deny this is an impressive effort.
It’s a considerable amount of work for sure, but that alone doesn’t make it impressive. Maybe there were particularly difficult hurdles to overcome that were solved in novel ways? But I don’t see such noteworthy aspects being mentioned in this thread, and it’s not evident at all that there should be any.
Is this your reaction when someone climbs a mountain? "Bipedal locomotion was shown sufficient for climbing mountains centuries ago, given reasonable assumptions about the terrain, why should I be impressed?"
Doing things can be difficult and admirable, even if it was confidently believed possible beforehand.
> Is this your reaction when someone climbs a mountain?
My reaction then isn’t “wow, this blows my mind that it’s possible”. The first time someone climbing Mount Everest 72 years ago was impressive and possibly astounding. Nowadays, not really that much.
We know that humans are capable of writing amazing symphonies or running a 2h marathon, so there’s no point in doing it?
Just because we know something is possible in theory doesn’t mean it’s not impressive to see it done in practice. There was a lot of effort and creativity involved here.
To be fair, this is graphical, but it's not real-time, not performant, and while it technically takes input, it'll be a while before you see it reflected in the output.
One of the top comments in the video:
> If this guy goes for a big tech interview they're still going to ask him how to invert a binary tree
The industry's hiring process is so messed up that this is completely believable.
"We've decided to prioritize other candidates, as you are strong in the fundamentals but lack the kind of experience in Vue that we're looking for."
By now there is more than one story how some open source developer wasn't hired because their skills with the project they created was not sufficient for the job.
I go back and forth on my opinion for this one. You wouldn’t necessarily want a mechanic or engineer to drive a race car, for example.
I’m 100% sure that if he was being considered for a domain expert role in some domain related to this (e.g. TypeScript) his score in a typical whiteboard interview wouldn’t have been a deciding factor whatsoever. This is a standard hiring track even in big tech. Sometimes you’ll even be exempt from these interviews altogether.
But if he was being considered for a mid level generalist role, yeah, none of this would’ve mattered. And why should it?
Would he have made it past your recruiter screen though?
A lot of people who have a gap between jobs for 1-2 years because they worked on their insane projects certainly wouldn't.
And would he have even bothered to apply, given the boring-sounding, narrowly worded JDs that get posted?
[flagged]
Has anybody ever figured out what "invert a binary tree" means? That came from Max Howell, and nobody else seems to have ever received that question.
The best anyone can figure out is that it's reversing the left and right branches, which seems like it's ten lines of code, at most?
Maybe the catch was in saying that left right labels are arbitrary, could be called node1 and node2 as well, inverting is not necessary per se, just visit it in node2, node1 order if needs to be flipped - ie. no physical rearrangement is necessary.
leetcode seems to agree with your definition [0]. the meme isn't to say that inverting a binary tree is particularly difficult - anyone familiar with coding challenges and trees could trivially produce a solution. the meme is more pointing out how ludicrous it is that senior/staff/principal interviews can hinge on these types of problems, despite the engineer proving their proficiency by doing something like running DOOM in typescript types or writing homebrew [1].
[0] https://leetcode.com/problems/invert-binary-tree/description...
[1] https://x.com/mxcl/status/608682016205344768
Reminds me of https://aphyr.com/posts/342-typing-the-technical-interview
> "We've decided to prioritize other candidates, as you are strong in the fundamentals but lack the kind of experience in Vue that we're looking for."
I have a nuanced view of your particular example. I've been in this industry for almost 30 years. I cut my teeth writing C/C++, had an interest in language theory and frameworks and was brought up to care about portability. I always wanted to be able to easily transition from one language to another, or one framework to another.
And I always assumed this was the case for other engineers in our field as well.
However, I have worked for startups that like to move really fast, and hired talented developers who passed our technical screenings (read: "had the fundamentals down") under a "framework agnostic" hiring policy ... only to see them display stunning degrees of incompetence trying to learn our tooling.
The problems that compound this are:
- When you enter a new company with a large codebase that you have to ramp up on, you're not only required to learn the language or 3rd party frameworks and libraries that they use ... you need to ramp up on THEIR "framework." Depending on the complexity of the system, there is a lot of domain specific knowledge and custom supporting code that will have been written. Try to learn the ins and outs of Angular change detection, for example, while also ramping up on a massive codebase that does things in weird ways for legacy and historic reasons.
- Every business, but some more so than others, has time pressure. You need to be able to write functional, easy to maintain code but also get it shipped yesterday. If you come into a company unfamiliar with the languages and tools that they use, you are essentially coming in handicapped. Expectations that you can deliver are very high, despite the time that you need to ramp up. Maybe you're one of those 10x'ers who can learn all the ins and outs of a new tool in a week or two before starting your position and then apply that knowledge at the level of someone whose been working with the tool for years and has learned all of the hidden footguns ... but if so, you are a rare specimen indeed. The industry can save itself a ton of inefficiency if it takes a "better not take a chance" attitude.
- All problems are people problems. It's not that the company needs people who know how to code in the language or tool ... they need someone who has worked on enough different projects with that tool that they can navigate the completely fucked up ways that THIS company uses it. Because THIS company will for sure have years of active development behind it by developers of all sorts of different experience levels ... and some of those developers did it the right way while others found creative solutions and did things weird. The company doesn't need someone who can write the Hello World tutorial in the language or framework, they need someone who can evaluate the good decisions vs the bad ones in an existing codebase.
Yeah that’s obvious and probably good. You’re trying to make a machine that reliably adds employees to your company in a way that minimizes nepotism or corruption.
Faced with the immutable fact that the chief executive cannot watch everything, that there will be pockets within the organization where people will sell access to a $300k job, and where others will hire from their family, their tribe, or so on: you make a system that is meant to prove some minimum standard while constraining your interviewers.
One thing that is not immediately obvious is that the Big Tech hiring process is to constrain your hiring team in who they bring on.
Startup executives are close to the road so they can tell if the rubber’s good much more easily.
The hiring process is designed around the constraint of executive attention. As are most things in firms.
From YT comment section:
>> @TimMattison >> If this guy goes for a big tech interview they're still going to ask him how to invert a binary tree
> @MichiganTypeScript > So actually in the "why" video, you're going to hear about exactly that! I was looking for a job during working on this and absolutely got some disappointing rejections, and one was because of my lack of skillset on things like this in a big tech company's interview. I literally failed the technical screening. Oh well.
He's also one of the principal organizers of SquiggleConf, a conference focused on devtools that takes place in Boston: https://2024.squiggleconf.com/about
What I'm saying is, if he still happens to be looking for a job, any employer reading this should be falling over themselves to recruit this man.
I got to watch Dimitri posting internal updates about his progress on this, and it has been utterly mindblowing. This is genuinely one of the most amazing things I've ever seen done with code. Absolutely legendary feat! (And also an incredible amount of persistence.)
Where can we see these updates?
Michigan Typescript has an active discord: https://discord.com/invite/DHtwNDTwrR
the #doom channel is where Mark is referring to. it's all there!
Nothing will ever top this for typescript types. This is the pinnacle. An entire virtual machine and system memory with garbage collector in types.
Turing Completeness is one level, but being able to run Doom is the real test of whether a programming environment is complete and robust. Absolutely stunning to see TypeScript's type system get there.
Well we haven't implemented a web browser capable of running javascript in the typescript type system yet.
Quick, someone tell this author it's not possible.
Doom is Turing complete (https://calabi-yau.space/blog/doom.html), so it's just a matter of building the appropriate map.
(author here) _yes I realize how ridiculous what I'm about to say is considering the project I just shared_ but I actually strongly disagree, haahah. there's this thing I learned of called "the turing tarpit". my position is that just because something could theoretically be done with infinite time and infinite resources, doesn't mean you can even approach the throne of doing it for real in a human lifetime.
And if I'm just totally wrong on this, then you have your answer on why I never gave up on this project. I never once, ever, at any point, lost hope that it wouldn't work (HOW COULD IT?!).... right up until the very instant when I couldn't deny it anymore and it was on the screen in front of me.
Of course you're right, and I should have put quotes around "just". It would be amusing to calculate how long it would take to render the Google home page via Doom via TypeScript; I'd guess much longer than the age of the universe.
That's not really relevant. Turing complete languages are used to build Doom and Pong, but one is more impressive than the other.
Blew my mind! Dimitri talks about it in the video but I love the mention of how this project came to be[0]:
> This engine was built to service a project that aimed to demonstrate why Doom can't run in TypeScript types. Well. The funny thing is.. It can.
[0]: https://github.com/MichiganTypeScript/typescript-types-only-...
Can someone help direct me toward an understanding of what it means for something to be "run in/by TypeScript types"?
A short explanation or link to a resource would really be helpful. :)
At this point the easiest way to know if a system is Turing complete is to check if someone has ported DOOM to it haha
Very impressive!
Only if the church-turing-carmack thesis holds, which I personally doubt
Alternatively if The Romero Hypothesis is proven to map the distribution of Mancubus numbers ... >_<
HN Pedantism never fails to elicit a chuckle from me
https://github.com/desi-ivanov/ts-lambda-calc
Doom compiled to just 177 TB (terabytes) of TypeScript types. Amazing on many levels.
This must be the quintessential example of a Turing tarpit.
In TypeScript types, everything is possible, but nothing of interest is easy.
For the first frame...
I think that 177 TB is for the whole shebang, it's just that it took 12 days to render the first frame.
I wonder if there are any small changes/improvements to TS that would make this orders-of-magnitude more efficient to run? It would be fun to go implement some random TS feature with the secret sneaky goal of making it run Wasm better.
Arithmetics were apparently integrated into TypeScript types for that exact reason:
https://note89.github.io/typescript-typelevel-tic-tac-toe/
If there's one top story HN deserves today, it has to be this. Absolutely insane and incredibly inspirational.
My literal LOL of the month. Love the types scale graphics/animation. :mind-blown:
A WASM runtime in TypeScript types is impressive in its own right, but I think I can dimly see how it could work with a lot of effort. https://github.com/MichiganTypeScript/typescript-types-only-...
What I don't understand is how this thing does keyboard input.
At 3:42, the video simply says, "And, yes, there's a way to do keyboard input," without elaborating on how. What sorcery is that? There must be something outside the type system translating keyboard input into TypeScript types…??
(author here) pause on that screen and look at the code displayed on the right (as well as the note at the bottom!) the way to do keyboard inputs is basically exactly what people do for tool assisted speedrunners. Some people at this point in the message just went "oh cool!" and others went "you liar! that's not the same thing!". There was SO MUCH to say in 7 minutes in a short video like that, but rest assured, I'll go into depth on that in the next videos. The pong stuff that's shown is real (only the animating part was the creative liberty) and it's in the open source codebase.
I haven't checked the DOOM one, but for the Pong example, the keyboard input is prerecorded. As in the sequence of the keyboard key press are sequenced in a TS array[0].
[0]: https://github.com/MichiganTypeScript/typescript-types-only-...
yep! exactly this! like how a tool assisted speedrunner works
If I had to guess, it's a file with an array of keys pressed (or unpressed) at some time interval (say 0.1 seconds). Then a VS code extension can append to the array every 0.1 second along with any key-press states at that time. The compiler updates the game state whenever this array gets updated.
However, I'm guessing this is why we see a demo of pong and not doom. Doom probably just can't keep up with this.
No idea if I'm remotely on the right track here though.
If I heard him correctly he stated that it takes A LOT to just render a single frame. It's not playable. It can run DOOM, but you can't actually play it.
"A lot" is an understatement, rendering the screen at ~320p took 12 days.
This shouldn’t be possible.. Typescript devs have lost their collective minds and I’m totally here for it.
Edit : TS not front end
That's pretty insane Dimitri. If you like stuff like this I really recommend Dimitri's TypeScript challenges series: https://www.youtube.com/playlist?list=PLOlZuxYbPik180vcJfsAM...
Not only is Dimitri an amazing engineer - he's also great at building community and event/video production. Michigan Typescript meetups and videos have a level of polish that goes over and above
In the YouTube comments he stated nonetheless that he still bombed big tech interviews, specifically the technical portion, probably because of some ridiculous LeetCode problem he did not memorize beforehand. It just goes to show how these procedures do not effectively determine who is actually a good engineer or programmer. If this guy can't land a job while achieving this, then something is not quite right with the interview process.
hi! yep! this definitely happened. I do mention it in the next "why" video, but it's good feedback to know this is interesting to people because I could say a bit more about what those rejections were like - specifically the one where I failed the technical screening.
I'm actually really excited to share that part of the story because I hope it can be a small thing in the back of people's mind to help them if it happens to them. It can happen to anyone. Interviews are SUCH a lossy process and most engineers I know don't have any training on how to do interviews at all - yet we just assume they know how to evaluate people's skillsets.
What you've accomplished demonstrates a very important skill you have, persistence. Kudos and don't give up.
About those rejections, did they effect your confidence in yourself and your skills? How did they make you feel?
Those interviews select for the type of person that believe it is worthwhile to dump tons of time into studying minutia to succeed at those types of interviews.
The purpose of a system is what it does, after all.
Amazing work. I'm interested in the choice of WASM - presumably any target that can run DOOM could've been used? Of which there are innumerable choices I assume. Was it for symbolic reasons or genuinely the most useful target?
WASM is one of the easier platforms to port as the Virtual Machine is well documented and there are actual implementations in many languages that can be used for debugging and comparing the results.
even in pure JS: https://github.com/evanw/polywasm
WASM is the easiest target because you don't have to emulate an entire computer.
Your only miss is that you should be selling that "Types" Doom themed shirt.
To be clear, it's running in TypeScript types only -- not JavaScript. Absolutely insane
Microsoft Solitaire is apparently the most installed program.
Doom must be the most ported.
Plus three months of recording/cutting/editing the video. Well done.
The video is very impressive by itself. This guy is a perfectionist
Typescript is for me one of the most overengineered programming languages. Why did JS not follow the way python and php did? Integrate types in the main language but make it optional.
When typescript came out, you were seen as weird for wanting such a thing. I once had a VP of engineering dm me to tell me to stop discussing typescript in the company dev channel around 2015 (if you're reading this, that was a dick move). Nowadays you're kinda odd man out if you don't want types. So the idea of adding types even optional ones probably wouldn't have gone down well. The closest we ever came was es4 which of course never landed: https://evertpot.com/ecmascript-4-the-missing-version/
Typescript does support it. You can do everything ts can in js with just jsdoc style comments. I actually prefer it.
Thank god they didn't follow the way Python did.
i envy dimitri's ambition and capabilities. i want to be able to dedicate that much effort and more into something I'm passionate about. mostly personal discipline/skill issues but MAJOR props to dimitri and this awesome project.
If you decide to have kids that’s a great long term project.
What the FUCK
About time some good news!
Bad Apple time!
Try to fit that in a context window! Absolutely amazing.
(author here) that was one of the 1st-week "ok, but THAT'S surely a good reason this can't work..." until I dug in and (to my great surprise) found a way.
Incredibly good video editing, unbridled insantiy, cheers!
Throughout the video and while appreciating this unbelievable feat I kept thinking "how could someone have the motivation necessary to tackle such an insurmountable undertaking" ?
And then he said it: "All I wanted was the specific reason DOOM can't run in a type system but every time I hit a roadblock I always came up with some ridiculous workaround. I clung to that belief that it couldn't work and that doubt fuelled me the whole time."
Beautiful. I wonder if I can trick myself to one time attempt the impossible.
Related: MichiganTypeScript: A WebAssembly runtime implemented in TypeScript types - https://github.com/MichiganTypeScript/typescript-types-only-...
(via https://news.ycombinator.com/item?id=43185174, but we merged that thread hither)
I wish tsc didn't take eternity to run though.
Brilliant. The TS type system is a true marvel of modern software engineering. Its a shame that it hasn't just been developed into a proper fully fledged runtime at this point. Something like Deno is the closest we'll get it seems.
Honestly every time I worked on TypeScript codebase and the type definition "any" started popping out more and more often, I felt I'm starring into the abyss.
There are valid use cases for any (such as type constraints).
Playground with example here: https://tinyurl.com/5ahs366a
That was the tipping point in transition from "we are serious and use static typing instead of lame JavaScript" into "ok we lost control over this thing".
What do you mean?
This is perfectly sound and valid from both a practical and theoretical pov.
Which is why I was pointing out that there are scenarios like constraints where any not only makes sense but is the correct type.
Seems to also work without any:
Sure, there's many other ways to type it, but none adds any kind of additional safety or strictness over Record<any, any> which was my point that `any` is the correct type in many cases, except when it widens a type.
But in my case it's not widening anything, in Record<A, B>, B can already be `any`thing.
People tend to see it as an unsafe escape hatch (which is how it is abused), but it's just a set of all possible types.
mad respect! you are a legend.
Not to be a grouch, but I feel like this could be way more optimized
It's a bit that it is oversold, but it's a cute little VM.
https://github.com/MichiganTypeScript/typescript-types-only-...
Though the fact that the actual converter that converts from WASM to TypeScript types is in Rust makes it lose a bit of charm, but still.
Like Flappy Bird in TypeScript types did: https://zackoverflow.dev/writing/flappy-bird-in-type-level-t...
It is open-source, you are of course more than welcome to take a crack at it.
I hope he learned something useful while doing it and it seems like he did, because, although regarding all the comments here I'll likely be alone in my assessment, I just see a massive waste of time & effort? He described it as "a brutal year-long journey of 18 hour days" and he didn't bootstrap a company, he wrote Doom in Typescript types...?! The "epic" doom music underlying his story just makes it seem even more comical to me.
Maybe it's just me, don't want to crash the party. Carry on
> don't want to crash the party
> I just see a massive waste of time & effort
Kinda seems like you do wanna "crash the party". I disagree that this is a "waste of time" of course, the value I see here is manyfold:
1. Learning how to do self-directed learning, managing time, etc
2. Learning, at an expert level, about dozens of complicated (not to mention in-demand) CS subdomains
3. Doing something that nobody has attempted, and few people could realistically accomplish
4. Having fun on the journey of taking a ridiculous idea from conception through to a truly functional implementation
5. Sharing something you've built with the world
It is, of course, not everyone's cup of tea, but if someone wants to spend a not insignificant fraction of their life building something unique (and beautiful, in its own way) and sharing it with the world, to the detriment of quite literally nobody else, I support them in their adventure.
I guess you have to ask yourself, what truely gives value in life? The answer is that value is subjective, and this person is wasting his time no less or more than you or I.
You could say the same about art. Artists put lots of time and effort into creating unuseful things to inspire others. Just like here!
It is just you, I think.
Recreating the WASM runtime makes you learn a crap ton of useful stuff no matter what you use as your host compiler. In this case, the host being the typescript compiler happens to also add a wow-factor.
[dead]
[dead]
imagine how amazing it would be if every major browser tomorrow suddenly dropped support for JS entirely and said that they only run typescript now. It will be a hard but absolutely mind blowing transition
What would be the point? Why waste time parsing and ignoring types? Types are for static analysis during comp time, they have nothing to do with the runtime and they don't provide "type hints" to the runtime about types, and code isn't optimized based on static typing analysis. Or should the browser do that? In that case which version of TypeScript? And by version I actually mean which tsconfig? Sorry for being picky but can't image why we would want something like that. If all we wanted was a compiled runtime like flash/actionscript was then I wonder why we killed flash
I know the following comment is discouraged from hackernews but these are extenuating circumstances:
Yoooo WTAF
I wonder if there will come a time when the HN audience will stop being amazed that some system is Turing complete, or that any Turing-complete system can run Doom (barring resource constraints). Maybe I’ve just seen it too often. The fact that TypeScript’s type system is Turing-complete was shown back in 2017 [0], and then of course you can run Doom on it.
[0] https://github.com/microsoft/TypeScript/issues/14833
There’s a difference between a _system_ being Turing complete and something actually _using_ that Turing-completeness to make something arbitrary run on it. You can’t deny this is an impressive effort.
It’s a considerable amount of work for sure, but that alone doesn’t make it impressive. Maybe there were particularly difficult hurdles to overcome that were solved in novel ways? But I don’t see such noteworthy aspects being mentioned in this thread, and it’s not evident at all that there should be any.
Is this your reaction when someone climbs a mountain? "Bipedal locomotion was shown sufficient for climbing mountains centuries ago, given reasonable assumptions about the terrain, why should I be impressed?"
Doing things can be difficult and admirable, even if it was confidently believed possible beforehand.
> Is this your reaction when someone climbs a mountain?
My reaction then isn’t “wow, this blows my mind that it’s possible”. The first time someone climbing Mount Everest 72 years ago was impressive and possibly astounding. Nowadays, not really that much.
Oh come on, are you seriously being blasé about this? What could ever impress you?
A time-travel machine would be really impressive, I would give all my money for that, and even upvote the thread.
> I wonder if there will come a time when the HN audience will stop being amazed that some system is Turing complete
The time is now, but if you had said
> I wonder if there will come a time when the HN audience will stop being amazed that some system can run Doom
The answer is never, and particularly not when its this insane to even try
We know that humans are capable of writing amazing symphonies or running a 2h marathon, so there’s no point in doing it?
Just because we know something is possible in theory doesn’t mean it’s not impressive to see it done in practice. There was a lot of effort and creativity involved here.
There is a big gap between "Turing complete"-able and "real-time, interactive, graphical and performant"-thing.
To be fair, this is graphical, but it's not real-time, not performant, and while it technically takes input, it'll be a while before you see it reflected in the output.
I think you missed the part about how much effort they put into it.
Ah yes, the Underpants Gnomes theory of Doom execution:
Step 2 is, of course, always trivial, and no amount of effort or technical nous that goes into actually getting to step 3 can possibly be relevant.