Hacker News Reader

Comment by adwhit | Hacker News Reader

Write your Rust app. Compile to a binary on the backend, wasm on the frontend, using asyncio to communicate transparently between the two. Update the DOM directly from wasm, with 60fps rendering from Servo's WebRender. Totally typesafe and lightening fast.

It could all be so beautiful.

View on HN

The question then is whether Servo will be ready for primetime before wasm gains GC support. :)

Is a GC planned for wasm? I was hoping not.

It is, but not in the first release: https://github.com/WebAssembly/design/blob/master/GC.md

That's a better fit for Scala imo. ScalaJS is great as is, and I'm sure a wasm Scala backend would be amazing.

Rust is way too low-level for that imo. It works for Emscripten because of legacy code, but Rust is still ways off in that regard (i.e. adoption).

My impression was that wasm doesn't provide GC. Since Scala needs GC, Rust seems better positioned to have a first mover advantage.

I did not know that. There is work being done in this area through the Scala Native project, so it's still feasible.

Having attempted this "isomorphism" across Scala and ScalaJS, it is not quite that easy. That goes for all setups (node -> JS, Java -> GWT, etc) that I have tried. There are a lot of what some might call "impedance mismatches" between the two targets especially when it comes to communication and DOM work. IMO only frameworks/middleware built to bridge the gap will make it seamless.

In my experience Scala(.js) works way better than "(node -> JS, Java -> GWT, etc)".

There is a large gap between those and the way Scala _just works_ across platforms.

The huge difference is that you can depend on libraries and have them "just work" regardless of whether they are implemented identical on each platform, or need specific variations to implement the expected features.

Neither JS/Node nor Java/GWT have that.

> using asyncio

Don't hold your breath.

Unfortunately, the community seems to be going the way of Ruby/Python/C++: massive fragmentation.

What evidence do you have of this? Almost everyone is rallying around tokio.

Yeah tokio and futures-rs rock. Have there been talks of futures becoming part of std?

Many feel that it's likely that the future trait itself could become part of libcore. It's still far too early days to tell, though.

> the future trait itself could become part of libcore

_Please_ make this so.

> still far too early

I've waited 3 years, more time probably couldn't hurt.

> Almost everyone is rallying around tokio.

Sure - just as everyone "rallies" around EventMachine in Ruby.

This discussion has been going on for almost 3 years now.

It's great that tokio is making community headwinds, Twisted, Gevent, Celluloid, EventMachine all did too.

The problem is, they've never reached critical mass, and their respective languages refused to bless them as "official."

> What evidence do you have of this?

The issue is inter-library compatibility.

https://github.com/tailhook/rotor

https://github.com/tokio-rs/tokio

Totally incompatible, even though they build on the same low level library.

https://github.com/mitsuhiko/redis-rs

Oh wow, a great redis library - objectively the most popular. Completely incompatible with all of the above AIO implementations.

Let's take it to the extreme:

- Incompatible memcached client implementations: - https://github.com/aisk/rust-memcache (sync) - https://github.com/zonyitoo/memcached-rs (sync) - https://github.com/samphippen/decachedmem (tokio, partially implemented)

- Incompatible redis client implementations: - https://github.com/tokio-rs/tokio-redis (async via tokio) - https://github.com/mitsuhiko/redis-rs (sync) - https://github.com/AsoSunag/redis-client

- Incompatible HTTP client implementations: - https://github.com/matt2xu/async-http-client/ (tokio, new) - https://gitlab.com/imp/requests-rs.git (hyper, sync) - https://crates.io/crates/reqwest (hyper) - https://crates.io/crates/request

The list goes on.

There are countless libraries implemented with synchronous I/O, there are countless (good) popular libraries implemented with non-Tokio-based concurrency primitives.

Let me just say it: I really, really like Rust.

But I cannot feasibly use it for network/server-related tasks until a single solution is blessed by the Rust team.

The "let's let the community handle standardizing async IO and concurrency" approach has _never_ worked in the somewhat brief history of programming languages.

A blessed solution though? - Erlang, Golang, Node/JS* All work flawlessly.

I would use Rust full-time for every server-related task if I could, but I've been observing for 3 years and unfortunately haven't seen much development after the abandonment of builtin green threading.

*- codestyles sometimes incompatible, but there was _never_ a litany of sync libraries or otherwise fundamentally incompatible systems.

> just as everyone "rallies" around EventMachine in Ruby.

You can't really compare things this way. Very few people even use EventMachine, as it has significant issues.

