7 ms·

Every so often a language comes out that allows frontend developers to put something other than "JavaScript developer" on their CV. First CoffeeScript, then Fl

• VWWHFSfQ 4y ago
  My company did an initial evaluation of Rust web development just to see what the options were. Put out some feelers to our web developers to see if they had any opinions about it. It was almost universally negative. Not because the ecosystem or technology is immature, but because our JavaScript/Typescript devs simply could not grok Rust at all. It was too different, or too difficult, or whatever. So we didn't really pursue it any further. At some point though we'll probably just have to hire Rust engineers instead of trying to convert JS devs.
  • bayesian_horse 4y ago
    Rust engineers coming from a different niche than frontend development will just LOVE web development.
    • voidfunc 4y ago
      Maybe the web ecosystem will finally get some sane tooling... or not because those devs will probably be driven to madness.
      • illiarian 4y ago
        Funnily enough, web ecosystem has tooling most languages can't even dream of. - Instant hot reload of application - Inspect app/page structure in runtime - Runtime debugging - Monitor all network requests - Tools to monitor time spent in functions, painting, redrawing... - Runtime changes instantly applied ...
        • camdenreslink 4y ago
          Many languages have all of that tooling and more. For example C# and Java. I think Rust has all of that except the hot reload and runtime changes.
          • illiarian 4y ago
            > Many languages have all of that tooling and more. For example C# and Java. Instant hot reloading? Runtime introspection into apps, and into strucutre of the apps, direct view into what the app sends over the network etc.? Open up development tools in your favorite browser, you'll be surprised :)
            • blackoil 4y ago
              Don't know of current state but Blazor should check most of them.
              • illiarian 4y ago
                Because Balzor piggy-backs the existing web tools ;)
            • kaba0 4y ago
              Well, java in debug mode can hot swap class methods, for what it worth. But the web is definitely the most used “GUI framework” ever, so there is no competition with that on tooling ground, even if there is nothing inherently that would block it, as a dom inspection is pretty easy to implement - just print out the tree of ui nodes.
        • Ygg2 4y ago
          At expense of browsers complexity rivaling operating systems. And now there is essentially one browser who can afford such complexity. Until Google discontinues it.
          • chrisco255 4y ago
      • Uehreka 4y ago
        You make a good point, I’ve been saying for years that hot reload is too fast. Rust compile times really give you time to meditate and reflect.
      • rk06 4y ago
        What sane tooling are you talking about? FE projects takes minutes to build while backend projects can take hours.
    • jvanderbot 4y ago
      Yeah, the closest I'd come is writing a server less endpoint in Rust or Cpp.
  • candiddevmike 4y ago
    What compelling reason do you have for wanting another team to use Rust instead of JS?
    • VWWHFSfQ 4y ago
      It was just an exploration to see if there was anything we were missing out on.
      • candiddevmike 4y ago
        That: > It was just an exploration to see if there was anything we were missing out on. Doesn't square with this: > At some point though we'll probably just have to hire Rust engineers instead of trying to convert JS devs. Reads like rust exceptionalism.
        • VWWHFSfQ 4y ago
          If we find that at some point we're missing out on something great with Rust/WASM then we'll hire Rust engineers and not just assume that our javascript developers can do it. That was the point.
  • oaiey 4y ago
    Rust on wasm is the same story as .net on wasm (aka blazor): it is nice if you have a single language developer workforce. But once you maintain a portal team, the benefit is gone. IMHO, the more interesting niche is desktop/mobile apps using html as a toolkit. Because here you can combine raw computing/resource access with being more cross platform.
  • govolckurself 4y ago
    [flagged]
    • CapsAdmin 4y ago
      Most web devs are familiar with javascript and typescript and are currently easily able to create products and solve problems for companies. They are much easier to find and hire compared to rust developers. So why should a company hinder its own productivity by trying to find rust developers because rust is technically safer in some ways? Or risk ruining the culture of its currently functional developers by forcing them to use rust?
