4 ms·

Variables ES6 wins, 'val' and 'var' are annoying close to each other. Primitive Types Scala hands down. Not even close. Functions Scala is more expressive

Variables ES6 wins, 'val' and 'var' are annoying close to each other. Primitive Types Scala hands down. Not even close. Functions Scala is more expressive (well if you ignore the types). I wish more languages would do the Haskell thing and let you write the type sig at the top. Typescript functions get so long. Anonymous Functions Very similar, so calling it a tie. Default, named and rest parameters I'll give this one to ES6 because the spread syntax feels more intuitive than * at the end of a type. if, while, for, match control structures Scala, because if is an expression and the for loop syntax is so concise. Also forget how nice nested looping was. Classes Scala. It's just more concise, I always liked not having to write boilerplate constructors. Case classes I mean I guess Scala but I still prefer polymorphism to pattern matching (please don't hurt me 2022 programmers) Objects Scala is shorter and more expressive here. Traits Scala because I never liked mutating objects, though I guess that's the prototype way. Option, the type safe undefined I mean Scala because I guess it actually has it, but worth pointing out it's like 30 LOC to define one for JS, depending on how many convenience methods you want. ---- Pointless post but this has made me kind of nostalgic for Scala. Maybe I own a computer fast enough to compile it now..

valenterry 5y ago
> Variables > ES6 wins, 'val' and 'var' are annoying close to each other. Disagree. I don't like either Scala nor ES - but "const" is really confusing. It implies that whatever we store is constant, but it's not. I can store a mutable object and it changes whenever I want - only the reference is constant. > Default, named and rest parameters > I'll give this one to ES6 because the spread syntax feels more intuitive than * at the end of a type. Not sure. If I imagine I come from a language without such a feature, then having "..." infront of the parameter seems confusing. "...args..." would be clearer. Having "Double*" is also a bit confusing, but I find that * is often used for such a situation (e.g. in regex) > Case classes > I mean I guess Scala but I still prefer polymorphism to pattern matching (please don't hurt me 2022 programmers) Scala is really lacking a way to easily support structural typing like typescript does. ES clearly wins here, since in Scala you have to define the case class in advance. And while you can just use maps, you give up typesafety.
- zosima 5y ago
  > Disagree. I don't like either Scala nor ES - but "const" is really confusing. It implies that whatever we store is constant, but it's not. I can store a mutable object and it changes whenever I want - only the reference is constant. That's the meaning of const in C++, C and a few more languages. In most other language, it just means that the reference stored in the cell corresponding to the variable is a const, just as you say. I don't think that's too bad, except when switching languages too often. > Scala is really lacking a way to easily support structural typing like typescript does. ES clearly wins here, since in Scala you have to define the case class in advance. And while you can just use maps, you give up typesafety. Scala has great support for structural typing. (One of it's main advantages IMHO), e.g.: def callSpeak[A <: { def speak(): Unit }](obj: A) { // code here ... obj.speak() }
  - valenterry 5y ago
    > That's the meaning of const in C++, C and a few more languages. In most other language, it just means that the reference stored in the cell corresponding to the variable is a const, just as you say. I don't think that's too bad, except when switching languages too often. Haha, I see - it's been a long time since I used C/C++. But n terms of general understanding and in the context of languages becoming more functional I still think that const is not a great choice. But you have a good point. > Scala has great support for structural typing. (One of it's main advantages IMHO), e.g.: I would not call this great support. If the support were really so good, there would be no or much less need for things like shapeless and chimney. In your example you make it so that you can pass any object that has a speak method and yeah, that works. But change the type of speak to Integer, add another one for string and then create (not pass!) a simple data-holding object that you can pass to it, without defining a case class first. Then the syntax is not so nice. And composition for these kind of things becomes tricky quickly.
- nikitaga 5y ago
  > Scala is really lacking a way to easily support structural typing like typescript does. ES clearly wins here, since in Scala you have to define the case class in advance. And while you can just use maps, you give up typesafety. Looking at it the other way, Typescript is really lacking nominal typing and the safety and simplicity that it provides. Structural typing isn't needed if you don't care about Javascript / dynamically typed coding patterns. But Typescript is optimized for exactly that, that's why it has structural typing. Personally I much prefer Scala's type system, it is very rare that I long for more dynamism than it affords, even though I've coded in and liked Javascript for years prior to that.
fy20 5y ago
In my dayjob we originally used Scala, but I pushed for a couple of new services to be written in TypeScript/Node as it was really hard to hire Scala developers. I'd say it worked well, we even took a somewhat functional approach to building things. We tried fp-ts but that was a bit hardcore (when you are trying to hire TypeScript developers who don't know functional programming), so just built Either and Option types which provided 99% of what we needed. There are still a few things I miss though: * Pattern matching and exhaustive checking. Using a switch statement it is possible to define a function that can emulate the compile-time exhaustive checking, but it's still rather weak compared to what you can do in Scala. * Implicits. Being able to define something that can convert say a UUID to a String or vice versa automatically just feels like magic, especially when dealing with data from third party systems. * Compiler macros and metaprogramming. It enables tools like Chimney (https://scalalandio.github.io/chimney/ https://scalalandio.github.io/chimney/) to be built, which I don't think are possible with TypeScript right now.
- rad_gruchalski 5y ago
  > as it was really hard to hire Scala developers This is by far the biggest problem of Scala. After Typesafe rebranding and dropping the ball as a main Scala supporting body, it all went downhill from there. Ehich is a shame as Scala is a solid language with very good features.
  - halfmatthalfcat 5y ago
    Never understood why they changed the name and still think “Lightbend” is an absolutely fucking awful name. Pisses me off to this day.
bern4444 5y ago
> Option, the type safe undefined I mean Scala because I guess it actually has it, but worth pointing out it's like 30 LOC to define one for JS, depending on how many convenience methods you want. Here's one I wrote: https://github.com/sbernheim4/excoptional https://github.com/sbernheim4/excoptional I fully believe it to be the best Option implementation for JS/TS

valenterry 5y ago

> Variables > ES6 wins, 'val' and 'var' are annoying close to each other. Disagree. I don't like either Scala nor ES - but "const" is really confusing. It implies that whatever we store is constant, but it's not. I can store a mutable object and it changes whenever I want - only the reference is constant. > Default, named and rest parameters > I'll give this one to ES6 because the spread syntax feels more intuitive than * at the end of a type. Not sure. If I imagine I come from a language without such a feature, then having "..." infront of the parameter seems confusing. "...args..." would be clearer. Having "Double*" is also a bit confusing, but I find that * is often used for such a situation (e.g. in regex) > Case classes > I mean I guess Scala but I still prefer polymorphism to pattern matching (please don't hurt me 2022 programmers) Scala is really lacking a way to easily support structural typing like typescript does. ES clearly wins here, since in Scala you have to define the case class in advance. And while you can just use maps, you give up typesafety.

