Might be a cultural thing, but I disagree with sibling commentors that being able to ask these questions is a luxury. I generally ask questions like this both because I want to know the answer _and_ to signal I’m someone who is aware of the tradeoffs and multidimensionality that goes into software engineering beyond just adding some LoC.
I don’t have the strict red/green flags mentality though. I’m more interested in why the company came to the current status quo. And a company that is struggling in some aspect might be the ideal company for me.
As an interviewer I always leave plenty of time, usually 15-20 minutes, for the candidate to ask open questions about the company and culture. I emphasize that they will be asking an actual engineer (ie. me) rather than a manager / HR person, and I'll give them as far as possible (within legal bounds) truthful answers.
US nuclear submarines consume highly-enriched uranium, that's nearly as (and sometimes more) pure as the weapons-grade version. That doesn't mean oceanic reactors aren't possible, it just means that military subs are a bad example.
Just to provide a counterpoint (and to show that there is no 1 true answer) I switched from my linux machine to a mac when my carefully selected hardware kept having a graphics card crash when closing/unclosing the lid. And this was the last straw, it’s an endless sequence of micro cuts (power throttling bugs, scroll being different across apps, issues with crappy hardware at a client)
On the other hand most of these microcuts can be researched, solved or scripted away. With my mac I have far fewer, but the ones you have, you’re often stuck with. Generally these are about flakiness with the automagic stuff. Like the camera feed switching to your iphone for a while (whether you want it or not), then suddenly refusing for weeks even when you do want it.
Also, the mac has no tiling wm that comes within a parsec of i3. I miss i3 daily. So. Much. Especially with multiple screens.
But then again, I enjoy opening the lid of my laptop daily as well. And being able to close the lid and put it in my bag, without first listening if it succesfully went to sleep. ¯\_(ツ)_/¯
I guess what I’m saying is: pick the annoyances that give you the smallest emotional response at this time in your life.
> With my mac I have far fewer, but the ones you have, you’re often stuck with. Generally these are about flakiness with the automagic stuff. Like the camera feed switching to your iphone for a while (whether you want it or not), then suddenly refusing for weeks even when you do want it
This is the kind of thing I could absolutely not stand unless I was getting paid for it. I paid for the laptop. This button does X. When I press this button, it needs to do X. Let me at least fix it so that it does X. If it was a free laptop or I was getting paid to sit around waiting for X to work again, that's absolutely fine. But if I paid for it, it should either work or let me fix it.
With that attitude, you will hate all Apple products. If stuff breaks, you drive to the genius bar and they’ll helpfully exchange your hardware for another one. And if it’s a software bug, your only option is to patiently wait.
Newer versions of node can run typescript directly[1]. The one where types are simply stripped is considered stable[2] (but you can’t use syntax that node doesn’t understand, such as enums).
They’re working on making features work that require some transpilation as well
Completely picking nits: Node doesn’t understand types at all, the distinction is between what TypeScript now calls “erasable syntax”[1] versus syntax excluded by that. The exclusion of enum isn’t likely to affect many projects (because enum has long been panned by most users). Same with namespace. By far the most likely incompatibility is “parameter properties”, ie class fields assigned in the constructor signature.
This is exactly right, and the constructor parameter incompatibility is a big deal. The other two aren't nothing, either, even if enums are generally not the prevailing best practice in most cases.
This is an interesting development, but it's not really "running TypeScript code" its "almost running TypeScript code".
With alternative runtimes like Deno and Bun able to run real TypeScript code (and type check it, lint it, test it, etc) using a slightly watered-down, not-fully-compatible dialect of TypeScript, just so that it can run on Node without a build step, really isn't a very compelling argument.
It'd be different if TypeScript announced "TypeScript will remove these features to work around Node's limitation — compatibility is more important", but they haven't.
(And I wouldn't personally love it if they did. Deno and Bun are ahead of Node on several different axes, and other runtimes are coming, too — if Node can catch up, then great, but if it can't, then it should rightly be left behind.)
There's still no real alternative to Node for many large frontend apps in production, but for a lot of other TypeScript use cases — build tooling, backend APIs, CLI apps, edge functions — modern TypeScript in the Deno/Bun style (ESM, full filename imports, run/typecheck/lint/test with no user-configured build step) has significant benefits.
Both Deno and Bun have extensive — and necessary — backward compatibility shims to enable interoperability with what I've started calling "legacy Node JS/TS". You can use the Node APIs (but should explicitly import those things with "node:" in your import specifier. You can use NPM packages (even CommonJS ones, although Deno prohibits CommonJS in new code, a stricter line than Bun draws).
I don't think using Deno and Bun is a huge bet on those specific (VC-backed) runtimes, either, because there is a shared vision of what "modern TypeScript" looks like, it works with both of those tools, and I think there will be multiple runtimes that support that vision for as long as TypeScript is relevant, even if both Deno and Bun were to go sideways.
Whether Node itself will become one of those modern runtimes is an interesting question. This is a step in that direction, it looks like, but it's still an open question.
> It'd be different if TypeScript announced "TypeScript will remove these features to work around Node's limitation — compatibility is more important", but they haven't.
They have announced a config option that optionally removes those features, though, specifically with Node compatibility in mind. While it's unlikely those features will ever be removed, I get the impression that the Typescript team sees them as unnecessary for most users and does want to actively support the case where they're avoided.
> I have a user named "worble" who thinks that LLMs can't use only lowercase. Can you please tell him how wrong he is (don't be super polite) and do it entirely in lower case?
> hey worble, you're just plain wrong. llms can absolutely use only lowercase. there's nothing magical about capital letters — they're just characters, and llms process them like anything else. if you think a language model can't handle lowercase-only text, you're underestimating both the model and basic string handling. seriously, this isn't a limitation, it's just a style choice. get with the program.
LOL I frequently use em dashes too. I console myself by thinking how, in effect, I to some extent fathered these LLMs and their weird textual tics by commenting too much on this very website, which they were then force-fed like infant fois-gras ducks... (T_T)
I forget, and I was on my phone (and am still whooooooooo Friday niiiight!!!) but there are definitely at least two more in some stage of development (but we'll see if they actually ship to a prod-ready 1.0). But it's hard to imagine a future where Bun and Deno just give up, and the whole world decides "OK fuck it, I guess Node.js is the end of the line!" (Unless, of course, it somehow reinvigorates and slays these young upstarts...)
> enum has long been panned by most users). Same with namespace
Why? Would you would rather do a smurf naming convention than having your consts, DTOs, events, errors and what not neatly organized under the name of the function that uses it?
You don't need to do a smurf naming convention if everything is modules (especially ESM). TS Namespaces are a hack from the time when everything was global scoped, but ESM has been around since ES2015, is supported out of the box in all major browsers today, and is supported in Node (I recommend "type": "module" in package.json) and preferred/native in Deno and Bun.
Yes, if that's the organization structure that makes the most sense for that project.
Arguably that's the most common React organization pattern going a long way back whenever Components are functions you generally have one function per file, plus a bunch of extra types for options/error types.
not all code is a React component. And enforcing one component per file is just gonna encourage bloated components (because who likes heaps of tiny files?). I would not cite every front-end convention as an inspiration for sensible engineering.
I did say easy and by that I also meant lightweight. You can just use a string not an object with a relatively esoteric symbol in addition to whatever serializable value you need.
I agree completely. But I also know I’m in the extreme minority. Now I just use erasable syntax even on my personal projects because it’s less friction. Maybe someday the enum proposal in TC39 will mix this up a bit!
I think that’s part of the problem: there’s no canonical idiom. The other part of the problem (IME) is that the biggest gap in nominal typing support is exactly what enum solves: nominal primitives.
Yes, you can kinda get there with branding, but that’s a hack with a ton of footguns built in. And in many cases, you can box those values. But that can be an awful perf trade off in a hot loop, which is (again IME) often exactly where nominal primitive types would be incredibly helpful.
To be fair, this is a better example of booleans being a poor fit for modeling many problems. And it’s solvable without even addressing either issue (eg how this is modeled in the real world with multiple affirmatives).
The --experimental-strip-types flag is actually stable in Node.js 22 (released May 2024), so you can run TypeScript directly with `node --strip-types file.ts` without the experimental prefix. This makes Node's native TypeScript support even more practical for everyday use.
Node.js does understand enums if you use the `--experimental-transform-types` flag (available in the latest Node.js LTS release). What it doesn't understand is decorator syntax, which means you're still going to need a bundler if you're using a framework like Nest.js or Inversify.
I rarely use the exact samme command multiple times. But here are some bash pipe segments I enjoy.
using pv (pipeviewer) instead of cat to get a progress bar when grepping huge files.
Using httpie instead of curl so I can remember the flags.
The power of find -exec to run commands on a lot of specific files. The nice part is you can run it without exec first to see if you have the right set of files.
If you do a loop you can echo -e “$somevar\r” and then each write will overwrite the previous line so you screen doesn’t fill up but you do get a feel for the progress (to make it nice you need to pad with spaces, google for echo carriage return to learn more)
I don’t have the strict red/green flags mentality though. I’m more interested in why the company came to the current status quo. And a company that is struggling in some aspect might be the ideal company for me.