• francisofascii 4y ago
  I would have said only TypeScript has been successful, despite it being backed by Microsoft. ;) (I like MS, but just know many who don't.)
  • illiarian 4y ago
    Microsoft is the only company that developed multiple successful languages. They know how to create languages for everything. No one is even close.
    • shrimp_emoji 4y ago
      I guess MSVC is the worst compiler out of spite that they didn't create C or C++.
    • tough 4y ago
      Microsoft has this exceptional engineer on payroll Anders Hejlsberg, lead architect of C# and creator of Delphi and Turbo Pascal, has worked on the development of TypeScript.
• myth_drannon 4y ago
  You forgot ClojureScript, ScalaJS, Elm. All were moderately successful in their own niche (Clojure or Scala dev shops).
  • fulafel 4y ago
    This should be present tense, at least in the ClojureScript case. Recent cool developments on that side include Electric Clojure - generating transparently state passing front and backend code from a single DSL: https://github.com/hyperfiddle/electric https://github.com/hyperfiddle/electric
    • erichocean 4y ago
      Electric Clojure is insane, having a ton of fun playing with it.
• MuffinFlavored 4y ago
  > This is not a dig at Rust (which I love) but God help any developer inheriting a frontend codebase with random bits of Rust in 2024. Why? Rust has a bunch of features built in to promote "good code", no?
  • oaiey 4y ago
    Rust is a unmanaged language. 99% of use cases do not need it and 99% of devs are unable to handle it's.
    • MuffinFlavored 4y ago
      > Rust is a unmanaged language. Not quite sure what you mean. I've written some pretty cool stuff in Rust and never had to do any free() / drop()?
      • kaba0 4y ago
        Most modern C++ code bases also completely lack explicit frees/deletes, but not many would argue that C++ is a managed language. Though a more objective distinction is hard to give on what is a managed language, I found the garbage collection handbooks’ quote on the topic the most illuminating (linking to my older comment): https://news.ycombinator.com/item?id=35332600 https://news.ycombinator.com/item?id=35332600 In Rust and in C++ memory layout is part of your public APIs and has to be refactored when it changes. This is not the case with managed languages.
  • augusto-moura 4y ago
    The problem is not "bad code", but experience from teams and community. Browsing HN might make we think that Rust is everywhere and everyone knows it, but most of the frontend developers in the world are not prepared to inherit a project in such a foreign language. My theory is that, you probably can see when a language its being picked by some community by looking into courses available, either free or on paid platforms
• jerf 4y ago
  "Rust with WASM & web macros." It's not really that; it's really just WASM. There's going to be a flood of this sort of thing from all sorts of languages, even multiple per language. It's early days yet and the ground is still being felt out, but eventually the Javascript qua Javascript foundation in the browser is going to be breached and a day will come when it is a minority language (still many years from now), for exactly the same reason that never in the whole history of computing has one general purpose programming language "won". Per https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... , Javascript is going to "win", but it's going to be Javascript in its incarnation as WASM, not the Javascript we know today. "random bits of Rust in 2024." And that's "the ground being felt out", not a fundamental problem. I expect to see WASM frameworks develop that are shipped out to the world as WASM and bind to any language. Decent odds they'll be developed in Rust for several reasons (performance not least of all), but you won't need to know that to use it in your Python WASM front-end app or some new WASM-primary language that is nothing more than a gleam in its creator's eye right now. If you don't want the chaos, hey, great. Even people who live on the cutting edge can't be cutting edge in every dimension. By all means sit back and watch from a distance. But these problems will certainly be fixed.
  • muglug 4y ago
    The enemy of this entire thesis is the layers of additional complexity required by such “innovation”. Each layer has its own API and update mechanisms, all of which slow down developer productivity (especially when inheriting a project you did not build). In some cases that complexity is worth it — Figma, for example, squeezes a lot of value from WASM. I myself have used WASM to create a browser-based testing environment for a Rust-based static analysis tool I’ve built, so my colleagues can quickly repro issues. But for most web development, it’s not worth it.
    • jerf 4y ago
      In the long term, I expect WASM to start blowing away layers of the browser, precisely because of this problem. It may be another 20 years, but it's going to happen. To put it another way, no, you're not wrong, and yes, the resistance to large-scale changes to the web stack is huge, arguably the largest resistance of all time. Nevertheless, the amount of metaphorical amperage flowing through is even larger and is large enough that it is already "short circuiting" and blasting a new circuit through. It's going to take a while, and the backwards compatibility will be with us for a while, but we're already seeing flashes of websites where you don't need to know the old CSS and HTML and such because they're actually WebGL and WASM. As more capabilities are exposed to WASM and they become more efficient, more and more stuff will be moved into it. That will cause its own explosion problem, but it'll be handled. It's not like every website is going to write its own bespoke text renderer every single time. And in the end there are some technologies that will fade out and become legacy, then irrelevant. I may yet outlive the HTML/CSS/JS stack.
• nosianu 4y ago
  > then Flow and TypeScript Neither one is a different language. Both merely add type annotations to an otherwise pristine ECMAScript code base. Typescript has some very few and minor and no longer needed things, like enums or namespaces, that need to be transpiled and are not part of ECMAScript. But again, those are minor and you no longer need them (since ES 2015 one can use modules instead of namespaces, and marked "as const" object literals instead of enums). I know some people want to argue definitions, "different language" etc., but it's really just a completely optional tooling layer that you can just strip. It's also evaluated purely during development time, for type checks, the actual code that gets executed remains the ECMAScript part. Whenever there are changes in a new Typescript version it's either purely within the type system, or they add type support for new ECMAScript features, those proposals that reached stage 3. You could just imagine the type annotations in a different layer than the actual code, like in Photoshop. A layer used only by the IDE and code checking tools. Microsoft added greatly to the confusion by putting the type checker, like eslint usable standalone or continuously queried through the IDE, and the type annotation files (.d.ts) generation and the completely optional .js file transformation AND .js file transpilation - backwards compatible JS code for earlier runtimes - into one tool. But all of those are different things. If your traget is "esnext" or you don't use JS features that your target runtime does not yet support transpilation is just removal of type annotations (except, enums, namespaces, which are no longer necessary and only exist for historical pre ES2015 reasons).
  • muglug 4y ago
    > Neither one is a different language. Both merely add type annotations to an otherwise pristine ECMAScript code base. This isn’t really a matter of debate — Microsoft describes TypeScript as a programming language distinct from JavaScript on its homepage. It’s a programming language with a trivial transpiration step to another language, but a separate language all the same.
    • nosianu 4y ago
      You completely ignored everything I wrote and merely responded with an assertion, ignoring all evidence. What a terrible way to have a discussion. Would you kindly not ignore the facts? Oh and here is what it ACTUALLY says on the Typescript page (https://www.typescriptlang.org/ https://www.typescriptlang.org/): > TypeScript is a strongly typed programming language that builds on JavaScript, giving you better tooling at any scale. None of that contradicts anything I wrote.
• zadler 4y ago
  As a recovered Haskell enthusiast, a can say that typescript is downright luxurious to work with for web development in a way that I think is hard to compete with in rust, because of how it types objects (like composable / decomposable sets), and the generic language to work with types really complements JavaScript instead of forcing you to do things differently.