5 ms·

I don't get the push for rust as a front-end language, it's very distracting with a lot of low-level features. Can we just stick with "best tool for the job"?

by nsonha 5y ago

I don't get the push for rust as a front-end language, it's very distracting with a lot of low-level features. Can we just stick with "best tool for the job"? Rust for performance-critical systems and, say, typescript for front-end? Using a single language for everything is a wet dream that always ends up in complexity and more work as you're fighting the "native" ecosystem.

VWWHFSfQ 5y ago
what if I don't like typescript
- nim2020 5y ago
  you can write your frontend in whatever you want, for example using yew...
- twobitshifter 5y ago
  Don’t use a web based app stack?
- nsonha 5y ago
  I don't know, pick a better high level language: kotlin, swift, f#
  - deleted 5y ago
    [deleted]
whimsicalism 5y ago
Maybe you should spend like 5 minutes looking into the thing you're critiquing before critiquing it? Just a suggestion, given that Tauri literally uses typescript for front-end.
- nsonha 5y ago
  did spend 5 mins, saw absolutely no code so I made some assumption. Maybe they should make better docs that don't require 5 mins+ to figure that out.
  - whimsicalism 5y ago
    Okay, so make a top-level comment critiquing their docs, rather than making an incorrect assumption and then critiquing it. You don't need to offer a perspective on everything, and I prefer the critiques I read to be well-founded.
adamnemecek 5y ago
When WASM becomes a dominant platform, all the performance-critical features will become very important.
- abeltensor 5y ago
  WASN will always need some kind of javascript glue to interact with the DOM.
  - adamnemecek 5y ago
    I think that eventually, people will roll their own GUIs without using DOM.
parker-codes 5y ago
The paradigm of Tauri is to pick the "best tool for the job". Bring your own frontend tech (JS, TS, RustWasm, etc).
ironmagma 5y ago
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
jdright 5y ago
You know, there are people like me that just can't stand Javascript. TypeScript is somewhat acceptable, but knowing Rust, I just prefer to use it anyway. It is just better.

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.
    - oscargrouch 5y ago
      Its unnecessary complexity for the paradigm we are talking about, that is user facing, mostly UI applications. Its necessary for system programming, and as we can see people talk about it whenever C++, C, OSes, Browsers, Games, etc.. are being talked about because it works really well in those domains. But when you are building a UI, C#, Kotlin, Swift, Typescript and even Java are much more productive with good speed, safe (even safer than Rust), and with language constructions that map really well to this domain. Rust achieved a very good set of features, but unfortunately the price is its complexity, which is a burden you don't need to take when you are creating UI's. Sure you and i (im mostly a C++ dev) can use it to make UI's, but unless you are creating something really complex that needs every drop of performance and memory, like big Games or a Photoshop, you don't need this productivity and HR tax(its much harder to find people in C++ and Rust) that languages like Rust and C++ ask of you. There's no such a thing as one language to rule them all, and Rust will not the best candidate for domains it was not designed for. Swift for instance is much better at this and with a very good performance, where it would also be a good fit for a Photoshop clone or a browser.
      - ironmagma 5y ago
        It's strange that some people view UIs as being some of the simplest software. Once you've considered the state management, asynchronous nature (meaning your code could be run in many different permutations), graphical elements (graphics' complexity upper bound being equivalent to what you might see in a video game), legacy APIs (old browsers, shims, or old OSes), and IO such as network requests, it ends up being incredibly complex. The number of hours I've seen being spent fighting Webpack are uncounted. From where I'm standing, it's clear the complexity is already there, it's just totally unmanaged. Rust will make a great UI language once the ecosystem has matured and async has gotten polished more. If upgrading the "Webpack" of the future meant just resolving compiler errors, we would be in a much better world. Same goes for upgrading dependencies on the frontend, which at my company becomes a blocker every 2 weeks or so due to the NPM security advisories being released, accompanied by the total lack of visibility into the dependencies' interplay that the Node ecosystem gives you.
        oscargrouch 5y ago
        I'm not saying that Rust is not a good language for UI, and im also not saying UI is simple. The problem is that you are just comparing it to JavaScript which is untyped and easy to beat. In my case i'm comparing it with languages that are also powerful, safe, fast and more well designed for this kind of scenario, which JavaScript or Python aren't. But if i had just two picks, between JavaScript or Rust, of course i would choose Rust without blinking. But once there is more options.. (in this case you can read my comments above). And i agree with you, that if you sum it all, maybe you get more productive (as in ready to ship) in Rust than with JavaScript.
        ironmagma 5y ago
        Sure, those other languages would be fine, but they all have their own severe downsides.. C# - requires an obscure runtime (Mono) on most platforms Kotlin - suffers from JVM's infamous GC pauses and startup time Swift - not open source (not SwiftUI, the good part) TypeScript - mostly same problems as JavaScript Java - same problems as Kotlin No one has managed to do open source cross-platform development well yet IMO. I'd be happy to be proven wrong.
- nsonha 5y ago
  Could you re-read my comments, I think go is a very lame language, at no point I said it would be good for anything. You're not convincing anyone by picking on low bar like C#, javascript & go to make rust seem like a good language for UI programming.
ironmagma 5y ago
I would disagree. Types like `Result<T,E>` or `Option<T>` exist purely for the user; the compiler doesn't care that there is a convention for errors, nor would it be that bad for a compiler to have `nil` (there are certainly a bunch of compilers that can handle it). There are a number of convenience types available such as `Rc` which does reference counting. If `Rc` didn't exist, you could still survive and write the same applications, it's just that it would be more cumbersome.