5 ms·

Normally I'm on the defensive side for the JS ecosystem on Hacker News, but not today. While it's still the best option for web app development productivity rig

Normally I'm on the defensive side for the JS ecosystem on Hacker News, but not today. While it's still the best option for web app development productivity right now, there are woefully bad issues with the Node ecosystem, from poor or lack of documentation for complex build tools to zero contracts between dependencies. Rust has the advantage of being able to break if things seem to not fit together. It's a popular language for more use-cases than just performance-critical applications even if it supports that.

nsonha 5y ago
> zero contracts between dependencies. Isn't typescript contract? This is not really about JS, if I want to replace JS I'll pick a language with similar characteristics that make it successful. Similar to how you replace C++ with rust, another language that gives you control of memory. For app developments they are simplicity and a focus on domain modelling with a good type system (this is typescript teritory), NOT memory safey. And don't tell me that rust's type system is powerful too, yes, but it's also complex and the focus isn't domain modelling. Like C++ and golang's type systems, it's there to aid the compilers/borrow checker, not developers. Example of such language in my other comment: kotlin, F#
- ironmagma 5y ago
  I think Typescript won't check that two of your dependencies are compatible with each other; it will only check that your app is compatible with dependencies. Even then, the check isn't very strong, since TypeScript operates on a "as you want it" basis, which is nice in some ways but also means you could get overly permissive behavior, especially if you're using third party typings, which is fairly common. > the focus isn't domain modelling, like C++ and golang's type systems Could you please explain what you mean by this? I've honestly not heard this argument before so I'd be interested what domain modeling Rust doesn't encourage/support that, e.g. Go does.
  - nsonha 5y ago
    I'm not saying that go and C++ have better type systems. I'm saying like rust, their type systems are built to aid the compiler. High-level languages like ocaml or f# have type systems made for domain modeling
    - Zababa 5y ago
      I'm not sure I understand your point. Rust has ADTs, like OCaml and F#, and Go doesn't. Rust can be written almost like OCaml and F#, Go can't.
      - oscargrouch 5y ago
        His point is that Rust is not user-friendly with a unnecessary cognitive load for user facing applications. I don't know why this comment section derails into the language properties and technical merits, giving its pretty simple to recognize that. The HN crowd might be above average and might tend to think that Rust is an easy enough language, but the reality for most people is that languages with the amount of complexity of the likes of Rust, C++ and Scala are not easy for the "average programmer" and we are not even talking about the people that just don't want to deal with unnecessary complexity. Really, almost any GC'ed language out there is a better pick for this sort of task (except the ones that are poorly designed for this, like Go).
        ironmagma 5y ago
        The point is not to be "easy;" environments that value being easy are environments that encourage bugs. The whole ethos of Rust is safety and thoroughness. True, it's not as user-friendly, if your definition of user friendly is "runs at any cost." If instead however you take the definition as "allows you to easily write programs that work right," it is probably one of the easiest languages. You speak of "unnecessary complexity" like the complexity was just pulled out of thin air for the purpose of making Rust harder; no, the complexity is inherent to building a functioning application, the difference is whether it lives in your head or it lives in the compiler. Personally I'd rather the compiler handle things like bookkeeping, moving memory around, checking that the types and cardinalities are right, and ensuring errors are handled rather than repeatedly having to debug those things at runtime in an extremely slow and punishing feedback loop.

nsonha 5y ago

> zero contracts between dependencies. Isn't typescript contract? This is not really about JS, if I want to replace JS I'll pick a language with similar characteristics that make it successful. Similar to how you replace C++ with rust, another language that gives you control of memory. For app developments they are simplicity and a focus on domain modelling with a good type system (this is typescript teritory), NOT memory safey. And don't tell me that rust's type system is powerful too, yes, but it's also complex and the focus isn't domain modelling. Like C++ and golang's type systems, it's there to aid the compilers/borrow checker, not developers. Example of such language in my other comment: kotlin, F#

ironmagma 5y ago
I think Typescript won't check that two of your dependencies are compatible with each other; it will only check that your app is compatible with dependencies. Even then, the check isn't very strong, since TypeScript operates on a "as you want it" basis, which is nice in some ways but also means you could get overly permissive behavior, especially if you're using third party typings, which is fairly common. > the focus isn't domain modelling, like C++ and golang's type systems Could you please explain what you mean by this? I've honestly not heard this argument before so I'd be interested what domain modeling Rust doesn't encourage/support that, e.g. Go does.
- nsonha 5y ago
  I'm not saying that go and C++ have better type systems. I'm saying like rust, their type systems are built to aid the compiler. High-level languages like ocaml or f# have type systems made for domain modeling
  - Zababa 5y ago
    I'm not sure I understand your point. Rust has ADTs, like OCaml and F#, and Go doesn't. Rust can be written almost like OCaml and F#, Go can't.
    - oscargrouch 5y ago
      His point is that Rust is not user-friendly with a unnecessary cognitive load for user facing applications. I don't know why this comment section derails into the language properties and technical merits, giving its pretty simple to recognize that. The HN crowd might be above average and might tend to think that Rust is an easy enough language, but the reality for most people is that languages with the amount of complexity of the likes of Rust, C++ and Scala are not easy for the "average programmer" and we are not even talking about the people that just don't want to deal with unnecessary complexity. Really, almost any GC'ed language out there is a better pick for this sort of task (except the ones that are poorly designed for this, like Go).
      - ironmagma 5y ago
        The point is not to be "easy;" environments that value being easy are environments that encourage bugs. The whole ethos of Rust is safety and thoroughness. True, it's not as user-friendly, if your definition of user friendly is "runs at any cost." If instead however you take the definition as "allows you to easily write programs that work right," it is probably one of the easiest languages. You speak of "unnecessary complexity" like the complexity was just pulled out of thin air for the purpose of making Rust harder; no, the complexity is inherent to building a functioning application, the difference is whether it lives in your head or it lives in the compiler. Personally I'd rather the compiler handle things like bookkeeping, moving memory around, checking that the types and cardinalities are right, and ensuring errors are handled rather than repeatedly having to debug those things at runtime in an extremely slow and punishing feedback loop.