6 ms·

> The only big drawback of Deno is the language Ooft. Although TypeScript does have a bit of a learning curve, and a lot of gotchas, I still have to say it's m

by zengid 4y ago

> The only big drawback of Deno is the language Ooft. Although TypeScript does have a bit of a learning curve, and a lot of gotchas, I still have to say it's my favorite language to use. If you combine the delicious syntax-sugar of ES6 (and beyond) with a sprinkling of tasteful types, the language leaves you full and energized without feeling bloated.

brigandish 4y ago
What are you comparing it to and what is lacking in those other languages?
- zengid 4y ago
  Good question. To be fair, JavaScript was my first "real" programming language, so my brain has adapted the most to it's weirdness. That's probably why TypeScript is very useful for me. But to answer your question, I've been using C# primarily for the last 4 years, and I dabble in other languages like Rust and Python. I used C++ in school (that's what they used for programming classes if you'll believe it). TypeScript feels pretty nice, but I do adore C#. I wish Microsoft would make a T# (as someone else put it once).
AlchemistCamp 4y ago
TypeScript’s type system is very complex and yet fails to achieve type safety to the degree that really strict languages do. I’m not that into class-based languages and prefer a language to have macros (more for DSLs they enable them for application code). However, even if those preferences were off the table, I’d still rather have something like Kotlin on the server than TS. It’s simpler and isn’t weighed down by 30 years of cruft.
- spartanatreyu 4y ago
  Typescript isn't really a class-based language. It's a language that supports both function and OO paradigms. Also, if macros/DSLs are what you're after, then you'd probably be interested in typescript's decorators. (you can use the old experimental decorators based on the old standard from ages past, and the new *standard* decorators introduced in typescript 5 which are based on the current stage-3 ecmascript proposal). The only things typescript as a language is really lacking are: 1. Pattern matching (minor issue) - +90% of pattern matching is really just a more concise switch/case syntax - the remaining -10% can be done by hand with mapping or just basic if statements 2. Immutable data-structures (minor issue) - The `as const` suffix handles most of the use cases. - There is a Records/Tuples proposal which would give some better syntactic sugar and some run-time performance improvements too. 3. Trait system (minor issue) - Typescript compiles down to Javascript which at the lowest level is actually a prototype-based language. Traits can be approximated using run-time mixins which alter the prototypes to essentially perform the same functions as traits. - But, it would be nice to have compile-time rather than run-time support for traits. - I think most languages are still only coming to terms with the fact that traits are often better than "traditional OOP classes". 4. Effects system (investigate) - It's too early to tell, but having an effects system (à la OCAML 5) will probably lead to entirely new programming paradigms. I'm not sure where it will lead, but having native algebraic effects to replace try/catch/throw would be very nice. Edit: Formatting
  - AlchemistCamp 4y ago
    As I said, the primary reason I wanted macros was for the DSLs they make possible, not their use in application code. For example when I’m working on a Phoenix app, I very rarely write a macro, but I get a great deal of benefit from Elixir them since they make Phoenix’s router DSL, Ecto’s database query syntax and the standard testing DSLs possible. I disagree that "pattern matching is "really just a more concise switch/case syntax" and use it regularly in function heads and in parsing nested data structures. More importantly, I reject the premise that the four items you mentioned are the only things really lacking or even that the problem with TS was a lack of features as opposed to its bad features, superfluous features and poor design decisions. For example, I'm not a fan of any of the following: - loose typing - multiple ways to declare variables, with different scoping rules - multiple ways to declare functions, with different treatment of "this" - the ability of code in any module anywhere in the system to affect code in the module you're looking at without leaving any evidence of this in the module you're looking at - the ability of functions to alter parameters they're called with - the sort function in the standard library being destructive by using the above - etc... That said, JS/TS really is missing some important things that didn't make your list: - a good concurrency model - macros - compile time guarantees about references - list comprehensions (actually minor) - a sufficient standard library - etc...
    - MrJohz 4y ago
      Fwiw, the function syntax in Typescript/Javascript is generally expressive enough to use as a basis for DSLs, and not needing to use macros for this also has a lot of benefits. I'm a big fan of Rust, but I find often library authors overuse custom syntax in macros when just writing functions would have been easier, just as expressive, and much simpler to integrate with an IDE. Where macros do exist in Javascript-land, they tend to be either to implement upcoming features, or as optimisation tools (e.g. converting CSS-in-JS expressions at build-time rather than run-time). The one exception here is probably JSX, but even there lots of people prefer to use function calls instead. But for things like testing blocks, configuration, HTML/CSS generation, etc, it's generally enough to use the language by itself.
