5 ms·

I would guess whatever you do on top of typescript, its still a superset of javascript, which will always have holes in it. Its that 100% guarantee that the aut

by jdance 7y ago

I would guess whatever you do on top of typescript, its still a superset of javascript, which will always have holes in it. Its that 100% guarantee that the author is looking for, and that Elm provides. The difference between 99% and 100% is enormous in my experience. A part of your brain that constantly evaluated the situation can now be totally at rest, spending that energy at other things. Note that I have not used Elm myself, but looking at it I get the point. I have the 99/100% experience in other things

tekkk 7y ago
Yes, precisely so. Type definitions are as good as the programmers who wrote them, and since humans are imperfect they make mistakes. After you have defined your types wrong, there are devious bugs in your code that you have no way of knowing (until you step on that mine and the program hopefully crashes). Although every language by design is mostly bug-free, it's that in JS/TS there is a much greater human factor (similar to C/C++) that just adds a large error margin for the correctness of the application. Especially when there are very loose runtime guarantees for type-safety, there is always a chance for something ugly to happen.
Touche 7y ago
Doesn't Rust have unsafe?
- Sindisil 7y ago
  Your point being?
  - Touche 7y ago
    You don't have a 100% guarantee if unsafe is being used.
    - cinnamonheart 7y ago
      Among others, Haskell has bottom, unsafeCoerce, unsafePerformIO, and Data.Dynamic. Even in the dependently typed Agda, you have postulates and pragmas like NON_TERMINATING and NO_POSITIVITY_CHECK. Is there any language out there with no unsafe hatches? Even in the most rigorous languages I'm aware of, I don't think 100% guarantees exist. Some languages get a lot closer than others, though -- I think Elm, Rust, Haskell, and so on are still a big improvement over the status quo of languages. I'd rather get 90% of the way there than 10%.
      - Touche 7y ago
        I don't disagree, seems weird that the author made such a big deal of the 99% vs 100% thing when 100% is not something Rust has.
    - Sindisil 7y ago
      No. But you the areas of unsafety are explicitly indicated, of limited scope, and not the default. Also, even in unsafe code, Rust offers more guarantees than many (most?) languages.
      - Touche 7y ago
        So not 100%. Kind of defeats the argument, imo. Now we're just talking about shades of grey.
Fellshard 7y ago
This is especially true when it comes to working with JS libraries. Since no two libraries or JS developers have the same set of ideas for how the language's components work and fit together - how objects are intended to be used, standard ordering of arguments, whether to use a functional or an OO style, etc. - your application will be torn between the dozens of wildly different libraries you end up selecting, or worse, by those you have no choice but to select. Every crack in JS will be pulled wide open by that tension, and even TS' attempt at some normalization will not fully erase that.
- hombre_fatal 7y ago
  Sounds like every language I've used, from Python to Java to Rust. JS actually has an improvement to offer here with its async-everything concurrency model taking away one degree of ecosystem fragmentation.
  - Fellshard 7y ago
    No. In general, there is a sense among Python coders of at least concrete schools of thought for these kinds of abstractions. Java certainly is looser, since it never clung tightly enough to 'pure OO' principles. Rust is young, and - I expect - is still developing its standard idioms and common abstractions, though it has certainly settled on a broad swathe of it already, and holds strong opinions on what good Rust code looks like. If I asked something similar of Javascript, you would see very little commonality between people. It's designed as a Self-y language with functional leanings, and gives far too unopinionated and broad a leeway to nudge its developers in any one direction. Furthermore, early browser APIs for JavaScript - especially when it came to features like window and cookie interaction - pulled the rug out from under every reasonable abstraction the language could have been geared towards, choosing unreasonable over reasonable abstractions. This leaves the language where it is now - incohesive, incoherent, unsound when it comes to stitching multiple parts together, because each developer behind each of those components has a wildly different perception of how the JavaScript world 'ought to work'.

by jdance 7y ago

tekkk 7y ago

Yes, precisely so. Type definitions are as good as the programmers who wrote them, and since humans are imperfect they make mistakes. After you have defined your types wrong, there are devious bugs in your code that you have no way of knowing (until you step on that mine and the program hopefully crashes). Although every language by design is mostly bug-free, it's that in JS/TS there is a much greater human factor (similar to C/C++) that just adds a large error margin for the correctness of the application. Especially when there are very loose runtime guarantees for type-safety, there is always a chance for something ugly to happen.

Touche 7y ago

Doesn't Rust have unsafe?

Sindisil 7y ago
Your point being?
- Touche 7y ago
  You don't have a 100% guarantee if unsafe is being used.
  - cinnamonheart 7y ago
    Among others, Haskell has bottom, unsafeCoerce, unsafePerformIO, and Data.Dynamic. Even in the dependently typed Agda, you have postulates and pragmas like NON_TERMINATING and NO_POSITIVITY_CHECK. Is there any language out there with no unsafe hatches? Even in the most rigorous languages I'm aware of, I don't think 100% guarantees exist. Some languages get a lot closer than others, though -- I think Elm, Rust, Haskell, and so on are still a big improvement over the status quo of languages. I'd rather get 90% of the way there than 10%.
    - Touche 7y ago
      I don't disagree, seems weird that the author made such a big deal of the 99% vs 100% thing when 100% is not something Rust has.
  - Sindisil 7y ago
    No. But you the areas of unsafety are explicitly indicated, of limited scope, and not the default. Also, even in unsafe code, Rust offers more guarantees than many (most?) languages.
    - Touche 7y ago
      So not 100%. Kind of defeats the argument, imo. Now we're just talking about shades of grey.

Fellshard 7y ago

This is especially true when it comes to working with JS libraries. Since no two libraries or JS developers have the same set of ideas for how the language's components work and fit together - how objects are intended to be used, standard ordering of arguments, whether to use a functional or an OO style, etc. - your application will be torn between the dozens of wildly different libraries you end up selecting, or worse, by those you have no choice but to select. Every crack in JS will be pulled wide open by that tension, and even TS' attempt at some normalization will not fully erase that.

hombre_fatal 7y ago
Sounds like every language I've used, from Python to Java to Rust. JS actually has an improvement to offer here with its async-everything concurrency model taking away one degree of ecosystem fragmentation.
- Fellshard 7y ago
  No. In general, there is a sense among Python coders of at least concrete schools of thought for these kinds of abstractions. Java certainly is looser, since it never clung tightly enough to 'pure OO' principles. Rust is young, and - I expect - is still developing its standard idioms and common abstractions, though it has certainly settled on a broad swathe of it already, and holds strong opinions on what good Rust code looks like. If I asked something similar of Javascript, you would see very little commonality between people. It's designed as a Self-y language with functional leanings, and gives far too unopinionated and broad a leeway to nudge its developers in any one direction. Furthermore, early browser APIs for JavaScript - especially when it came to features like window and cookie interaction - pulled the rug out from under every reasonable abstraction the language could have been geared towards, choosing unreasonable over reasonable abstractions. This leaves the language where it is now - incohesive, incoherent, unsound when it comes to stitching multiple parts together, because each developer behind each of those components has a wildly different perception of how the JavaScript world 'ought to work'.