You can't just show that rotor and tokio are two different libraries; you've claimed that there's significant ecosystem fragementation. That's a very different claim. The same goes for the other three sets of links below: that you can find a bunch of GitHub repositories does not mean that there's actual fragmentation. Writing a memcached or Redis client is a good way to learn a language, even: I've known two people who independently did so for memcached + Rust, tossed them up on github, and that's it. (one of those is one of the links you've provided above, even.)

> Oh wow, a great redis library - objectively the most popular. Completely incompatible with all of the above AIO implementations.

Because it's synchronous. Once tokio has an actual 0.1 release of the full stack, which is to happen any day now, you'll see more consolidation.

> until a single solution is blessed by the Rust team.

Two of three of tokio's core team members are Rust core team members. We had a full talk on it at RustConf, and it was mentioned in the keynote. Mozilla has sponsored development of it in places.

  > their respective languages refused to bless them as 
  > "official."

Tokio is literally developed by 1) the Rust developers and 2) contractors paid by Mozilla to work on Tokio. It's as official as Cargo is. :P

The "Rust team" isn't picking winners, but they do happen to be contributing to and creating the leading solutions. There is a lot of energy around futures and tokio, very early on in the story of Rust. Sure, Rust has already been around for a while, but 1.0 was only last year.

If you like Rust, and you want to use it for network and server related tasks, get involved. Write the redis, memcache, HTTP clients of your dreams. Rally the people who've solved those problems in Rust (and elsewhere) in the past.

Please try to state your concerns (or better yet, ask questions) in a more thoughtful manner.

>The "Rust team" isn't picking winners

It would be better if they would, though, is what some of us are thinking.

Between "totally chaotic third-party libs landscape" and "official lib designed with the language and part of the standard library", picking winners is a great middle ground.

> Twisted, Gevent, Celluloid, EventMachine all did too. The problem is, they've never reached critical mass, and their respective languages refused to bless them as "official."

At least in the case of Twisted, it probably didn't help that for a long time it was GPL licensed with all community contributions requiring copyright assignment to the lead developer.

Rust is a magnet for creative, intelligent people. There are bound to be lots of implementations for things like low-level I/O because lots of people want to explore the relationship between the OS, the application and the hardware. That is different than fragmentation in the sense you're implying.

The Rust community is pretty unified, esp. as its communication channels are well defined. For asyncio, I am pretty sure that Tokio will be the tool for most applications.

> That is different than fragmentation in the sense you're implying.

It is! But there are a mass of completely incompatible, overwhelmingly popular libraries.

> For asyncio, I am pretty sure that Tokio will be the tool for most applications.

When?

> When?

Tokio was only released along with futures like 3 months ago? It takes time to rebuild software on top of that. It definitely took me time to port from directly using MIO to using tokio.

After evaluating others options, I do believe tokio will be the default for most people.

Tokio is already eating the ecosystem, voluntarily. The authors of the only other two competitors, Rotor and GJ, told me at Rust Belt Rust that they're planning on deprecating their projects and throwing in with Tokio (perhaps largely thanks to the fact that the Rust/Mio devs asked them both for their input during the design of Tokio).

>There are bound to be lots of implementations for things like low-level I/O because lots of people want to explore the relationship between the OS, the application and the hardware.

You say it like it's a good thing.

> You say it like it's a good thing.

Why wouldn't it be? Let people experiment. As long as there's a standard, go-to library for applications that need to "just-work", I don't see any reason not to explore new ideas and find potentially better solutions for the future.

I agree it's an issue. Java and C# also suffer from it. In Java probably each webserver implements it's own network framework on top of NIO and in the end you have dozens of incompatible event loops runing.

However it's not an easy issue to solve for a general purpose language, unless you want to tie all those IO semantics (and probably a big runtime environment) directly to the language. C++ and Rust don't want to do that, since they want you to be able to use the language even on bare metal with zero runtime.

What you can do as a library developer for these languages is to try to make them as integretable as possible into all kinds of surrounding environments. I normally would try to make my library usable for blocking calls as well as in a nonblocking way within an external eventloop. You can do that by spawning your own thread/eventloop, handle all the library logic in there and provide thread-safe external APIs that communicate with our eventloop.

Framework development (in the sense of Netty/Tokio/etc) is harder. If often won't be possible to develop code that runs in multiple frameworks.

Yeah, if your app happens to be the same on the frontend and backend.