zosima 5y ago
> Disagree. I don't like either Scala nor ES - but "const" is really confusing. It implies that whatever we store is constant, but it's not. I can store a mutable object and it changes whenever I want - only the reference is constant. That's the meaning of const in C++, C and a few more languages. In most other language, it just means that the reference stored in the cell corresponding to the variable is a const, just as you say. I don't think that's too bad, except when switching languages too often. > Scala is really lacking a way to easily support structural typing like typescript does. ES clearly wins here, since in Scala you have to define the case class in advance. And while you can just use maps, you give up typesafety. Scala has great support for structural typing. (One of it's main advantages IMHO), e.g.: def callSpeak[A <: { def speak(): Unit }](obj: A) { // code here ... obj.speak() }
- valenterry 5y ago
  > That's the meaning of const in C++, C and a few more languages. In most other language, it just means that the reference stored in the cell corresponding to the variable is a const, just as you say. I don't think that's too bad, except when switching languages too often. Haha, I see - it's been a long time since I used C/C++. But n terms of general understanding and in the context of languages becoming more functional I still think that const is not a great choice. But you have a good point. > Scala has great support for structural typing. (One of it's main advantages IMHO), e.g.: I would not call this great support. If the support were really so good, there would be no or much less need for things like shapeless and chimney. In your example you make it so that you can pass any object that has a speak method and yeah, that works. But change the type of speak to Integer, add another one for string and then create (not pass!) a simple data-holding object that you can pass to it, without defining a case class first. Then the syntax is not so nice. And composition for these kind of things becomes tricky quickly.
nikitaga 5y ago
> Scala is really lacking a way to easily support structural typing like typescript does. ES clearly wins here, since in Scala you have to define the case class in advance. And while you can just use maps, you give up typesafety. Looking at it the other way, Typescript is really lacking nominal typing and the safety and simplicity that it provides. Structural typing isn't needed if you don't care about Javascript / dynamically typed coding patterns. But Typescript is optimized for exactly that, that's why it has structural typing. Personally I much prefer Scala's type system, it is very rare that I long for more dynamism than it affords, even though I've coded in and liked Javascript for years prior to that.

fy20 5y ago

In my dayjob we originally used Scala, but I pushed for a couple of new services to be written in TypeScript/Node as it was really hard to hire Scala developers. I'd say it worked well, we even took a somewhat functional approach to building things. We tried fp-ts but that was a bit hardcore (when you are trying to hire TypeScript developers who don't know functional programming), so just built Either and Option types which provided 99% of what we needed. There are still a few things I miss though: * Pattern matching and exhaustive checking. Using a switch statement it is possible to define a function that can emulate the compile-time exhaustive checking, but it's still rather weak compared to what you can do in Scala. * Implicits. Being able to define something that can convert say a UUID to a String or vice versa automatically just feels like magic, especially when dealing with data from third party systems. * Compiler macros and metaprogramming. It enables tools like Chimney (https://scalalandio.github.io/chimney/ https://scalalandio.github.io/chimney/) to be built, which I don't think are possible with TypeScript right now.

rad_gruchalski 5y ago
> as it was really hard to hire Scala developers This is by far the biggest problem of Scala. After Typesafe rebranding and dropping the ball as a main Scala supporting body, it all went downhill from there. Ehich is a shame as Scala is a solid language with very good features.
- halfmatthalfcat 5y ago
  Never understood why they changed the name and still think “Lightbend” is an absolutely fucking awful name. Pisses me off to this day.

bern4444 5y ago

> Option, the type safe undefined I mean Scala because I guess it actually has it, but worth pointing out it's like 30 LOC to define one for JS, depending on how many convenience methods you want. Here's one I wrote: https://github.com/sbernheim4/excoptional https://github.com/sbernheim4/excoptional I fully believe it to be the best Option implementation for JS/TS