GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-11-26) - page 1 of 10
 
___________________________________________________________________
Rust: Enable WebAssembly backend by default
351 points by a_humean
https://www.hellorust.com/news/native-wasm-target.html
___________________________________________________________________
 
[deleted]
 
JepZ - 2 hours ago
Actually, I don't know why so many people are so excited about
webassembly. Yes, it is faster than JS, but JS itself is not that
slow and on the other hand we loose the open nature of the human
readable web.
 
  Kwastie - 2 hours ago
  Minifiers don't output any readable JavaScript anyway. Yes, it
  can be "decompiled" back to something readable, but so can WASM.
 
  poizan42 - 2 hours ago
  Is it even faster? There is no particular reason why asm.js
  should be slower besides the initial parsing time.
 
  steveklabnik - 2 hours ago
  WASM has a non-lossy text based format; everyone involved doesn?t
  want to lose view source.
 
vincentriemer - 8 hours ago
Maybe I just can't find it, but the largest blocker for using Rust
on the web for me is a lack of a exposure/binding system (like
embind).I'm not particularly interested in writing entire webapps
in Rust but I do see it being useful for smaller self-contained
modules inside a larger JS app. Not having a robust binding API
makes that difficult.EDIT: But unrelated criticisms aside, congrats
on the progress! I'm excited to see more first class support of
WASM from languages other than C/C++.
 
  arbie - 8 hours ago
  I am excited for WASM for the same reason; not for wholesale
  migration, but targeted optimization. Hope documentation for this
  (likely very popular use-case) improves as WASM matures.
 
    cormacrelf - 8 hours ago
    Can anyone describe the (overhead) cost of calling into WASM
    code in the implementations so far? A lot of optimize-able
    areas are things like RxJS or Promise implementations (eg
    Bluebird), or generally libraries making the stack trace like
    [userspace code] -> [library code, approx 20 stack frames] ->
    [more userspace]. Should we think of the WASM-JS bridge cost
    like system calls, or like inline assembly?
 
      skybrian - 7 hours ago
      You need to look at serialization overhead for exchanging
      data. For example, I don't think web assembly has direct
      access to JavaScript strings? What about JSON?Seems like
      you're either converting a lot of strings (which wastes
      memory) or calling lots of JavaScript string methods from web
      assembly, which is not likely to be fast in an inner loop.
 
      josephg - 1 hours ago
      I'm curious about this too.I hand-wrote a perlin noise
      generation function in asmjs when that was the future. Then I
      called my noise function from a loop in javascript to paint
      an image (1 call per pixel - about 1M calls). Running the
      perlin noise code with the asmjs engine in Firefox turned out
      to be a bit slower than running all the code through FF's
      regular javascript engine. The asmjs code ran fast, but the
      FFI overhead at the boundary between JS and asmjs made the
      system slower overall.Given how easy it looks, I might try
      the same experiment with Rust & WASM to see where we're at.
      That said, this is the sort of thing which can definitely be
      improved over time.
 
  themihai - 8 hours ago
  I think the real issue is the lack of DOM access rather than
  binding to JS.
 
    tyingq - 8 hours ago
    Supposedly they are adding things like polymorphic inline
    cache, garbage collection, threads, etc, that would make it
    more like a VM.  Perhaps enough that Python, PHP, Ruby, or
    similar languages could run in WASM without downloading the
    whole runtime.  That plus native DOM access might make the
    front end web as diverse as the back end web.I'm curious
    whether the fragmentation that would bring on is a net add, or
    a net drain on the web as a whole.
 
      themihai - 7 hours ago
      I wouldn't say that fragmentation on the backend is a net
      drain as a whole...
 
    ralfn - 4 hours ago
    Isn't the point of the whole architecture that from a security
    perspective all IO will always be through
    JavaScript.Replicating the attack surface of the browser in
    JavaScript land in WebAssembly land goes against the whole
    design of it.It's for the community to make nice libraries that
    expose the browser features to WebAssembly land in JavaScript.
    It's also the right place to deal with cross browser
    differences.
 
  kenOfYugen - 8 hours ago
  What do you mean by 'first class support' of WASM in C/C++? Is it
  somehow possible to produce wasm binaries without utilizing
  emscripten?
 
    RX14 - 8 hours ago
    Yes, llvm has built in wasm support for a while now.
 
      buu700 - 6 hours ago
      The plan for emscripten is actually to replace its own wasm
      compiler with LLVM, and possibly drop its asm.js compiler in
      favor of running wasm2asm on LLVM's wasm output:
      https://github.com/kripken/emscripten/issues/5827Aside from
      keeping emscripten's code smaller / more maintainable and
      allowing the team to focus more on its role as high-level
      tooling, this should improve the size and performance of
      emscripten output since IIRC it's currently missing out on a
      lot of optimization opportunity by producing wasm as
      transpiled asm.js.
 
        azakai - 2 hours ago
        > IIRC it's currently missing out on a lot of optimization
        opportunity by producing wasm as transpiled asm.js.That's
        actually not true: the asm.js => wasm path emits better
        code (smaller, faster) than the wasm backend path
        currently.However, the wasm backend path is being improved,
        and should eventually get to parity.
 
          buu700 - 2 hours ago
          Ah okay, interesting. Is it because wasm doesn't yet add
          any new functionality over asm.js that using asm.js as an
          intermediary step isn't inherently worse?In that case, it
          sounds like the LLVM backend will only yield clear user-
          facing benefits when new features like pthreads are
          introduced?
 
          azakai - 2 hours ago
          Well, the "asm.js to wasm" path actually isn't pure
          asm.js anymore. We added i64 support and other things a
          while back, as intrinsics. So the asm2wasm path isn't
          limited by asm.js. It's weird ;) but it produces good
          code...The wasm backend does have other benefits, which
          is why we'd like to move emscripten to use it by
          default:* It uses LLVM's default legalization code, so it
          can handle LLVM IR from more sources (i.e. not just C and
          C++ from clang).* We can stop maintaining the out-of-tree
          LLVM that asm2wasm depends on.The LLVM wasm backend isn't
          ready yet (larger output code, slower compile times, a
          few missing features) but it's getting there.
 
      steveklabnik - 8 hours ago
      Incidentally, that's how this target works in Rust; we also
      have an emscripten-based target.
 
  steveklabnik - 8 hours ago
  I agree that the best use-case here isn't full apps in Rust, but
  writing high-performance modules.The webpack team is working on
  stuff so you can just drop a rust file into your proejct, and it
  will do everything needed for super easy
  integration.https://crates.io/crates/stdweb sort of gives you the
  bindings you want, by the way.
 