There are benefits even if you aren't sharing the entire back-end. I develop an internal Mojolicious webapp, and there's been quite a few times where I would have loved to just have one or two of the backend libraries I've written available to JS, so I wouldn't have to write it again in JS or pass it to the server. Just knowing that I could write it once and have it be the same in both places, even if I changed it later, would be a real boon.

Exactly. Everytime I write a feature, I have to decide whether it's a backend feature or a frontend feature. Sometimes I get it wrong. I'd like to not lock myself into my choice.

And it will never happen (ok, maybe "never" is too strong - it will happen 10-15 years from now, at best and even then it will be unstable/unreliable/slow/half baked on some platforms, because reasons). The best we've got is the piece meal approach of HTML/Javascript/CSS.

And before you blame those standards, blame the Unix vendors^W^W, pardon me, the platform owners (Microsoft, Apple, Google).

Why won't it happen? If wasm can talk to the DOM, then you'll still be using HTML and CSS, and wasm in place of JS. There's no reason this couldn't be done already by just compiling to JS, and plenty of languages already do that.

You could also render everything to a canvas to avoid HTML and CSS, but at that point there are a lot of things to re-implement, especially around accessibility.

Well, first of all wasm needs to be implemented in all major browsers on all major platforms for it to be widely adopted. Since the major browser vendors are backing it, that should happen quite soon.

But that's just the initial implementation. It needs to be implemented fully, debugged, optimized and then it needs to trickle down to user devices, including those sold 3-4-5 years ago and still in use.

And then, in the second stage, wasm needs to get DOM access (as far as I know v1 won't have it). See stage 1, all over again.

I'd say that the mass adoption cycle for 1 stage is roughly 5 years (where 80%+ of the browsers out there support a major feature well). So 2 stages x 5 years = 10 years.

Maybe I'm too pessimistic...

Given the history of the web and what I know of the people/companies behind wasm, it seems very likely that there'll be a graceful degradation/shim in the form of a wasm interpreter written in JS/asm.JS (or even a JIT from wasm to one of them), so there'll be no need to wait for all browsers to have implemented it, it just won't live up to its performance on all platforms.

There already is: https://github.com/lukewagner/polyfill-prototype-1

I think you are being too pessimistic about the speed of mass adoption.

On the desktop: Firefox, Chrome and Edge auto-update.

On mobile: Android 4.4+ (over 80% and rising fast) auto-updates its webview component. iOS receives yearly updates that are applied by a very large majority - though Apple's browser development does seem to have stagnated a bit.

So it seems to me that non-updating browsers are going extinct, and that we won't be dealing with another IE6 anytime soon. We're living in the future! :-)

The age of the evergreen-browsers is dawning. Although it will be years before the last corporate holdouts let go of their pinned IE9/IE10/IE11 browsers.

Why is 80% the magic number? 5% would reach more than 100 million people. That's enough to keep a team busy and a product growing while the competition sits on its butt waiting for the next 75%.

There is a shim so you don't need to wait for all the browsers to implement wasm

I hate JS but replacing it with Rust for front end is a bad idea, Rust is a low level systems programming language, it's very suboptimal for high level front end code from productivity standpoint and it adds no value because it's advantages (mem safety with 0 cost abstractions) don't really matter in frontend (JS is super bad at being optimizable but it's still more than sufficiently fast).

Rust is indeed known for memory safety and zero cost abstractions. But there is another side to Rust which is even more interesting - a type system that is almost as powerful as those of functional languages like OCaml and Haskell, but wrapped in approachable imperative syntax.

With such a type system, it is possible to encode the invariants of your application in types (using generics and algebraic data types). Then you can get very close to "if it compiles, it works".

JS, in particular, is the opposite. I am never really convinced that any JS I have written is "correct". It works, until one day it doesn't. This is such a problem that there have been multiple attempts to retrofit type-systems on top of it.

Rust needn't be the only language that brings strong typing to the frontend (Elm has been around for years now). But I think the prospect of speed and correctness both front and back is pretty exciting.

>But there is another side to Rust which is even more interesting - a type system that is almost as powerful as those of functional languages like OCaml and Haskell, but wrapped in approachable imperative syntax.

That type system is pretty verbose because it's aimed at manual memory management which you don't really care about in front end, and the compile times are huge compared to say TypeScript or something along those lines so yeah - I agree static typing is nice - but saying you should use Rust for front-end because it has static typing is like saying every gardener should have an excavator because digging holes with hands sucks - shovels exist.

I don't necessarily disagree with you, but when wasm is fully established I expect to see (another) step change in the complexity of the web. Fully-featured applications, 3D, VR, AR etc. We are on the brink of it already. And beyond a certain complexity (a relatively small amount of complexity, I would argue), a decent type system is essential.

