4 ms·
I appreciate this sentiment; I've been very hesitant to explore Rust myself, it seems too new, too overhyped, and lacking in foundation (or, as you said, too im
by i336_ 10y ago
I appreciate this sentiment; I've been very hesitant to explore Rust myself, it seems too new, too overhyped, and lacking in foundation (or, as you said, too immature) at this point for me to have absolute confidence in it, or at least the same level of absolute confidence I'd have in C.
I'm definitely keeping an eye on it though, because if it keeps going at the same rate it has the potential to be great in 10 years.
But at the same time, flurries of activity aren't universally positive: it becomes harder to filter out the low-quality contributions that introduce subtle bugs, and smaller/more strict teams have an easier time maintaining stringent quality controls.
PHP and JavaScript very rarely segfault either. Sure, they use virtual machines (PHP's is non-JITed too!); and yes, their CPU and memory usage are comparatively astronomical. But I can only hope that Rust's memory-safety doesn't wind up attracting the same kind of unskilled language architecture "contributions" that PHP has, or wind up with an ecosystem as fragmented as Node's.
- pcwalton 10y ago> But I can only hope that Rust's memory-safety doesn't wind up attracting the same kind of unskilled language architecture "contributions" that PHP has, or wind up with an ecosystem as fragmented as Node's. Going from "PHP has memory safety" to "memory safety causes the quality of code to decrease" is quite a leap. Haskell also has memory safety.
- i336_ 10y agoYou're right. Let me qualify. Haskell as an excellent example of a language that, by design, filters out probably many well-meaning individuals who don't have the requisite level of high-level skill. Languages like Java, BASIC, PHP, etc are easy to get started with, which means those languages attract all types. Perl is somewhat in this class too, along with C++ due to that language's widespread popularity. In PHP's case, the language's lack of inherent default-to-paranoia security settings has bitten it hard, because no real consideration was given to these phenomena (or apparently anything else, but that's a different story). It's a nuanced (social) issue, but solving the type safety problem does make it generally easier not to shoot your foot when you still don't know what you're doing. The hope is that the programmer steadily advances beyond the baby-steps/worsethanfailure.com stage - and doesn't build any large systems that are too big to rewrite before they're decent. Languages like Haskell, Lisp/Scheme, Erlang, C, assembly language, etc are generally difficult to do large-scale useful things with unless you've either studied the language a lot and/or already have programming experience.
- pjmlp 10y ago> PHP's is non-JITed too! It depends on which PHP you mean. http://hhvm.com/ http://hhvm.com/ http://react-etc.net/entry/php-8-to-ship-with-a-jit-compiler http://react-etc.net/entry/php-8-to-ship-with-a-jit-compiler
- i336_ 10y agoOh, that's awesome to hear, that stock PHP will finally be JITted. I wonder how good it'll be... (My primary dev platform is 32-bit, so I can't take HHVM seriously.)
- sidlls 10y agoI'm not sure what "memory safety" has to do with skill regarding "language architecture." In fact, I'm not quite sure what you mean by that whole bit. Memory safety isn't a bad thing. But maybe pushing it as the thing will end up making it harder for newer systems programmers to be comfortable dropping into "unsafe-Rust" when it's necessary out of fear, or harder for them to learn the lessons that C and C++ folks have had to when they do have to use "unsafe-Rust". We just don't know what the impact will be in that regard. It's part of being a young language--it just needs time to develop.
- i336_ 10y agoYour second paragraph pretty much nails my thinking exactly. Memory safety is a very good thing, but having to manage memory/the stack/etc is kind of an IQ test that filters out contributions of generally low quality. At least that's the theory. Thinking about it, there are probably people out there who can nail things like memory management but are terrible at eg higher-level application architecture to such an extent that they're ultimately not competent engineers anyway. It's possible at least.