3 ms·

I have nothing against the language and if it suits my purpose I will use it, and I have. But I don't want to use it for everything and I don't want to be told

I have nothing against the language and if it suits my purpose I will use it, and I have. But I don't want to use it for everything and I don't want to be told I should. For me it kinda either works or it doesn't. I'm not sure what kind of community it would take, like I dunno some programming language for racists or ISIS or something, but I don't think people should let it bother them. The Rust community reminds me a lot of Bitcoin. You cannot say anything without a reply-guy telling you why you're wrong, even if it's just something minor. I already see all kinds of "it's in the kernel" posts in here too. (Hint: it's "in the kernel" is actually an argument against its use for, say, the web--not for it.) This is just another instance of the tired cycle of people not understanding most problems in tech need evolution, even though the big things come from revolution. Just look at how mad people get about Apple's "forced obsolescence." You cannot start everything from scratch even for revolutionary gains. Are there revolutionary gains with Rust? Well, I don't think it should be that hard to make revolutionary gains over a language that's the same age as I am. It would probably be better if everything was written from the ground up, but unless AI does it for us, that's a lot of wasted man-hours. Apple still hasn't rewritten its entire stack in Swift, much less its kernel, and no one in the industry moves much faster than they do. I would definitely consider starting any PC-based project (Rust doesn't very many platforms) that I might have used C++ or C for in Rust. And I prefer to used either a very low level language or a very high level language or two together (e.g., asm libraries with Python) and maybe one day Rust will work for me for that, though it has a huge runtime too. Mostly that doesn't matter. I just try not to blame the language and it's good features for the obnoxious reply-guy cults that surround it. There are worse languages with good communities and definitely worse communities out there. But no, I don't want to rewrite my MODplayer from 1990 in Rust.

deleted 4y ago
[deleted]
kaba0 4y ago
> The Rust community reminds me a lot of Bitcoin. You cannot say anything without a reply-guy telling you why you're wrong, even if it's just something minor. I overall agree with you and there is no reason to rush switching languages for already established projects, but not even for new ones. But I don’t think that this quoted part is really true about the Rust community. Sure, it has a very vocal minority you hear the most which might fit your description (it’s always those we see first), but I find the more general community very well-versed in low-level programming, more often than not having a strong C++ background and/or some advanced FP knowledge, which is great. I regularly visit r/rust even though I don’t use the language too much, simply because the quality of discussion on certain issues is very high.
- garbagecoder 4y ago
  Look at what happened to my post. A reply guy arguing that the binary size isn't large. I mean, everyone talks about this. Just like I said. It's not even a big deal, I don't care. I have 3mb or whatever, but denying it is just bonkers.
InsanityBlossom 4y ago
> though it has a huge runtime too. Yeah you don't say, it's huge! Like maybe just a little bigger than C runtime. Unacceptable!
- garbagecoder 4y ago
  Way to prove me wrong about reply guys. Rust binaries are large for small utilities. What kind of C are you comparing it to, Windows?
  - tialaramex 4y ago
    You expressed an opinion about the runtime. If your complaint is actually that your Rust binaries are big, that's a different thing. The "reply guy" knows what a runtime is. In a language like Java of course the entire Java Virtual Machine is a runtime. There are lots of nice things to like about this, but it's pretty heavyweight. In C and Rust the usual application software is built with a runtime, it just doesn't do very much. For example the runtime makes the world for your software hospitable before your main() function executes and it needs to arrange that atexit() work for example. Rust's runtime does a little more than C's but not a whole lot. Both C and Rust have a mechanism to write software for an environment where you just wake up naked and setting up even the basic hardware is your problem, as might happen on a tiny embedded SOC too small for an operating system - C calls this "freestanding" and Rust calls it "no_std" but that's not the default. The new complaint your have though is about binary size - your Rust binaries are big often because of mono-morphisation, a compiler optimisation pass which converts all the polymorphic functions used in your program into distinct instances of that function for each type used, possibly inlining some of them where they're used; and because it's statically linked so the binary ends up with all this stuff in it even if that same stuff would be used by other binaries. It's not big because there's some massive runtime living in the binary.

deleted 4y ago

[deleted]

kaba0 4y ago

> The Rust community reminds me a lot of Bitcoin. You cannot say anything without a reply-guy telling you why you're wrong, even if it's just something minor. I overall agree with you and there is no reason to rush switching languages for already established projects, but not even for new ones. But I don’t think that this quoted part is really true about the Rust community. Sure, it has a very vocal minority you hear the most which might fit your description (it’s always those we see first), but I find the more general community very well-versed in low-level programming, more often than not having a strong C++ background and/or some advanced FP knowledge, which is great. I regularly visit r/rust even though I don’t use the language too much, simply because the quality of discussion on certain issues is very high.

garbagecoder 4y ago
Look at what happened to my post. A reply guy arguing that the binary size isn't large. I mean, everyone talks about this. Just like I said. It's not even a big deal, I don't care. I have 3mb or whatever, but denying it is just bonkers.

InsanityBlossom 4y ago

> though it has a huge runtime too. Yeah you don't say, it's huge! Like maybe just a little bigger than C runtime. Unacceptable!

garbagecoder 4y ago
Way to prove me wrong about reply guys. Rust binaries are large for small utilities. What kind of C are you comparing it to, Windows?
- tialaramex 4y ago
  You expressed an opinion about the runtime. If your complaint is actually that your Rust binaries are big, that's a different thing. The "reply guy" knows what a runtime is. In a language like Java of course the entire Java Virtual Machine is a runtime. There are lots of nice things to like about this, but it's pretty heavyweight. In C and Rust the usual application software is built with a runtime, it just doesn't do very much. For example the runtime makes the world for your software hospitable before your main() function executes and it needs to arrange that atexit() work for example. Rust's runtime does a little more than C's but not a whole lot. Both C and Rust have a mechanism to write software for an environment where you just wake up naked and setting up even the basic hardware is your problem, as might happen on a tiny embedded SOC too small for an operating system - C calls this "freestanding" and Rust calls it "no_std" but that's not the default. The new complaint your have though is about binary size - your Rust binaries are big often because of mono-morphisation, a compiler optimisation pass which converts all the polymorphic functions used in your program into distinct instances of that function for each type used, possibly inlining some of them where they're used; and because it's statically linked so the binary ends up with all this stuff in it even if that same stuff would be used by other binaries. It's not big because there's some massive runtime living in the binary.