Rust just happens to be well positioned to take advantage of all this.

Are you saying because it can do A it can't do B?

Are A and B mutually exclusive per se or is that just an unfounded assumption?

It's a design trade off. I don't get why people are so pissy about it - Rust makes design choices that are suited for low level systems programming language - but it has a lot of noise and complicated things from high level language stand point, and compile times + debugging + lack of run time tweak-ability make it very unproductive for front end compared to say TS/JS

I use Rust for web 1 year already and I can say it's awesome. Try.

But on the backend, not on the client, I presume? If you've really been deploying Rust over the wire via asm.js, then some commendations are in order for your persistence. :P

Yes, of course. But in parallel I write code in TypeScript (frontend) and after few months performance is equivalent in both languages. Only difference - no runtime errors in Rust.

Are you joking ? You can have hot module replacement in TypeScript meaning you don't even have to refresh the page to get new code in browser - and then you can fire up the REPL and prototype stuff - Rust has to go trough rebuild+redeploy on every iteration - you're saying that's the same speed ?

No. I don't use hot module replacement and I don't like this idea. And I don't prototype things often - maybe once or 2 per year - my contracts are usually long enough. It's all personal, as you see.

I'm saying that to implement feature in Rust takes same time as in Typescript or PHP (as PHP is a server side language also and comparison is more illustrative).

memory safety isn't the only advantage.

0 cost abstractions do matter a bit. In general abstractions let you do high level programming in lower level languages.

The type system matters a lot.

I used to do a lot of scripting. One thing I really missed was having a good static type system. These days I miss ADT enums in all languages.

Scripting is already moving in the direction of being more type safe (typescript, python type annotations), which is awesome, but I'd love to use something like Rust in that sphere.

I love JS (pretty unpopular opinion here on HN) and I love Rust also and I'm not convinced using Rust on front-end tasks would have any benefits. Yet, I strongly disagree with you on this point :

> Rust is a low level systems programming language, it's very suboptimal for high level front end code from productivity standpoint

Rust's type system is wonderful, and it's a real productivity boost. Fortunately people at Facebook developed an equivalent for JavaScript [1] because living without it would be really hard for me now. Furthermore, Rust offers a lot of syntactic sugar that makes it feel like a really high level language (compared to C, Go or even JavaScript pre-ES6 for instance).

>it's advantages (mem safety with 0 cost abstractions) don't really matter in frontend

It's indeed one of Rust selling point (especially for people coming from a C background) but it's not the only one. My favorite being the data-race free parallelism. I don't know the current status of multi threading in wasm, but being able to take advantage of all the cores of mobile devices could really help front-end frameworks.

[1]: http://flowtype.org, it's not inspired by Rust but inspired by OCaml, which also inspired Rust.

>Rust's type system is wonderful, and it's a real productivity boost.

Rust type system is verbose compared to higher level languages and it lacks a lot of the things that make higher level languages productive. It just focuses on low level code - which is good - but you wouldn't use it in place of C#, you would use it instead of C++, and you don't want to write GUI code in C++ either (even Qt uses JS for the frontend)

>My favorite being the data-race free parallelism.

Also mostly irrelevant in front end since you're dealing with single threaded event loops and doing parallel work that talks to UI thread is easy. Stuff that needs to do work in parallel can be written in Rust and talk to front end via FFI or RPC.

> even Qt uses JS for the frontend

Only if you use QtQuick. The traditional QWidget API is C++ all the way.

If you don't like it, you don't have to use it. The beauty of WebAssembly is that it can be targeted by so many other things. Finally, we can let JS sink or swim on its own, without being propped by an artificial monopoly on the web frontend scripting...

There doesn't seem to be anything unstable about it, even now. I've compiled tons of Rust code to asm.js over the last few months and there's not a single thing that didn't work. Modifying the DOM also works fairly well (you have to write wrappers though). And the code is 10x to 40x faster than the equivalent JS code. And you can run the exact same code natively on tons of platforms too. So it's already quite amazing.

One package that doesn't work yet, last I heard, is regex. That's a big one.

I'm not 100% sure if I tried it in any of my apps, but I think I did, and can't recall it not working. I'll try again soon and will tell you if it works.

Please fill me in too, possibly filling an issue on the regex repo if there's anything I can do to help. (This is the first I'm hearing of the problem.)

I had only heard of it second hand; I thought it was already communicated upstream. Oops!

Reply on news.ycombinator.com