- giraffe_lady 4y ago
  Shit even something like rescript. Ocaml is weighed down by 30 years of cruft and it's not known for a simple type system either. Yet it's still easier to work with than typescript and you get more for it.
- pjmlp 4y ago
  ES6 classes are still based on prototype inheritance underneath.
darthrupert 4y ago
Afaik, it's still missing a high quality REPL which python can give you. Extremely useful for exploratory coding. Otherwise I have to agree, Typescript is a pretty damned good compromise.
- jeremyjacob 4y ago
  Deno’s REPL is quite nice. It’s syntax highlighted, supports Typescript and autocompletion as well as creature comforts like enter opening a new line when the cursor is in between quotations. You can also pass a file to load and then work interactively from that. The URL-based imports allow you to paste code from another project and not worry about `npm install`ing anything.
- lloydatkinson 4y ago
  You can get pretty close with Vitest, a unit test as a REPL, and Vitest's ability to run tests as soon as the file changes.
spencerchubb 4y ago
I never understood why people feel that typescript has a learning curve. I never formally learned typescript; I just started using it intuitively. I already knew javascript, and I already understood how types work from using other languages, so there wasn't anything to learn. When people say typescript is hard to learn, do they know javascript, or are they starting from scratch?
- zengid 4y ago
  I had a similar experience where I was able to pick up most of it just by tinkering around with it, but there were a few places where I expected it to behave in a certain way, but ended up tripping over a few places where the type system is a little too weak, or the syntax for some of the advanced types are too unique to guess how it works without some studying. I made a blanket statement about the curve too, since I feel like the community as a whole is still adopting it. Library authors adopted it early, but the average front-end dev (judging from podcast topics and documentation I see) seems to be really getting serious about learning it in depth. YMMV.
- quectophoton 4y ago
  Same. Python's type hints and Ruby's Sorbet (or their weird RBS thing), I can understand. But TypeScript? Besides a few things that are not obvious at first (like callable interfaces), I don't think you really need to think about most stuff.
- jamal-kumar 4y ago
  It has an insanely complex type system. It's kind of incredible, I don't know of any other type systems off hand which are totally turing-complete. That's honestly really impressive. I don't think you need to use most of these types until you start getting into stuff like needing union types. You can get away with reading and writing most typescript without getting too crazy. I think the most compelling thing I read about type hinting is that it's like salt - A little and the dish doesn't taste the same without it but too much and you've ruined the thing
  - pjmlp 4y ago

by zengid 4y ago

brigandish 4y ago

What are you comparing it to and what is lacking in those other languages?

zengid 4y ago
Good question. To be fair, JavaScript was my first "real" programming language, so my brain has adapted the most to it's weirdness. That's probably why TypeScript is very useful for me. But to answer your question, I've been using C# primarily for the last 4 years, and I dabble in other languages like Rust and Python. I used C++ in school (that's what they used for programming classes if you'll believe it). TypeScript feels pretty nice, but I do adore C#. I wish Microsoft would make a T# (as someone else put it once).

AlchemistCamp 4y ago

TypeScript’s type system is very complex and yet fails to achieve type safety to the degree that really strict languages do. I’m not that into class-based languages and prefer a language to have macros (more for DSLs they enable them for application code). However, even if those preferences were off the table, I’d still rather have something like Kotlin on the server than TS. It’s simpler and isn’t weighed down by 30 years of cruft.

