181–190 of 264 posts
I'm not convinced that it’s worth spending any time supporting most proprietary systems. Maybe not even Windows, but especially the really expensive ones.
Earlier quoted context omitted.
I once implemented a WASM to Rust compiler that due to WASM's safety compiles to fully safe Rust. So I was able to compile C -> WASM -> Rust and ended up with fully safe code. Though of course, just like in WASM, the C code is still able to corrupt its own linear memory, just can't escape the "sandbox". Firefox has employed a similar strategy: https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...
I'd love to check that out. Did it unroll a wasm interpreter into wasm_op function calls?
The compiler is here: https://github.com/CryZe/wasm-to-rust
I have an example of a GameBoy emulator compiled from AssemblyScript to WASM to Rust here: https://github.com/CryZe/wasmboy-rs/blob/master/src/wasm.rs
Earlier quoted context omitted.
I'm saying package managers automate dependency hell and software is and will be less stable & more bloated as a consequence. And one should know how to write a csv parser and yes, even consider writing one if there are obvious custom restraints and it's an important part of one's project. (and yes, numbers were exaggerated; I picked something trivial like a csv parser pulling in 89 packages for effect; the underlyin…
The number of dependencies does not indicate how bloated your app is. Package managers actually reduce bloat because your dependencies can have shared dependencies. The reason C programs may seem lightweight is because their number of dependencies is low, but each dependency is actually super fat, and they tend to link dynamically.
In C this was actually a less problem since you had to copy-paste the shared code into your program and at some level you were manually reviewing it all the time.
Also in Rust people tend to write very small libraries and that increases the number of dependencies. However, many still not follow SemVer et. al and packages tend to be unstable too. On top of additional security issues. They maybe be useful for a short time but in many cases you might need to think the lifetime of your application up to 10 years.
Earlier quoted context omitted.
The number of dependencies does not indicate how bloated your app is. Package managers actually reduce bloat because your dependencies can have shared dependencies. The reason C programs may seem lightweight is because their number of dependencies is low, but each dependency is actually super fat, and they tend to link dynamically.
In the context of Rust it is not about "bloat" indeed. The compiler includes only used bits and nothing more. However, there are other problems, like the software supply chain security. More dependencies you have, more projects you have to track. Was there a vulnerability that affects me? Is project unmaintained and some ill factor took it over? In C this was actually a less problem since you had to copy-paste the sh…
It's not a problem with Rust specifically though. It's not unique to Rust.
> Also in Rust people tend to write very small libraries and that increases the number of dependencies. However, many still not follow SemVer et. al and packages tend to be unstable too.
Don't use random unpopular crates maintained by unknown people without reviewing the code.
Earlier quoted context omitted.
Hi, retro computing person here. I've had a similar debate with Rust evangelists in past Something the Rust community doesn't understand is when they shout "REWRITE IT IN RUST!" at a certain point that's simply not possible Those mainframes your Bank runs? I'm sure they'd love to see all that "awful" FORTRAN or C or whatever other language rewritten in Rust. But if Rust as a platform doesn't support the architecture?…
>Those mainframes your Bank runs? I'm sure they'd love to see all that "awful" FORTRAN or C or whatever other language rewritten in Rust. But if Rust as a platform doesn't support the architecture? Well then that's a non-starter But Rust does support S390x? >Worse still, Rust seems to basically leave anything that isn't i686/x86_64 or ARM64 as "Tier 2" or worse Rust has an explicit documented support tier list with g…
It was actually a pretty good experience. It mostly just worked.
Earlier quoted context omitted.
I'd love to check that out. Did it unroll a wasm interpreter into wasm_op function calls?
There's no interpreter, I just map each instruction to equivalent Rust code. Linear memory is accessed through a trait. The compiler is here: https://github.com/CryZe/wasm-to-rust I have an example of a GameBoy emulator compiled from AssemblyScript to WASM to Rust here: https://github.com/CryZe/wasmboy-rs/blob/master/src/wasm.rs
Have you run into any limitations?
Have you tried running in loop, wasm->rust->wasm->rust ?
This is not-unlike unrolling an interpreter. There was a lua2c project that did something similar.
Earlier quoted context omitted.
Too much complexity, long build times, monomorphization, lack of stability / no standard, poor portability, supply chain issues, no dynamic linking, no proper standard, not enough different implementations, etc. It is a nice language though, but I do not prefer it over C.
> long build times, monomorphization Monomorphization is what causes long build times, but it brings better performance than dynamic dispatch. > lack of stability There was another comment which also never elaborated on how Rust is not stable. > supply chain issues Not a language issue, you choose your dependencies. > no proper standard, not enough different implementations Is that a practical problem? > no dynamic l…
Earlier quoted context omitted.
Being decades old does not make it out of date. Until a few years ago, the Linux kernel was written using C89. While it has switched to C11, the changes are fairly small such that a book on C89 is still useful. Many projects still write code against older C versions, and the C compiler supports specifying older C versions. This is very different than Rust where every new version is abandonware after 6 weeks and the c…
> This is very different than Rust where every new version is abandonware after 6 weeks and the compiler does not let you specify that your code is from a specific version. Do you have any specific evidence? Rust ecosystem is known for libraries that sit on crates.io for years with no updates but they are still perfectly usable (backward-compatible) and popular. Projects usually specify their MSRV (minimum supported…
Earlier quoted context omitted.
Being decades old does not make it out of date. Until a few years ago, the Linux kernel was written using C89. While it has switched to C11, the changes are fairly small such that a book on C89 is still useful. Many projects still write code against older C versions, and the C compiler supports specifying older C versions. This is very different than Rust where every new version is abandonware after 6 weeks and the c…
> Being decades old does not make it out of date. Right, the docs never get out of date if the thing they document never changes. Can you say the same about C++ though? I’ve heard they release new versions every now and then. My robotics teacher didn’t know ‘auto’ is a thing for example.
There is no `-std=1.85` in rust 1.86. You do get `-std=c++98` in both g++ and clang++. A book on C or C++ is still useful even decades later since the version of C or C++ described does not become abandonware at some well defined point after release, unlike Rust releases.
Earlier quoted context omitted.
How you implement algorithms and data structures in C++/rust is semantics at best. The imperative shell of those languages are identical semantically right down to the memory model.
Right, that's why a 20 year old book on algorithms and data structures is not necessarily outdated, but a 20 year old book on C/C++ most certainly is.