13 ms·

I am hopeful that Rust can achieve what Elm did not. I really fell in love with Elm early on, back when it was an experimental language for functional reactive

• bgorman 6y ago
  I don't understand why Rust is more compelling than ReasonML (OCaml). Reason is more expressive and on the web low level memory management isn't a concern.
  • nilkn 6y ago
    Isomorphic codebases. I would much rather use Rust on the back-end than ReasonML/OCaml.
    • smabie 6y ago
      Why's that? Ocaml has excellent performance and is a lot higher level than Rust. I personally see Rust as a language that really only should be used if utmost performance or hard latency requirements makes GC'd languages unsuitable. Most backends for web-app would run only marginally better with Rust than Ocaml and incur a steep productivity and maintenance penalty. A lot of people seem to be suggesting Rust as a GC language replacement instead of a C/C++/asm replacement, which I've never really got. Is the mutation/lifetime/pointer management really worth it for this kind of thing?
      • pjmlp 6y ago
        I think it stems from the root cause that many equate GC languages with heap allocation everywhere, and never got to learn properly how to do value allocations on the languages that offer language or library features to do such allocations.
  • StreamBright 6y ago
    I was wondering about that too. OCaml has a really good track record and the whole Bucklescript ecosystem also proven to be good for reliable frontend development.
• ronanyeah 6y ago
  As a longtime user of both, Rust has a long way to go on the frontend before I would consider switching.
• nickbauman 6y ago
  Clojure has been there as a fullstack language for a lot longer. It also fulfills the story that Elm was trying to do for much longer. And Reagent is a much needed improvement on React. The borrow-checker in Rust is kind of silly tool to use in the context of a managed language (that does GC) like Javascript. I don't get it. It's like using a backhoe to plant a few geraniums. Am I just not getting this?
  • deleted 6y ago
    [deleted]
  • keithasaurus 6y ago
    I don't see clojure in the same realm here. Both rust and elm are geared more toward enforcing correctness through their type systems to tame complexity in large projects. In my experience, clojure, being dynamic, fits more as a comparison to vanilla JavaScript. In a langauge-to-language comparison, I think clojure is somewhat more appealing than JavaScript due to immutability by default and general functional niceties. However, the fullstack comparison is not quite apples-to-apples as clojure (backend) is JVM and clojurescript (frontend) is node. While it works for some people, clojure feels awkward to me as a fullstack language.
    • nickbauman 6y ago
      Types provide only the simplest most trivial kinds of correctness, though. And people routinely make mistakes with types.
      • AlisdairO 6y ago
        Things like null safety aren't trivial for practical purposes IME.
        • nickbauman 6y ago
          Most Optional implementations are kinda terrible, though. They cost more than they save. If I have a function with a param and I release it with it required, but later I change it to be optional (loosening a requirement) does rust require everyone calling that function the old way to change their code? If so that not an improvement!
• azangru 6y ago
  I re-ally struggle to see the appeal of Rust for frontend web development over typescript. Perhaps there are some rare scenarios where you need to eek out every little bit of performance... But in normal circumstances, typescript offers a fantastic combination of familiarity, expressiveness and ... if not type-safety, then at least some degree of type-sanity.
  • danenania 6y ago
    There are major benefits to using the same language on backend and frontend though, especially with typed languages where you can share types. In my experience, this makes a much bigger difference than the specific language you choose. So the real question imo should be which is better considering both frontend and backend. I suppose it’s also a very project-specific question. Maybe a heavy frontend project = ts, while heavy backend = rust.
  • mplanchard 6y ago
    I would choose Rust over TS not for any performance characteristics, but because I strongly prefer it as a language, due in large part to features like pattern matching, sum types, exhaustiveness checking, traits, etc. I do quite like TS, but you can never really get away from the fact that you’re still limited by many historical JavaScript gotchas, and the type system is nowhere near as powerful as Rust’s. Edit: That being said, as a business decision, TS will often be a better pick because it’s so much easier to find talent, and the learning curve is much smaller.
    • chrfrasco 6y ago
      Sum types and exhaustiveness checking are doable with typescript! Though it's not especially ergonomic https://www.typescriptlang.org/play?#code/C4TwDgpgBAygrgWygXigbygMwPbYFxTABOcEANFAEYCGRBAzsQJYB2A5lAL5QA+6WuApmoAbetE4AoSZjgsAxsCbYWWFgAp6iAvAQBKBs3bpJUKPQDuTYPIAWUTYgB0ObHpNmz86uMIkIeKaeZkQQwHBEqloITjREQV4+0MJiAQmeoeGRUADkACYQwnAiwDnpBUUlgcFmcqHUdtSUIhCO+kFSUjJyisqqdRANtk0t6gAeBCwQAG4QRAZQU7NEHoS2RNgWixBbAKJEG0TqAAbevizYwFDDLHkteQQAJGhjnMd6kpxAA https://www.typescriptlang.org/play?#code/C4TwDgpgBAygrgWygX...
  • 6y ago
