4 ms·

In a statically compiled language, when APIs change, you get compile errors that show up at build time. It's usually pretty obvious. With dynamically typed erro

In a statically compiled language, when APIs change, you get compile errors that show up at build time. It's usually pretty obvious. With dynamically typed errors, you get weird run-time failures that can be well hidden until you trigger a use case that actually needs the bit that changed. That combined with poor test coverage means a lot of potential for things to slip through build and QA processes. I use Kotlin, both on the JVM and in the browser (via kotlin-js). Dependencies are equally complex as in javascript but it's much easier to find out if stuff breaks or not. I update often to minimize the amount of changes I have to deal with. This may sound counter intuitive but integration testing small deltas is exponentially easier and less risky than big deltas. My attitude to having big updates lurking is that they represent technical debt. Just because you don't know you have a problem because you haven't updated yet doesn't mean you don't have a problem. By not updating, you just increase your ignorance of technical debt. It might be piling up without you realizing. And you might be making things worse by working against obsolete APIs. Upgrading libraries often means I typically only have to deal with a handful of minor updates for libraries that are mostly unproblematic. And if stuff breaks, it's easier to pin point the source of the breakage. And I find out as early as possible about problems I need to deal with. If I don't know about it, I can't deal with it either. Sometimes downgrading a library temporarily is needed. But then you document why and stay on top of issue trackers and upstream development to see when you can upgrade or you start looking for alternatives. Occasionally, some API breaking changes happen and then I fix it (because the compiler tells me stuff is not compiling). If I don't update for a year, I probably have a lot of breakage on my hands and a lot of work fixing things. Much harder and much more time consuming. And risky. All I know then is that I probably have a lot of problems (i.e. technical debt) on my hands that I don't know about.

rezonant 3y ago
Friends don't let friends write raw JavaScript. Typescript nearly eliminates the problem you bring up, when used correctly.
- jillesvangurp 3y ago
  That's why I use kotlin-js. It's like typescript with the training wheels removed. I always joke that typescript is a bit of a gateway drug for web developers that know javascript to actually get into other languages. Kotlin-js is a bit of a niche thing of course and soon going to be obsoleted by Kotlin's wasm compiler. But kotlin-js actually works very nicely. Just like typescript, it's a transpiler. Unlike typescript, it does not really have a non strict mode (except for the dynamic keyword so you can deal with some js libraries and its weird type system).
  - rezonant 3y ago
    Fun, all the power to ya on that. I've done a bunch of Kotlin for Android and although I initially didn't like a lot of how it does syntax, it has grown on me a lot. It is definitely a language that is focused on correctness and convenience. That being said, there isn't too much about Kotlin I miss when I write Typescript in strict mode. > Unlike typescript, it does not really have a non strict mode (except for the dynamic keyword so you can deal with some js libraries and its weird type system). Why is the existence of non-strict mode a concern for you if you are using strict mode? After all, whether you are using Typescript or kotlin-js, you are likely to have JS dependencies, and those might not be written with Typescript strict mode. I guess you could just opt not to use any "native" (Javascript) dependencies and just do it all in Kotlin JS, but beyond a certain point that's not very practical.
    - jillesvangurp 3y ago
      Strictness should not be optional. A lot of typescript projects don't use all the features. I've been on projects where people were just working around those features to do all the crazy hacks javascript is famous for; or to be able to use libraries that use those hacks. It's a constant fight to push back that madness. With Kotlin, that's just much less of a concern. Having a language that just says no to all of that is valuable. IMHO typescript could just remove the option to turn off the strict mode and always be strict. It would be a better language. It's impractical of course because a lot of stuff would break. That's the problem with it. Don't get me wrong, I've actually used typescript and don't mind it. But I prefer kotlin. I do indeed do a lot in Kotlin-js rather than using javascript libraries. We make a few exceptions for libraries like map-libre for which we have a very thin hand crafted Kotlin facade. Things like react we simply don't use at all (we use a pure kotlin framework called fritz2). We actually use a lot of Kotlin multi platform libraries as well. And even some wasm libraries (e.g. sqlite). Most of the foreign code dependencies in our codebase are not javascript libaries.
leptons 3y ago
>With dynamically typed errors, you get weird run-time failures that can be well hidden until you trigger a use case that actually needs the bit that changed. Maybe you've never heard of "writing tests"? If you update a dependency, and the dependency has a breaking change, your tests will fail. It's really that simple, and this should be the same in any language, not just Javascript.

rezonant 3y ago

Friends don't let friends write raw JavaScript. Typescript nearly eliminates the problem you bring up, when used correctly.

jillesvangurp 3y ago
That's why I use kotlin-js. It's like typescript with the training wheels removed. I always joke that typescript is a bit of a gateway drug for web developers that know javascript to actually get into other languages. Kotlin-js is a bit of a niche thing of course and soon going to be obsoleted by Kotlin's wasm compiler. But kotlin-js actually works very nicely. Just like typescript, it's a transpiler. Unlike typescript, it does not really have a non strict mode (except for the dynamic keyword so you can deal with some js libraries and its weird type system).
- rezonant 3y ago
  Fun, all the power to ya on that. I've done a bunch of Kotlin for Android and although I initially didn't like a lot of how it does syntax, it has grown on me a lot. It is definitely a language that is focused on correctness and convenience. That being said, there isn't too much about Kotlin I miss when I write Typescript in strict mode. > Unlike typescript, it does not really have a non strict mode (except for the dynamic keyword so you can deal with some js libraries and its weird type system). Why is the existence of non-strict mode a concern for you if you are using strict mode? After all, whether you are using Typescript or kotlin-js, you are likely to have JS dependencies, and those might not be written with Typescript strict mode. I guess you could just opt not to use any "native" (Javascript) dependencies and just do it all in Kotlin JS, but beyond a certain point that's not very practical.
  - jillesvangurp 3y ago
    Strictness should not be optional. A lot of typescript projects don't use all the features. I've been on projects where people were just working around those features to do all the crazy hacks javascript is famous for; or to be able to use libraries that use those hacks. It's a constant fight to push back that madness. With Kotlin, that's just much less of a concern. Having a language that just says no to all of that is valuable. IMHO typescript could just remove the option to turn off the strict mode and always be strict. It would be a better language. It's impractical of course because a lot of stuff would break. That's the problem with it. Don't get me wrong, I've actually used typescript and don't mind it. But I prefer kotlin. I do indeed do a lot in Kotlin-js rather than using javascript libraries. We make a few exceptions for libraries like map-libre for which we have a very thin hand crafted Kotlin facade. Things like react we simply don't use at all (we use a pure kotlin framework called fritz2). We actually use a lot of Kotlin multi platform libraries as well. And even some wasm libraries (e.g. sqlite). Most of the foreign code dependencies in our codebase are not javascript libaries.

leptons 3y ago

>With dynamically typed errors, you get weird run-time failures that can be well hidden until you trigger a use case that actually needs the bit that changed. Maybe you've never heard of "writing tests"? If you update a dependency, and the dependency has a breaking change, your tests will fail. It's really that simple, and this should be the same in any language, not just Javascript.