spartanatreyu 4y ago
Typescript isn't really a class-based language. It's a language that supports both function and OO paradigms. Also, if macros/DSLs are what you're after, then you'd probably be interested in typescript's decorators. (you can use the old experimental decorators based on the old standard from ages past, and the new *standard* decorators introduced in typescript 5 which are based on the current stage-3 ecmascript proposal). The only things typescript as a language is really lacking are: 1. Pattern matching (minor issue) - +90% of pattern matching is really just a more concise switch/case syntax - the remaining -10% can be done by hand with mapping or just basic if statements 2. Immutable data-structures (minor issue) - The `as const` suffix handles most of the use cases. - There is a Records/Tuples proposal which would give some better syntactic sugar and some run-time performance improvements too. 3. Trait system (minor issue) - Typescript compiles down to Javascript which at the lowest level is actually a prototype-based language. Traits can be approximated using run-time mixins which alter the prototypes to essentially perform the same functions as traits. - But, it would be nice to have compile-time rather than run-time support for traits. - I think most languages are still only coming to terms with the fact that traits are often better than "traditional OOP classes". 4. Effects system (investigate) - It's too early to tell, but having an effects system (à la OCAML 5) will probably lead to entirely new programming paradigms. I'm not sure where it will lead, but having native algebraic effects to replace try/catch/throw would be very nice. Edit: Formatting
- AlchemistCamp 4y ago
  As I said, the primary reason I wanted macros was for the DSLs they make possible, not their use in application code. For example when I’m working on a Phoenix app, I very rarely write a macro, but I get a great deal of benefit from Elixir them since they make Phoenix’s router DSL, Ecto’s database query syntax and the standard testing DSLs possible. I disagree that "pattern matching is "really just a more concise switch/case syntax" and use it regularly in function heads and in parsing nested data structures. More importantly, I reject the premise that the four items you mentioned are the only things really lacking or even that the problem with TS was a lack of features as opposed to its bad features, superfluous features and poor design decisions. For example, I'm not a fan of any of the following: - loose typing - multiple ways to declare variables, with different scoping rules - multiple ways to declare functions, with different treatment of "this" - the ability of code in any module anywhere in the system to affect code in the module you're looking at without leaving any evidence of this in the module you're looking at - the ability of functions to alter parameters they're called with - the sort function in the standard library being destructive by using the above - etc... That said, JS/TS really is missing some important things that didn't make your list: - a good concurrency model - macros - compile time guarantees about references - list comprehensions (actually minor) - a sufficient standard library - etc...
  - MrJohz 4y ago
    Fwiw, the function syntax in Typescript/Javascript is generally expressive enough to use as a basis for DSLs, and not needing to use macros for this also has a lot of benefits. I'm a big fan of Rust, but I find often library authors overuse custom syntax in macros when just writing functions would have been easier, just as expressive, and much simpler to integrate with an IDE. Where macros do exist in Javascript-land, they tend to be either to implement upcoming features, or as optimisation tools (e.g. converting CSS-in-JS expressions at build-time rather than run-time). The one exception here is probably JSX, but even there lots of people prefer to use function calls instead. But for things like testing blocks, configuration, HTML/CSS generation, etc, it's generally enough to use the language by itself.
giraffe_lady 4y ago
Shit even something like rescript. Ocaml is weighed down by 30 years of cruft and it's not known for a simple type system either. Yet it's still easier to work with than typescript and you get more for it.
pjmlp 4y ago
ES6 classes are still based on prototype inheritance underneath.

darthrupert 4y ago

Afaik, it's still missing a high quality REPL which python can give you. Extremely useful for exploratory coding. Otherwise I have to agree, Typescript is a pretty damned good compromise.

jeremyjacob 4y ago
Deno’s REPL is quite nice. It’s syntax highlighted, supports Typescript and autocompletion as well as creature comforts like enter opening a new line when the cursor is in between quotations. You can also pass a file to load and then work interactively from that. The URL-based imports allow you to paste code from another project and not worry about `npm install`ing anything.
lloydatkinson 4y ago
You can get pretty close with Vitest, a unit test as a REPL, and Vitest's ability to run tests as soon as the file changes.

spencerchubb 4y ago

I never understood why people feel that typescript has a learning curve. I never formally learned typescript; I just started using it intuitively. I already knew javascript, and I already understood how types work from using other languages, so there wasn't anything to learn. When people say typescript is hard to learn, do they know javascript, or are they starting from scratch?

zengid 4y ago
I had a similar experience where I was able to pick up most of it just by tinkering around with it, but there were a few places where I expected it to behave in a certain way, but ended up tripping over a few places where the type system is a little too weak, or the syntax for some of the advanced types are too unique to guess how it works without some studying. I made a blanket statement about the curve too, since I feel like the community as a whole is still adopting it. Library authors adopted it early, but the average front-end dev (judging from podcast topics and documentation I see) seems to be really getting serious about learning it in depth. YMMV.
quectophoton 4y ago
Same. Python's type hints and Ruby's Sorbet (or their weird RBS thing), I can understand. But TypeScript? Besides a few things that are not obvious at first (like callable interfaces), I don't think you really need to think about most stuff.
jamal-kumar 4y ago
It has an insanely complex type system. It's kind of incredible, I don't know of any other type systems off hand which are totally turing-complete. That's honestly really impressive. I don't think you need to use most of these types until you start getting into stuff like needing union types. You can get away with reading and writing most typescript without getting too crazy. I think the most compelling thing I read about type hinting is that it's like salt - A little and the dish doesn't taste the same without it but too much and you've ruined the thing
- pjmlp 4y ago