3 ms·

So much cutting edge technology for something that could have been written in BASIC running on a Z80 :) That being said, Zig is an interesting, well-deigned la

So much cutting edge technology for something that could have been written in BASIC running on a Z80 :) That being said, Zig is an interesting, well-deigned language. Despite being young, it already has tons of features. And compatibility with the C ABI is a big plus.

flohofwoe 7y ago
...I think it's interesting that WebAssembly moves the "code bloat problem" into focus again, because WebAssembly apps cannot afford to have huge upfront downloads or long installations. They must start in a second or so. The Tetris example is under 60 kBytes (compressed), and that includes all data as well (there's a sprite/font sheet embedded in the wasm blob). This is in the same general size range as 8-bit BASIC programs. That means that Zig doesn't need a big runtime to work, similar to C, but unlike C# or Java (or even C++ / Rust, unless you ignore most of the respective standard libraries and restrict yourself to a minimal "embedded-programming" style). Here's a similar example (shameless plug), a WASM C64 emulator in under 64 KByte download size. This is implemented in C: https://floooh.github.io/tiny8bit/c64.html https://floooh.github.io/tiny8bit/c64.html I can (most likely) get to the same result in Zig, but with a much nicer "better C" language (and build system!) (...of course there's a huge web browser dangling off the WebAssembly blob, but this is mostly runtime components that are not even needed for this type of WASM programs (we really need smaller, more modularized browsers!).
- winter_blue 7y ago
  It’s not much of a problem once you have code splitting. React supports code splitting, which lets you split large amounts JS into separate production JS files; load only what’s necessary at first, and load the rest as-needed: https://reactjs.org/docs/code-splitting.html https://reactjs.org/docs/code-splitting.html With a new programming language (like Zig), I would hope that they eventually try to have code splitting be automatic and transparent. For JS targets, you create multiple smaller final JS files instead of one giant JS file. For native targets, you could break out extra code into dynamically loaded .so or .dll files. The real challenge is making this whole process as painless and transparent as possible for the developer.
  - flohofwoe 7y ago
    Compiled languages usually have dead-code-elimination (only code that's actually "reachable" is included)... I think the JS world invented the word "tree-shaking" for that. Not loading everything that's eventually needed at startup can be handled with loading WASM modules on demand (which can be handled the same way as loading DLLs in a native application). IMHO it's better to fight code bloat at the root, by picking a language without runtime, minimizing dependencies, and picking the right dependencies.
- bluejekyll 7y ago
  I’m not sure what you mean by your comments around C vs. C++/Rust. All of them have no required runtime. All of them generally have libc supplied by your OS, which is a runtime. Even in C you must restrict yourself to the runtime your building on, i.e. your target might not have libc. Rust and C++ are the same in the regard that they are capable of doing this.
  - flohofwoe 7y ago
    There was a time when Rust executables came with an embedded jemalloc, but that's been fixed in the meantime (I think). But that's not what I mean in the C++ and Rust case, instead: Both C++ and Rust make it quite easy to "accidentally" add bloat indirectly through their standard libraries because they encourage high-level abstractions which may "unfold" into a lot of binary code from very little source code. It can be avoided but requires to give up on many of the high-level language features which Rust and C++ differentiate from (for instance) C.
    - bluejekyll 7y ago
      I can speak better for Rust in this regard, so I won't comment on C++, but I also don't work with #[no_std] often so apologies if anything is inaccurate. jemalloc has been optional in nightly ever since I started using the language in 2015. It switched to the system allocator in the 1.28 release, Aug 2018, it also stabilized the ability to define a custom Global Allocator[1]. > Rust make it quite easy to "accidentally" add bloat indirectly through their standard libraries This isn't accurate, the #![no_std] feature disables stdlib in your library/binary. It requires you to implement a few things, but it will not compile if you use things in std [2]. You may be interested in reading the embedded book[3] which discusses this area in a lot more detail. > give up on many of the high-level language features I also would disagree. You still have a powerful type system, match statements, RAII, hygienic macros, proc_macros, all of the core library[4], optionally have access to the alloc crate[5], cargo, simple unit-test integration, and a growing set of #[no_std] libraries with easy access through crates.io or git dependencies. There's a lot more of course. Point being, there are still a lot of higher-level language features available even in a #[no_std] context, and it's very easy to ensure that your binaries won't compile if this is a requirement and someone tries to pull something in that relies on std. [1]: https://blog.rust-lang.org/2018/08/02/Rust-1.28.html https://blog.rust-lang.org/2018/08/02/Rust-1.28.html [2]: https://doc.rust-lang.org/nomicon/beneath-std.html https://doc.rust-lang.org/nomicon/beneath-std.html [3]: https://rust-embedded.github.io/book/intro/no-std.html https://rust-embedded.github.io/book/intro/no-std.html [4]: https://doc.rust-lang.org/core/ https://doc.rust-lang.org/core/ [5]: https://doc.rust-lang.org/alloc/ https://doc.rust-lang.org/alloc/
- dmitrygr 7y ago
  > .I think it's interesting that WebAssembly moves the "code bloat problem" into focus again, because WebAssembly apps cannot afford to have huge upfront downloads or long installations. They must start in a second or so. The Tetris example is under 60 kBytes (compressed), and that includes all data as well (there's a sprite/font sheet embedded in the wasm blob). This is in the same general size range as 8-bit BASIC programs. Original Tetris was under 32k, and competition implementations since have been under 512 bytes. 60K plus webkit plus OS is plenty of bloat still
- apta 7y ago
  > but unlike C# or Java https://github.com/MichalStrehovsky/zerosharp/blob/master/efi-no-runtime/README.md https://github.com/MichalStrehovsky/zerosharp/blob/master/ef...