• wolfadex 6y ago
  Why not have tools that specialize and are strong in some areas instead of trying to have a Swiss Army Knife language? In other professions it's normal to have different tools for different tasks. Or is there something I'm missing? I personally would be happy with many different languages that are focused on front end development, like how we already have many that are focused on back end development.
• G4BB3R 6y ago
  I prefer to use languages in the domains they were designed for, and I think it's almost impossible to a general purpose language, or a system programming language, to be better in a domain-specific language that was designed with the right trade offs in mind. Elm having less abstraction-power and doesn't offering full interop with JS, was a design decision. For this reason, we have lots of high quality packages that makes sense to Elm, instead of bindings of JS libs. For the other side, I can't see any language being better at system programming than Rust.
  • tiffanyh 6y ago
    > “ I prefer to use languages in the domains they were designed for” So for web development, do you use PHP? Because neither Python, nor Ruby nor even JavaScript itself was designed for web development.
    • dec0dedab0de 6y ago
      JavaScript was definitely designed for web development. Though, at the time web development meant a tiny bit of magic in an otherwise static html document.
      • bhaak 6y ago
        I wouldn’t call “animating a piece of text” on a HTML page as “web development. 16 bit home computers could do this better 10 years before JS.
        • whatshisface 6y ago
          The crucial distinguishing factor is that JS was made to animate a bit of text... on every device in existence, past present or future. That's the biggest difference between the web and native.
          • riquito 6y ago
            The "every device in existence" fails with node, at example, which has a different standard library, and every browser support libraries and even syntax differently (which is why we backport stuff with tools like babel)
• Tarq0n 6y ago
  I noticed Elm is listed as an inspiration by a number of Rust front-end frameworks (seed and iced for instance). It seems a lot of people feel the same in the Rust community.
• ghostwriter 6y ago
  > It was an outgrowth of failed experiments in FRP from the Haskell world I'd like to hear more about this failed experiment. Reflex is alive and active and perhaps is the best tool out there for fullstack applications.
  • Ericson2314 6y ago
    As someone who uses Reflex at work and has also written a bunch of Rust, I wish Rust the best but am highly skeptical it's going to be a productive tool, and not just nerd-fodder, for user interfaces. Reflex is distilled mutation and week reference black-magic, and the safe interface it provides relies heavily on higher kinded types. Even if someone goes though all the trouble to implement it or something like it (And that would be cool!), I don't think the resulting algorithms can be packaged up in nice abstractions. Rust is a great language, but it just shouldn't bother competing where GC will do. It's just no point trying to win a race with that handicap. ------ I do believe in "one language for all tasks", actually. It's just that one language will have split ecosystems as it will support many idioms that don't interoperate well. Put another way, let's start with "multiple languages, perfect type-safe FFI", and then go for endosymbiosis.
• giancarlostoro 6y ago
  > I am hopeful that Rust can achieve what Elm did not. I am hopeful we can see the web ecosystem evolve into being capable of 'Single Language Web Applications' like Rust seems to be capable of, and C# as well. Of course there's Flutter, but it seems to just pain on a canvas instead of reusing the DOM.
• Parazitull 6y ago
  For anyone looking for an Elm like experience but without the limitation imposed by its creator, take a look at Elmish, a port of the Elm architecture in F#. Advantages: You can use F# on the front and backend. Pretty good js interop with a lot of opportunities to shoot yourself in the foot. Disadvantages: You will probably need to use the Elm docs/tutorials to learn about Elmish.
• smabie 6y ago
  Im not sure Rust provides a lot of value for web development. Instead of Rust, use something like OCaml which has a nice front and backend story. It's certainly going to be a lot less work than using Rust. And more functional to boot.