4 ms·
C/C++ market itself as replacement for assembly languages and proclaim as if all code written in assembly languages is garbage and only C/C++ can solve it, when
by jevgeni 6y ago
C/C++ market itself as replacement for assembly languages and proclaim as if all code written in assembly languages is garbage and only C/C++ can solve it, when majority of it's own useful libraries heavily rely on unsafe assembly code.
So "Pure C/C++" is also marketing when you look at the libraries used by this software are not Pure C/C++, but rely on unsafe assembly code underneath.
Python, PHP do not claim as assembly replacement, indeed Python is synonymous with CPython which is ultimately written in an assembly language.
Also, C/C++ relies on LLVM, which runs on assembly language to generate the target binary.
- dragonsh 6y ago> C/C++ market itself as replacement for assembly languages and proclaim as if all code written in assembly languages is garbage and only C/C++ can solve it Your assertion is not true in C/C++ community, but “Rust is good and C or any other systems programming language is bad” is common assertion in Rust community. Most C/C++ programmers will not mind writing handcrafted assembly. Seen plenty of such examples in game and embedded systems development. C/C++ contrary to your arguments make it very easy to incorporate handcrafted assembly along with C/C++ code, haven’t seen handcrafted assembly code in Rust so can’t say if it’s as easy as C.
- steveklabnik 6y agoRust's inline assembly used to be the exact same as clang's. We recently merged a slightly different version, in the hopes of stabilizing that feature. It ends up pretty similar. (I've been writing a bunch of inline assembly lately, and in fact, ported some C inline asm to Rust. It's not exactly identical, and I did in fact introduce a small bug when doing so...)
- dragonsh 6y agoIt’s good Rust adopted C style handcrafted assembly, earlier didn’t expect it given emphasis on safety at any cost as handcrafted assembly is a dual-edged sword it can help with performance and direct access to hardware, but can also introduce bugs. Porting code will have some stumbling blocks, but given enough time and some resources those mountains can be crossed and may uncover new trail and then leave the ropes for other climbers. Personally I am from the camp who likes the simplicity of lisp. That’s one of the reason in spite of learning some Haskell to learn about FP, didn’t continue long although I like Haskell’s brevity as in “Brevity is the soul of wit”. Haskell really makes it easy to refactor the code, but given large surface area makes it hard to learn and develop. Rust felt the same way although recently saw it becoming more approachable and easy. I was pondering recently if built a modern lisp machines, how good it will be. A hardware directly controlled from lisp instead of C.
- steveklabnik 6y ago> safety at any cost This is not Rust's position on safety. Rust's position is that you should be able to isolate unsafe parts of your program. And we try to give you tools to make them as small as possible. But unsafe stuff was deliberately included in Rust, on purpose, as a tool to be used. I also wonder what a modern lisp machine might look like. Oh well, I don't suspect that will ever happen.
- bronson 6y agoIt would have taken you less time to google ‘rust inline assembly’ than to write this comment.