MaxBarraclough 7y ago
> Despite being young, it already has tons of features Zig is aiming to be lean-and-mean, not feature-rich, but I take your point. I agree it's very impressive how quickly it's come this far.

flohofwoe 7y ago

...I think it's interesting that WebAssembly moves the "code bloat problem" into focus again, because WebAssembly apps cannot afford to have huge upfront downloads or long installations. They must start in a second or so. The Tetris example is under 60 kBytes (compressed), and that includes all data as well (there's a sprite/font sheet embedded in the wasm blob). This is in the same general size range as 8-bit BASIC programs. That means that Zig doesn't need a big runtime to work, similar to C, but unlike C# or Java (or even C++ / Rust, unless you ignore most of the respective standard libraries and restrict yourself to a minimal "embedded-programming" style). Here's a similar example (shameless plug), a WASM C64 emulator in under 64 KByte download size. This is implemented in C: https://floooh.github.io/tiny8bit/c64.html https://floooh.github.io/tiny8bit/c64.html I can (most likely) get to the same result in Zig, but with a much nicer "better C" language (and build system!) (...of course there's a huge web browser dangling off the WebAssembly blob, but this is mostly runtime components that are not even needed for this type of WASM programs (we really need smaller, more modularized browsers!).

winter_blue 7y ago
It’s not much of a problem once you have code splitting. React supports code splitting, which lets you split large amounts JS into separate production JS files; load only what’s necessary at first, and load the rest as-needed: https://reactjs.org/docs/code-splitting.html https://reactjs.org/docs/code-splitting.html With a new programming language (like Zig), I would hope that they eventually try to have code splitting be automatic and transparent. For JS targets, you create multiple smaller final JS files instead of one giant JS file. For native targets, you could break out extra code into dynamically loaded .so or .dll files. The real challenge is making this whole process as painless and transparent as possible for the developer.
- flohofwoe 7y ago
  Compiled languages usually have dead-code-elimination (only code that's actually "reachable" is included)... I think the JS world invented the word "tree-shaking" for that. Not loading everything that's eventually needed at startup can be handled with loading WASM modules on demand (which can be handled the same way as loading DLLs in a native application). IMHO it's better to fight code bloat at the root, by picking a language without runtime, minimizing dependencies, and picking the right dependencies.
bluejekyll 7y ago
I’m not sure what you mean by your comments around C vs. C++/Rust. All of them have no required runtime. All of them generally have libc supplied by your OS, which is a runtime. Even in C you must restrict yourself to the runtime your building on, i.e. your target might not have libc. Rust and C++ are the same in the regard that they are capable of doing this.
- flohofwoe 7y ago
  There was a time when Rust executables came with an embedded jemalloc, but that's been fixed in the meantime (I think). But that's not what I mean in the C++ and Rust case, instead: Both C++ and Rust make it quite easy to "accidentally" add bloat indirectly through their standard libraries because they encourage high-level abstractions which may "unfold" into a lot of binary code from very little source code. It can be avoided but requires to give up on many of the high-level language features which Rust and C++ differentiate from (for instance) C.
  - bluejekyll 7y ago
    I can speak better for Rust in this regard, so I won't comment on C++, but I also don't work with #[no_std] often so apologies if anything is inaccurate. jemalloc has been optional in nightly ever since I started using the language in 2015. It switched to the system allocator in the 1.28 release, Aug 2018, it also stabilized the ability to define a custom Global Allocator[1]. > Rust make it quite easy to "accidentally" add bloat indirectly through their standard libraries This isn't accurate, the #![no_std] feature disables stdlib in your library/binary. It requires you to implement a few things, but it will not compile if you use things in std [2]. You may be interested in reading the embedded book[3] which discusses this area in a lot more detail. > give up on many of the high-level language features I also would disagree. You still have a powerful type system, match statements, RAII, hygienic macros, proc_macros, all of the core library[4], optionally have access to the alloc crate[5], cargo, simple unit-test integration, and a growing set of #[no_std] libraries with easy access through crates.io or git dependencies. There's a lot more of course. Point being, there are still a lot of higher-level language features available even in a #[no_std] context, and it's very easy to ensure that your binaries won't compile if this is a requirement and someone tries to pull something in that relies on std. [1]: https://blog.rust-lang.org/2018/08/02/Rust-1.28.html https://blog.rust-lang.org/2018/08/02/Rust-1.28.html [2]: https://doc.rust-lang.org/nomicon/beneath-std.html https://doc.rust-lang.org/nomicon/beneath-std.html [3]: https://rust-embedded.github.io/book/intro/no-std.html https://rust-embedded.github.io/book/intro/no-std.html [4]: https://doc.rust-lang.org/core/ https://doc.rust-lang.org/core/ [5]: https://doc.rust-lang.org/alloc/ https://doc.rust-lang.org/alloc/
dmitrygr 7y ago
> .I think it's interesting that WebAssembly moves the "code bloat problem" into focus again, because WebAssembly apps cannot afford to have huge upfront downloads or long installations. They must start in a second or so. The Tetris example is under 60 kBytes (compressed), and that includes all data as well (there's a sprite/font sheet embedded in the wasm blob). This is in the same general size range as 8-bit BASIC programs. Original Tetris was under 32k, and competition implementations since have been under 512 bytes. 60K plus webkit plus OS is plenty of bloat still
apta 7y ago
> but unlike C# or Java https://github.com/MichalStrehovsky/zerosharp/blob/master/efi-no-runtime/README.md https://github.com/MichalStrehovsky/zerosharp/blob/master/ef...

MaxBarraclough 7y ago

> Despite being young, it already has tons of features Zig is aiming to be lean-and-mean, not feature-rich, but I take your point. I agree it's very impressive how quickly it's come this far.