i havent try with Deepseek with api, but you can install it with ollama. So you should be able to use the API. I just dont know for the <think> section and structured output.

Lol TONS of languages have pitfalls a lot worse than enum

@mattpocockuk yes but people don't pretend they are good But I read more about it and there's nothing actually wrong with typescript enums as long as they have a string definition, so that's cool

Great question! I'll think about that for the course.

You can make optional some field. So it wont fill when he dont find the value. Else, yes, it can hallucinate a lot. llama vision 3.2 hallucinate a lot more than chat gpt 4o

Erasable means it can be stripped at runtime. Non-erasable typing actually affects how your code behaves, erasable typing is only visible to the developer/typescript compiler. Enums are non-erasable, as code gets generated in its place; they're a form of syntactic sugar.

@@kakschoen that was clear, thanks! I think they get stripped at compile time, though, no?

Enums do not get stripped, they get compiled into a different form.

@@mattpocockuk makes sense now, thanks! Shoulda been calling "strippable..."

Everyone else got the normal greeting

🤦‍♂should have watched the next 5s of the video before posting the comment, of course LLM describe it for you lol

Absolutely wild!

It should! Fixed.

@@mattpocockuk 💙🙏

Yes, private and protected properties are not going away - just the automatic assignation in the constructor.

@mattpocockuk Yeah I know but still are they really bad practice to use? In your code, do you do this implicit assignment or assign values explicitly in the body of the constructors?

@mattpocockuk `public` vs. `Object.assign` - This is a minor thing but underlying a major tradeoff: In my company, codebase readability is probably worth more than direct portability across the runtimes and configurations, or do you think that it is the other way?

@ I assign values explicitly. And I don't understand why you're comparing public and Object.assign - they feel unrelated to me.

Because: - You need to ship source maps to make it work - It ties Node in somewhat to TypeScript's runtime syntax, which is not a dependency they want - especially when the TS themselves are signalling that it's not the future of TS.

Sure, go for it

It seems they dislike that those are checked runtime. But I have the same question. Because to me it is more important write clean code with the tools a language gives me than how the language supports such a feature.

@twigsagan3857 Agree 👍

​@twigsagan3857 same. And I think all of this is mostly about Node, and NOT browser. TypeScript doesn't really do anything at runtime in a browser... it's transpiled...

I guess partly it's because union types exist that can do the same thing without any extra syntax overhead, while also still having intellisense capabilities. Sometimes enums can also be transpiled differently depending on how they're written. I can't remember exactly, but say if you wanted to get all the values of an enum type via Object.values(), it will return essentially the same values twice, but with the keys and values swapped. Something like: { 1: "ValueA", 2: "ValueB", "ValueA": 1, "ValueB": 2 }

TypeScript is not a language, it's a type checker, so it goes against the modern standard that TS shouldn't be involved in runtime issues. Also enums are a little weird. You can code a typesafe Enum equivalent if you really want, or get similar results with simple things like objects.

You still have an enum alternative. Something like this should work: const myEnum = { value: "value", value2: "value2" ...} as const; type MyEnumType = typeof myEnum[keyof typeof myEnum];

I'd love enums in JavaScript. But TS enums are odd.

​@@akikadzeThat's a lot more work than an enum

​@@robertsandiford6223to me it is a language since I don't consider Javascript to be up to the task of scaling software. Typescript gives you options to keep you code clean. And it shouldn't matter from that perspective whether they do stuff runtime VS compile time. Enums make your code more stable.

Good thing the flag is optional :)

Why would node support something that isn't in the Ecma Script spec?

@@robertsandiford6223 nodejs should adopt all TS feature because there are TS devs who use them and they want to use them when they switch to vanilla nodejs also. That is a very practical down to earth argument, would you agree? What point would strictly following ecma spec have in this case? I agree that nodejs JS should follow ecma spec because its JS. But nodejs TS should follow TS spec. These are 2 different things.

@@weirdwordcombo TS has moved away from runtime features as that would create a clash between TS runtime features and new features added to JS itself. E.g. JS may one day have its own enums. We're not going to see further development of TS runtime features and support for them.

It's a JavaScript feature, so no need to erase it

No, because I think everyone involved (Node and TS team) see this as a possible sea change moment to get rid of some features that they're not interested in supporting. TS's future is as JS + Types, not as its own language with runtime features.

@mattpocockuk isn't it called JSDocs?