bluejekyll - 8 hours ago
This makes me so excited! Great job to Alex and the entire team
getting this done.I know Rust is not the most perfect language for
some. For me, it?s really exciting that there is finally a high
level language which can scale for every potential use case.Rust is
great for kernels and the embedded space; Excels in the systems
space; Is gaining traction in the native application space; Has
great tooling for web backends; and, now, with WASM, it?s capable
of targeting the web (Yes, without DOM access this is limited, but
my understanding is that is coming at some point in the future).Are
there any other runtime free, memory safe languages that can target
all of those use cases?
 
  FrappucinoFill - 4 hours ago
  >which can scale for every potential use caseFor a certain type
  of lowish-level programming, yes. But there's a reason that many
  projects include something like Lua for the majority of the
  actual application-level work.
 
  Thaxll - 6 hours ago
  Rust is not really good for web backends, it has no library for
  talking to popular service, the construct for networking are
  still uncertain / unstable / hard to use.
 
    bluejekyll - 5 hours ago
    For reference, what I have used that makes me claim this
    without being misleading (not necessarily all at the same
    time):https://rocket.rs/,
    https://rusoto.github.io/rusoto/rusoto_core/index.html,
    https://docs.rs/postgres/0.15.1/postgres/,
    https://docs.rs/kafka/0.7.0/kafka/,
    https://docs.rs/reqwest/0.8.1/reqwest/, as well as many other
    supporting libraries. I've not run into many things where there
    isn't already support.Also, in terms of networking, if your
    doing blocking IO, the stdlib is fine. Otherwise, from my
    experience, I really like https://tokio.rs/ for non-blocking (I
    know people are torn on this one) and have used it in my DNS
    impl, https://github.com/bluejekyll/trust-dnsFor more info on
    web and Rust, this is a great page: http://www.arewewebyet.org/
 
  justincormack - 6 hours ago
  I think another contender here would be OCaml/Reason, which has
  both JavaScript and WebAsm targeting, is used in systems space
  (eg Mirage). Its a bit different in technical choices
  (functional, GC, for example). Facebook is using Reason for
  Messenger for example, on mobile.
 
    shams93 - 1 hours ago
    There is a project TrueBit is working on for ocaml and wasm
    integration.
 
    d215 - 5 hours ago
    Honest question, Is reason really targeting wasm right now? Do
    you know a resource describing this? I cannot find anything
    about this.
 
      rlp - 2 hours ago
      I couldn't find anything on this either.  The assembly
      emitters in their repo don't suggest a WASM backend:
      https://github.com/ocaml/ocaml/tree/trunk/asmcomp
 
      bad_user - 5 hours ago
      AFAIK Reason is a frontend for OCaml and can target whatever
      OCaml can target. Note that for targeting JavaScript they are
      using BuckleScript, an OCaml backend that's not built by
      Facebook.
 
      k__ - 2 minutes ago
      https://github.com/sebmarkbage/ocamlrun-wasmreason == ocaml
 
    smt88 - 1 hours ago
    I consider Rust to be functional, although people would dispute
    that, I'm sure. GC is a huge difference though.
 
    idibidiart - 5 hours ago
    Any links to instructions for Reason WASM targeting?
 
      k__ - 1 minutes ago
      https://github.com/sebmarkbage/ocamlrun-wasm
 
  verletx64 - 5 hours ago
  > Rust is great for the embedded spaceHonestly, I would disagree
  here, unless we're talking in terms of potential, rather than
  actual ability right now. There's certainly some level of
  support, but I really did not get the feeling that Rust was
  'great' for embedded, rather that it could be.
 
    bluejekyll - 5 hours ago
    > but I really did not get the feeling that Rust was 'great'
    for embedded, rather that it could be.My experience is very
    limited here, but I have used TockOS on one of their dev
    boards. That was very pleasant, no stdlib makes it a little
    harder than std Rust, but still felt more deterministic than
    writing in C.
 
      verletx64 - 5 hours ago
      I was thinking a lot in terms of device support too, I guess.
      That's important to me; I know with C that I don't have to
      think too hard about which device, at least in terms of "Does
      this board support my language well".It's probably even more
      important for professional embedded engineers, where the
      hardware decisions may not even be made by the software
      developers, for various reasons.
 
        stmw - 5 hours ago
        Good point, although one advantage with Rust is that it
        plays well with C -- so you could keep some C drivers or
        libraries, and do the rest of the work in Rust. That
        reduces attack surface area while providing a smoother on-
        ramp to full device support.
 
          Const-me - 4 hours ago
          > one advantage with Rust is that it plays well with
          CAdvantage over what? This can be said about the majority
          of programming languagesFor example, I?ve recently done
          an embedded ARM Linux project where I used C# and .NET
          Core for higher level parts, C++ for lower level,
          [DllImport] and C API between the two.
 
          steveklabnik - 4 hours ago
          You're considering the "call into C" case, which is only
          half the story. "C calls into you" will always be easier
          in C++ and Rust, or any other language with "no" runtime,
          than heavier languages that rely on them. Yes, it can
          work, but it's a disadvantage.
 
          Const-me - 4 hours ago
          In C# I use callbacks where I find appropriate (logging,
          also some rare events). Under the hood, the runtime
          marshals delegates (most languages would call them
          lambdas) into unmanaged C function pointers.Ease of use
          is the same when I consuming the C API from e.g. C++. No
          disadvantage for C#.
 
          sinhpham - 3 hours ago
          "C calls into you" means you already have a C code base
          and now need to call your C# functions.
 
          Const-me - 3 hours ago
          Right, C# is OK when C code calls into
          it.https://stackoverflow.com/a/5235549/126995
 
          steveklabnik - 58 minutes ago
          To be clear, I?m not saying it?s not possible. I?m saying
          that one less runtime is an advantage.
 
          stmw - 5 minutes ago
          I actually think .Net runtime does a well above-average
          job with this - including clear declarations of managed
          and unmanaged code - so your ARM project sounds great &
          what I would expect. I just don't think it's true of
          "majority" of programming languages, at least if you
          count by number of users or HN popularity. We're both
          right.
 
        bluejekyll - 5 hours ago
        Again, not speaking from experience here, but it should be
        easy enough using tools like
        https://docs.rs/bindgen/0.31.3/bindgen/ to generate FFI
        interfaces to C libs where that is needed.So, I wouldn't
        necessarily say that's a blocker. Obviously everyone should
        make the best choice given their business requirements,
        etc.
 
          vvanders - 5 hours ago
          Yup, bindgen works great. It has a little problem with c
          macros but they're easy enough to redefine into a static
          constant to make them work.
 
  rapind - 53 minutes ago
  Nim comes to mind. https://nim-lang.org/
 
    dom96 - 42 minutes ago
    Thank you for mentioning Nim here. :)To expand a bit, Nim
    features its own JS backend with a high proportion of the
    stdlib supporting it. You can access the DOM via the `dom`
    module[1] and build some pretty cool stuff[2][3]. It doesn't
    target WebAssembly (yet) however.On the systems side, Nim
    compiles to C/C++/ObjC and manages memory via a soft real-time
    GC (or via a choice of other GCs including boehm).1 - https
    ://nim-lang.org/docs/dom.html2 - https://nim-
    lang.org/araq/karax.html3 - https://picheta.me/snake/ (source
    available here: https://github.com/dom96/snake)
 
  tyingq - 8 hours ago
  "Rust is great for kernels and the embedded space"I'm no expert,
  but from a layperson's perspective, the rust usage in these areas
  depends on a lot of "unsafe" blocks, fighting the borrow checker,
  etc.Does that ratchet it down from "great" for this space to
  something like "ok" or "usable"?Or is this just the best we can
  do in terms of a memory safe language for kernel and/or bare
  metal embedded?
 
    geofft - 7 hours ago
    The point of unsafe blocks is to contain unsafety. In a
    language like C, the natural pattern is to expose raw pointers
    through the entire codebase and document how to use them
    correctly, when they can be mutated, who's responsible for
    freeing them, etc. In Rust, the natural pattern is to implement
    wrapper types and other abstractions that themselves make heavy
    use of unsafe blocks but whose APIs are safe.This isn't unique
    to kernels. The standard heap-allocated vector type in Rust (on
    which the standard string type is based) is full of unsafe
    blocks: https://doc.rust-lang.org/src/alloc/vec.rs.html The
    problem of implementing a heap-allocated vector, with some
    elements uninitialized but available for use and with the
    ability to reallocate the entire vector and copy the members,
    is not a problem that lends itself well to the borrow checker's
    view of the world, so raw pointers are a fine way to solve it.
    Use of vectors themselves, their iterators, references to items
    in the vectors, etc. does match the borrow checker's view of
    the world, so the average Rust program running in userspace
    doesn't have to care that the standard library itself isn't
    implemented in safe Rust.So copious usage of the "unsafe"
    keyword in a codebase can be a sign that the code as a whole is
    more safe: instead of having large portions of the code be
    unsafe (or instead of having the code pretend it's containing
    unsafety when it's not), only the parts that need raw memory
    access use it, and they maintain invariants used by the rest of
    the code.It is certainly possible to do better - there are no
    machine-checked proofs that unsafe code does what it claims and
    upholds the invariants it claims to uphold. There could be, and
    I'm really interested to see what people do with languages that
    lend themselves better to proofs (usually dependently-typed,
    Turing-incomplete-but-very-powerful languages). But right now
    the state of the art is that such languages are a pain to use
    and writing proofs is even more of a pain. I think that's where
    the compromise is right now. The borrow checker is, arguably, a
    system for proving things about your code; it just only knows
    how to prove specific things. (Way more than C's type system
    proves, but way less than you'd prove in a perfect world.)
 
      Animats - 3 hours ago
      The usual problem in C is ambiguity over "how big is it", the
      cause of most buffer overflows. Rust tries to contain that,
      but doesn't solve the problem at the language level. Part of
      the trouble is that there's no way to talk about
      uninitialized memory in Rust. If you implement something like
      a growable array (rust calls this a "Vector", a poorly chosen
      name), it has space in use and space that's uninitialized and
      unused. There's no way to express that concept within the
      language. If you had a way in Rust to say that only elements
      0..N are initialized, and only they can be accessed, you
      could express that situation. Initializing another slot means
      more elements are now initialized.  This is run-time
      checkable with some overhead.Once you can say that, you can
      prove it. The proof techniques are well known. The first step
      is to be able to talk about it within the language. A
      predicate like    initialized(A,i,j)  meaning that array A is
      initialized from elements i to j inclusive is all that's
      needed. Then, when you write    assert(initialized(A,i,j));
      A[j+1] = 0;     assert(initialized(A,i,j+1);  you've
      expressed how much of the array is now initialized.  Then
      automatic theorem proving takes over and proves that if the
      first assert is true, so is the second.This eliminates the
      need for "unsafe" in many places. A fancier type system is
      not needed.It only takes one wrong piece of unsafe code to
      enable a buffer overflow attack.
 
        viraptor - 2 hours ago
        > Part of the trouble is that there's no way to talk about
        uninitialized memory in Rust.You mentioned Vec right after
        that. Which is interesting, because Vec deals with
        uninitialized memory just fine. https://doc.rust-
        lang.org/std/vec/struct.Vec.html#method.res... allocates
        more space, but doesn't allow you to read it unless you
        explicitly add elements.> It only takes one wrong piece of
        unsafe code to enable a buffer overflow attack.Isn't that
        the case for every language? Here, you can limit the unsafe
        bit to the underlying datastructure if any unsafe actions
        are required. Maybe Vec uses some unsafe bits, maybe not -
        but the usage of it is all safe code.
 
          frankmcsherry - 1 hours ago
          In many other languages `unsafe` taints the block of code
          it is in, which propagates upwards. Rust is the other way
          around, where `unsafe` means "I'm doing something unsafe
          here, but let's not tell anyone who doesn't look". It can
          be a lot harder in Rust (than other languages I've used)
          to know whose code you have to trust: language
          implementors (probably ok) or random crates (urk).
 
          ben-schaaf - 55 minutes ago
          Could you give some examples of these other languages? My
          only exposure to a similar feature is D's @safe/@trusted,
          where if you're writing @safe code, you'll always wrap
          unsafe code with @trusted stopping any propagation.
 
          frankmcsherry - 27 minutes ago
          C#
 
        Tade0 - 3 hours ago
        > (rust calls this a "Vector", a poorly chosen name),What
        exactly makes it "poorly chosen"?
 
          jacobolus - 1 hours ago
          I think it?s based on the C++ name? (a name which
          Stepanov supposedly now regrets,
          https://stackoverflow.com/questions/581426/why-
          is-a-c-vector...)But it disagrees with all past use of
          the name ?vector? in mathematics and numerical computing,
          which is reasonably consistent and well defined and dates
          from the mid-19th century.
 
          gpm - 1 hours ago
          I think it agrees pretty well with the mathematical
          definition, it's just a slight generalization.A Rust
          (C++, etc) Vec of length n where T implements addition
          and multiplication in a way that satisfies field laws is
          the "reasonable" representation of a n length
          "mathematical" vector over the field T. It just
          generalizes that storage type to situations where T is
          not a field.It doesn't support addition of two vectors
          and multiplication by a element of T using the normal
          mathematical syntax, but that's a fairly reasonable
          choice given how we regularly use vectors as a sequence
          of independent numbers and the different priorities for
          math syntax and programming language syntax.
 
          kccqzy - 1 minutes ago
          Just to clarify, a vector space is defined over a field
          but vectors themselves do not form a field.Also more
          importantly in mathematics vectors aren?t really
          growable. When you change the number of elements you
          change the dimension (and thus the ?type? for that
          vector). It is then ill-defined to add two vectors of
          different dimensions.
 
          azernik - 44 minutes ago
          This is quite standard in the functional programming
          world; Common LISP, Scala, and Haskell all use "vector"
          to refer to (usually growable) contiguous-memory arrays
          with efficient random access, as opposed to "lists" with
          efficient append and prepend but inefficient random
          access.
 
        TheDong - 3 hours ago
        > The usual problem in C is ambiguity over "how big is it",
        the cause of most buffer overflowsBuffer overflows in C are
        caused by accessing uninitialized memory, regardless of why
        the program does it (how big is it vs null pointer derefs
        vs various other ways).Rust does solve that problem at the
        language level. There's no such thing as an uninitialized
        pointer, which is the only right solution I'd argue. If you
        do access out-of-bounds in a safe block, you panic, not
        cause a vulnerability. How is the problem not solved by
        this, combined with iterators?What you're talking about,
        tracking uninitialized/initialized at runtime, can totally
        be done in rust too, e.g. with a [Option] or such... but
        then you'll obviously pay the runtime price of doing such
        checking.The more common case though is someone wishes to
        have a mutable vector which has a capacity and an
        accessible subset of data, which Vec implements.What you're
        claiming can be proven easily is not so trivial to prove
        for the common case; it may be `j+n` where `n` may derive
        from user input.It would be cool if blocks of rust now
        could be "theorem-proved-unsafe", but I think realistically
        it's a huge amount of work for a small win.Writing and
        proving theorems about code is typically much more time-
        consuming than exhaustively testing or informally verifying
        a block of code via review, and when the unsafe code is
        small and simple enough, the results we get are already
        "good enough".> It only takes one wrong piece of unsafe
        code to enable a buffer overflow attack.Yup, though for
        many programs you can entirely avoid unsafe code (outside
        of the well-reviewed and well-tested stdlib), and you can
        pay special attention to unsafe code in review and
        testing.That's a damn sight better than other low level
        non-gc'd languages like C++/C where the default is unsafe
        and all code is suspect.
 
          andrewflnr - 1 hours ago
          Ah, no, buffer overflows are caused by failure to check
          bounds. Practically, this is usually only a serious
          problem when the buffer overflows into an area that has
          been initialized with something like a return address.
 
      jeffdavis - 2 hours ago
      I think it's wrong to say that unsafe blocks "contain" the
      unsafety. Unsafety can't really be contained once it's there
      -- that's what makes it unsafe.The advantage is that you
      should be able to write application code without unsafe
      blocks; they should be in a library. And the library has a
      contract: if unsafe behavior does leak outside the library,
      it is clearly the fault of the library, and can't be blamed
      on the (safe) caller.
 
        TheDong - 2 hours ago
        Unsafe blocks "contain the possible sources of unsafety"
        may be a more correct way to phrase it.It is better to know
        that only a specific subset of the codebase could be
        responsible for memory unsafety even if that behavior may
        leak. If nothing else, it helps focus reviewing and testing
        effort.
 
        burntsushi - 2 hours ago
        I'm pretty sure y'all are saying the same thing. :-) my
        favorite way of describing it is "Rust lets you build safe
        abstractions, even if its core uses unsafe."
 
      kzrdude - 6 hours ago
      This is a teaser / preview and not necessarily what is going
      to come. But Rust could evolve to providing checks like
      this:https://i.imgur.com/oqtEDoV.pngFrom miri, page 27 in
      their slide deck. The miri project has changed a lot since
      the slides were written ? and it is now close to being merged
      into rustc.miri: https://github.com/solson/miri
 
      tyingq - 7 hours ago
      Terrific, in-depth, answer...and I appreciate it.
 
      javajosh - 7 hours ago
      A really nice answer. It's too bad, I suppose, that the same
      abstraction can't be used "all the way down". I suppose then
      we'd be stuck with some high-level encoding of the chip's
      ISA, perhaps generalized to allow the programmer the ability
      to define new instructions, and an increased number of
      registers, etc.
 
    steveklabnik - 7 hours ago
    You'd be surprised at how little unsafe you need. Consider
    https://os.phil-opp.com/page-tables/ for example, it uses the
    type system effectively to eliminate some issues, in the end,
    it only has two calls to unsafe.On some level, yes, it's the
    best we can do. Unless you want to add hardware semantics into
    your language. Unless you do, writing two bytes to 0xB8000 is
    going to be an arbitrary memory access. At least, that's my
    take.
 
      cwzwarich - 4 hours ago
      > Consider https://os.phil-opp.com/page-tables/ for example,
      it uses the type system effectively to eliminate some issues,
      in the end, it only has two calls to unsafe.However, those
      two calls to unsafe rely on an invariant maintained by the
      rest of the code that is not marked unsafe. Effectively, the
      entire module has to be treated as unsafe code by the
      programmer.
 
        steveklabnik - 4 hours ago
        Yes, absolutely. It's still a far cry from what many people
        assume, which is that the whole shebang must be.
 
          cwzwarich - 4 hours ago
          For kernel-level programming, I think Rust is basically
          the same as C or C++ in this regard. I haven't seen a
          kernel written in Rust where I am convinced there is a
          submodule that can be treated as if its correctness
          doesn't impact the safety of the entire kernel.
 
          TheDong - 2 hours ago
          I don't understand this argument at all."Rust is not
          perfect, so it's basically the same as C"The fact that
          "american fuzzy lop" and "syzkaller" have gone through
          the kernel and found dozens of use-after-free's (see http
          s://github.com/google/syzkaller/blob/4bd70f/docs/linux/f.
          ..), shows that even incredibly carefully programmed C
          messes up in totally rote ways.The basic cleanup code
          which is able to be exploited here would not be in an
          unsafe block if this were rust. In fact, because rust
          abstracts memory management out better, most of the
          cleanup code wouldn't exist at all.Rust also allows
          better abstractions. For example, Rc in rust is much
          easier to use without screwing up than the manually
          handled reference counters littered throughout the
          kernel. It seems obvious to me that numerous deadlocks in
          the kernel could be avoided by not hand-rolling
          refcounting everywhere.You're right that there's still
          the potential with rust for some code to compromise the
          safety of the entire kernel.But with rust that's a subset
          of code, not practically every single line of the whole
          thing.It seems to me like memory corruption/use-after-
          free/etc only being able to happen in a small fraction of
          code is better than it being able to happen anywhere.
 
          Rusky - 3 hours ago
          > a submodule that can be treated as if its correctness
          doesn't impact the safety of the entire kernel.You don't
          have to go all that way to be better than C or C++. Rust
          can give you a submodule A whose correctness doesn't
          impact the safety of any uses of submodule B.
 
          cwzwarich - 3 hours ago
          If the correctness of submodule A impacts the safety of
          the entire kernel, then it impacts the safety of the uses
          of any other submodule, because you can't really contain
          the consequences of the unsafe behavior.
 
          Rusky - 1 hours ago
          > you can't really contain the consequences of the unsafe
          behavior.That's true, but the property I described can
          still help you track down the root cause and limit the
          number of places that interact with it.
 
          andrewflnr - 1 hours ago
          No, that's sort of the problem, isn't it? Safety actually
          does depend on the whole shebang, or rather, the
          correctness of all the code that supplies inputs to the
          "unsafe" block. I think safety has to be thought about at
          level of the unit of code that can enforce its own
          invariants, rather than the specific syntax that does the
          dirty work.
 
          steveklabnik - 1 hours ago
          Safety depends on any module containing unsafe code
          upholding the invariants that are required. But once
          you've done that, it's safe.The question is, how much
          code is in this state, vs being purely safe? My
          experience and that of others shows that it's generally a
          smaller amount than many people not experienced with Rust
          assume.Basically, I find the "there's always unsafe code
          somewhere at the bottom and therefore it's the same as
          100% unsafe" to be overly reductive.
 
          frankmcsherry - 47 minutes ago
          > Basically, I find the "there's always unsafe code
          somewhere at the bottom and therefore it's the same as
          100% unsafe" to be overly reductive.I totally agree; it's
          not the same. However, I think there is disagreement
          about whether saying only "there's always unsafe code
          somewhere at the bottom" is better or worse than saying
          "it's 100% unsafe".I tend to write some sketchy unsafe
          code, and the only thing I can say with a straight face
          is "please don't use this if you care about safety", i.e.
          treat it as if "it's 100% unsafe". I'm slightly weirded
          out that Rust has a keyword that amounts to "I understand
          UB really well; tell others to trust me on it
          transitively".I'll be less weirded out when the UB story
          gets shaken out more, or if cargo gets an "audit-unsafe"
          option that shows you all unsafe blocks you transitively
          depend on (does that exist yet?). Still like Rust, but
          letting randoms write unsafe code is scary.
 
    traverseda - 7 hours ago
    Having never used rust and having barely used C, here are some
    uninformed opinions.A memory safe language for the kernel
    doesn't seem possible using "traditional" safety tools. I'd
    expect a "safer" language would look a lot like formal
    verification. If you can make a safer language that doesn't
    look a lot like formal verification, you can probably automate
    a lot of formal verification.There are still some big
    advantages to rust. By explicitly marking unsafe code, you've
    made it a lot easier to figure out what needs to be focused on.
    I imagine you can even formally verify just the unsafe parts of
    your ecosystem.Also, rusts tooling just seems more pleasant.
 
      pjmlp - 6 hours ago
      ESPOL for Burroughs B55000 in 1961 already allowed for some
      kind of safety.It was a systems programming language based on
      Algol and already had the notion of unsafe code for low level
      code.Those modules had to be marked as UNSAFE and could only
      be executed if allowed to do so by the sysadmin.Similar
      exemples could be provided about PL/S, PL/8, Mesa, Modula-2,
      Modula-3 and many others.One big contribution that Rust
      brings into the table is to educate a whole generation that
      belives the myth that C was the very first systems
      programming language, that there are actually safer
      alternatives.
 
        catnaroek - 1 hours ago
        > Those modules had to be marked as UNSAFE and could only
        be executed if allowed to do so by the sysadmin.Safety vs.
        authorization are completely orthogonal. The former is an
        objective property of a program, to be established or
        refuted with formal proof. The latter depends on the
        subjective whims of one specific human being, in this case,
        the sysadmin. And, in my experience, the typical sysadmin
        is not a good enough semanticist to determine whether a
        program is safe or not.
 
          pjmlp - 36 minutes ago
          The point being that unsafe code had to be marked as such
          to be compilable and that tainted the binary, which was
          only allowed to execute after given permission.Formal
          proofs can also contain logic errors.Any kind of safety
          improvement is better than what C offers.
 
          catnaroek - 33 minutes ago
          > The point being that unsafe code had to be marked as
          such to be compilable and that tainted the binary, which
          was only allowed to execute after given permission.And my
          point is that this is useless in the absence of someone
          or something capable of reliably determining whether the
          code is safe to run.> Formal proofs can also contain
          logic errors.So you have competent people write them.
 
          pjmlp - 21 minutes ago
          Regarding formal proof systems, not only can they contain
          logic errors, they are still very far from being usable
          for the common programmer to do regular programming.As
          for competent programmer, we all know how many
          corporations search who they hire.
 
    013a - 7 hours ago
    Even if you wrote your entire program in unsafe, you're still
    enjoying an experience at least as good as C++; you just don't
    get the compile time memory safety. And its unlikely your
    entire program would ever have to be in unsafe.
 
stcredzero - 21 minutes ago
What is the Rusty way of handling memory management for a game
engine client deployed on WebAssembly? When a program is running a
game loop, there are certain entities which will stick around
across frames, and there are certain entities which definitely will
not. Is there a way to enforce that most of the implementation of
the game reside in pure functions, while making memory management
nearly bulletproof?
 
idibidiart - 5 hours ago
How does the performance of WASM compare to JIT'd JS code?
 
  amelius - 3 hours ago
  This makes me wonder: does WASM allow a JIT (specializer)? I.e.,
  does WASM allow self-modifying code or code to write code?If not,
  then JIT'ed JS could still be faster than WASM.
 
    steveklabnik - 2 hours ago
    Wasm code is normally JIT-ed by the JS VM. That is, browser
    implementations don?t have an entire separate VM for wasm.
 
  amaranth - 3 hours ago
  It's going to be heavily dependent on what you're doing. WASM can
  be as fast as native code but is more likely to be 1/2 the speed
  of native on realistic benchmarks. However, the overhead of
  moving between WASM and JS is quite large so in practical use
  your WASM version might be slower than a pure JS version. WASM vs
  JS benchmarks I've seen show WASM anywhere from 40x faster than
  pure JS to 10x slower than pure JS, due to this overhead.If
  you're doing a large amount of CPU intensive work that can be
  isolated from the rest of the code that is an ideal scenario for
  WASM. You have the translation overhead of JS->WASM once, then do
  the computation, then WASM->JS once to get the result. A small
  function or code that needs to call back into JS (for DOM access,
  to query some state in your app, etc) is going to have a lot of
  those translations so won't see much or any benefit.
 
xstartup - 7 hours ago
We switched from Go to Rust in production. After the initial ramp-
up time, it's really a lot more productive than Go for us, at
least.
 
  johnydepp - 6 hours ago
  Interesting! Can you tell what are you working on? It may help
  others.
 
  qualitytime - 7 hours ago
  May I ask what "production" is?
 
    zimzim - 5 hours ago
    the actual product environment, not development research or
    testing.
 
      GolDDranks - 5 hours ago
      What area of computing you are talking about?
 
    xstartup - 4 hours ago
    Real-time fraud detection as service for adtech companies. We
    started with Java but got tired of GC pauses, perhaps due to an
    inexperienced team but we were not able to tame it. Then we
    moved to Go and now we are in Rust.
 
  stmw - 5 hours ago
  We've been happy with Rust, as well.
 
  FourSigma - 6 hours ago
  Ditto! Would love some clarification.
 
doiwin - 6 hours ago
I would like to code WebAssembly by hand. Are there any good tools
/ tutorials on this?
 
  kodablah - 6 hours ago
  Probably not any good tools or tutorials, but the wast format is
  not that hard [0][1] and most compilers accept that format. Just
  gotta keep the values on the stack in mind while you write.0 -
  http://webassembly.org/docs/text-format/1 -
  https://webassembly.github.io/spec/text/index.html
 
  lj3 - 4 hours ago
  Do you mean something like this?
  https://mbebenita.github.io/WasmExplorer/
 
knowThySelfx - 8 hours ago
Great. I like the way Rust is going on about.
 
phkahler - 8 hours ago
So when will servo become a webapp so we can run it inside
firefox?To clarify, this is sarcasm. What I really want to say is
when can we run firefox inside firefox? But it's not entirely
written in Rust. The point of that question is to illuminate some
of the absurdity of web apps. i.e. what function does the outer
browser serve in this scenario and why do we need it?Edit: All the
answers point to the outer browser as providing a sandbox. I
contend that is supposed to be an OS function. I also think that
tabs in the browser came about because OSes didn't provide a decent
way to handle multiple instances of applications. See what's
happening here?
 
  Jyaif - 5 hours ago
  You can already run ff in ff:https://bellard.org/jslinux/vm.html?
  url=https://bellard.org/...
 
  bluejekyll - 7 hours ago
  Your question is related to the technical aspects of the
  ecosystem, but not to the way that people use computers in
  general.A good rhetorical question in response is, why is the web
  so much more popular when using computers than installed
  applications?The implication you've made is that there is no
  benefit to the web, but that is obviously not true, as web usage
  far outstrips installed applications (besides the browser) at
  this point. Given this, it becomes necessary to have common
  tooling to target the different browsers out there.Getting back
  to the core of your question, if there was a framework for which
  you could target all users on the internet (with a single
  codebase), it ran natively on all platforms, was easily run by
  everyone merely by clicking on an icon, which then cleans itself
  up after running... then maybe native apps would be a good avenue
  for delivering all applications.
 
    qznc - 4 hours ago
    What is the advantage of wasm over Java and Flash? I don't
    really see technical advantages. There is only the social/legal
    aspect: wasm is not controlled by a single corporation.
 
      steveklabnik - 4 hours ago
      wasm is more baked into the web platform than either are;
      flash wasn't as bad as java in this regard, but still. Nobody
      wrote flash libraries that your JS code could use, they used
      it for the equivalent of a big old .It also does not
      require a second runtime; integrating wasm support into
      existing JS VMs took very little code compared to an entire
      JVM or flash runtime.
 
      Rusky - 3 hours ago
      There is an immense technical advantage: wasm doesn't enforce
      a high-level memory model like the JVM's classes or Flash's
      ActionScript. It allows straightforward use as a compiler
      target for low level languages which do not use a bytecode
      verifier for safety.Any attempt to use those languages or
      their existing ecosystems of code on the JVM, Flash, or
      Javascript will be incredibly fragile and convoluted.
 
  [deleted]
 
  jonreem - 8 hours ago
  It still serves as a sandboxed interpreter/GUI framework and as a
  frontend for finding and loading apps, regardless of how complex
  the apps are.
 
  a_humean - 8 hours ago
  Isolation. WASM is a target that allows users to effortlessly
  download and run arbitrary code from the web on all platforms
  with a modern web browser; an environment that is sandboxed such
  that arbitrary file system access or other system access is
  relatively safe and limited even without knowing the intentions
  of the author.This is why javascript is so popular with its
  current monopoly on the web. No other language can do that, but
  with WASM other languages, such as Rust, can be part of the
  picture.
 
    dullgiulio - 7 hours ago
    I don't want to attack Rust or WASM, as I am pretty excited
    about this, but it's not that easy.That anything that runs into
    the browser is isolated sandboxed and whatnot is irrelevant.
    It's still arbitrary code running on often unwilling
    clients.Don't believe me? Think about ad-blockers.
 
      steveklabnik - 7 hours ago
      It's no different than the existing JS here.
 
        dullgiulio - 7 hours ago
        Absolutely, not different at all. I am just saying that is
        naive to think that the web platform is safer than other
        platforms. Many "attacks" happen completely inside the
        sandbox.
 
          steveklabnik - 7 hours ago
          Oh yeah, it's not a panacea for sure.
 
          Rusky - 3 hours ago
          The web platform is not completely safe, but it is far
          safer than, say, an unsandboxed exe running on Windows.
 
        phkahler - 7 hours ago
        Most JS is unwanted code running in the browser. Seriously,
        the web devs are the ones that want it, not the user.
 
      a_humean - 7 hours ago
      That's why I qualifed with "relatively safe". Arbitrary code
      from potentially malicious/incompetent sources is arbitrary
      code, but its a platform on which its relatively safe to run
      arbitrary code.
 
  mrdoops - 3 hours ago
  I feel like the direction web and applications in general are
  heading is that of near-native performance in a sand-boxed
  execution environment managed by something like a browser. This
  potential is what excites me the most about webassembly, even
  more so than enabling the transition away from Javascript.
 
  geofft - 8 hours ago
  It serves the same purpose as the outer kernel on a VM host:
  isolation between fully-featured inner environments using a
  solid, featureful platform. There are tinier platforms you can
  use for isolation, and yes, they're more secure, but they don't
  get you the wide real-world deployability that full-featured
  kernels or browsers get you.I would genuinely like to be able to
  run Servo inside my un-jailbroken Chromebook. I already run an
  SSH client in the browser (using Google's Native Client instead
  of wasm, but same difference), and I don't see why Servo needs
  access to my SSH private keys. To me, the fact that the only way
  I can run Servo is to give it access to my entire user profile is
  the absurd thing.
 
steveklabnik - 8 hours ago
I'm so so so excited to see this land! I have a little hello world
demo:
https://gist.github.com/steveklabnik/d86491646b9e3e420f8806a...To
give you an idea of file sizes, the above produces a 116 byte wasm
file. If you leave off the no-std stuff it produces a 3059 byte
wasm file.EDIT: I'm actually being told that there was a bug in
wasm-gc that's since been fixed, even with libstd it should be able
to eliminate all of it and get the tiny file now.
 
  josephg - 7 hours ago
  That?s gorgeous. How much bigger does it grow if you heap
  allocate? Does it include 2mb of extra code like in normal
  desktop builds?
 
    steveklabnik - 7 hours ago
    I?m away from my computer right now, so may take a while to
    give you an exact number, but when I first did this, I forgot
    to turn on optimizations, and the libstd version was 173kb pre-
    gzip. So I?d imagine it?s similar to that, or at least, that
    gives you an order of magnitude.
 
    killercup - 7 hours ago
    This Rust code [1] heap allocates some things (e.g., a string
    with `String::from`), and results in this [2] WASM file, which
    is 65kB, or 25kB after `gzip -9`.[1]:
    https://github.com/killercup/wasm-
    experiments/blob/bf3b30eed...[2]: https://github.com/killercup
    /wasm-experiments/blob/bf3b30eed...
 
      azakai - 2 hours ago
      It should be possible to reduce that a bunch more, 65kB
      sounds high.Running the binaryen optimizer on that wasm
      shrinks it by 6%. Probably more can be done on the Rust side.
 
        killercup - 2 hours ago
        Absolutely, yeah. Having a real linker will help with that
        as well. Until then, you can also compile with
        [profile.release]     opt-level = "s"  (i.e., optimizing
        for size), to get it down to 23kB gzipped.
 
      josephg - 1 hours ago
      Thats much smaller than I expected, especially given how
      large rust native binaries usually are. What allocator does
      that use? Does that 65k include its own malloc implementation
      like we needed for asmjs, or does WASM expose a system malloc
      library or something?
 
        steveklabnik - 1 hours ago
        wasm exposes "memory sections", which the module states up-
        front how much it wants. It can also generally call a "grow
        memory" function that makes this space bigger. That's it,
        from the direct wasm perspective.That said, this target
        uses https://github.com/alexcrichton/dlmalloc-rs
 
  sinhpham - 4 hours ago
  Could you please add an example of using cargo instead of calling
  rustc directly? How do I configure cargo.toml?
 
    steveklabnik - 4 hours ago
    Here's hello world: https://github.com/steveklabnik/semver.crat
    es.io/commit/dc3b...(I wanted to try to port semver parsing to
    the web today, but I hit an LLVM assertion, so it'll have to
    wait until we can fix that issue. This stuff is still very
    raw!)
 
drhodes - 7 hours ago
Has anyone given any thought to dynamic linking wasm objects to
save bandwidth?
 
  [deleted]
 
  ainar-g - 7 hours ago
  I would prefer compilers that produce compact statically linked
  "binaries".
 
    bluejekyll - 6 hours ago
    Assuming that the Rust stdlib eventually is compatible/compiled
    for WASM, wouldn?t it be better if that was cached for all
    sites which use it, rather than downloading it each time?I can
    imagine a world where all dependencies are compiled for WASM,
    similar to crates.io, and then all apps using those libs would
    benefit from sharing and load blazingly fast because they only
    load the site specific code.Wouldn?t that be a good thing?
 
      sd8dgf8ds8g8dsg - 5 hours ago
      This is what we have CDN:s for
 
      Rusky - 3 hours ago
      There are two problems with that, at least for the
      stdlib.First, the stdlib contains a lot of compiler version-
      specific code so the savings would not be that great unless
      (until?) it becomes much more stable, along the lines of
      glibc.Second, a large portion of stdlib is generics, which
      are be monomorphized per-app. Further, much of stdlib usage
      should be inlined and optimized into the app itself
      anyway.The portions of the stdlib statically linked into an
      app will generally always be smaller than the whole stdlib.
      It may make sense to dynamically link some parts of the
      platform, like the memory allocator, but the whole stdlib is
      not a good candidate.
 
        bluejekyll - 3 hours ago
        That is a great point about the monomorphized code. I
        hadn?t considered that.
 
      josephg - 1 hours ago
      For what its worth, the web community is currently pretty
      conflicted on using this approach. jQuery is often loaded
      from CDNs, while React (and friends) are almost always
      bundled into each app individually. I'd like to say there's a
      principled reason behind this, but I think the main reason is
      that the tooling (webpack, browserify) makes it simpler to
      embed react than use a CDN version.Actual benchmarks are
      pretty mixed. If you have a cached CDN copy of react it can
      be a little faster. But if you get a cache miss, the extra
      overhead of hitting another host to load dependancies is
      often 10x-100x slower for unlucky users than downloading
      80k(?) of additional gzipped javascript. Its especially bad
      with react because unless you do isomorphic rendering, your
      page isn't visible at all until react is downloaded.I suspect
      Rust's stdlib will compress to a similar size (maybe a little
      bigger), and the speed saving you're hoping for won't really
      be worth it in practice; even if you get around the
      monomorphising problem.
 
  steveklabnik - 7 hours ago
  It totally works, it's just not particularly easy to do. wasm
  modules have import and export sections; you'd instantiate the
  std module first, the instantiate the module that depends on it,
  pointing its imports at std's exports. I don't know of any
  tooling that makes this super easy at the moment though, you
  basically have to do it by hand as far as I know.
 
    kodablah - 6 hours ago
    I don't think you can at runtime from wasm though. Imports are
    resolved at load time. Sure there are call indirect that let
    you dynamically change the function index but not the
    import/export. Now if you were willing to reload, you could use
    the JS API to create modules at runtime with dynamically
    downloaded pieces, but once created, that's it I think.
 
      steveklabnik - 6 hours ago
      Sure, I'm talking about "instantiate one big module" vs
      "instantiate several smaller modules, then finally the last
      module". Which is a bit different than what you're talking
      about; you're right that after you've instantiated, you can't
      change imports.
 
    drhodes - 6 hours ago
    great, thanks, that clarifies things quite a bit.
 
souenzzo - 2 hours ago
Once rust is implemented in rust, I can run rustc in browser and
get binaries for windows, for example?
 
  steveklabnik - 2 hours ago
  Rust is written in Rust, with the exception of LLVM. C++ can be
  compiled to wasm too though, so that's not the blocker.The bigger
  issue is that rustc uses features that aren't in wasm yet, like
  threads and file loading and such. It'll happen eventually, but
  not just yet...
 
[deleted]