3 ms·
> I keep this bias voluntarily, because Rust is generally touted (hyped?) as a Silver Bullet, and I'm wary of Silver Bullets. Hrm. We're not progressing on tha
by pdimitar 3y ago
> I keep this bias voluntarily, because Rust is generally touted (hyped?) as a Silver Bullet, and I'm wary of Silver Bullets.
Hrm. We're not progressing on that front so maybe it's time to stop. But I don't think Rust is "touted as a silver bullet". Rust is simply better than many other languages if you have criterias X, Y and Z -- and it just so happens that those X, Y and Z are actually things that fix problems that exist quite often out there. This is not "touting".
Forgive the generalization but you do seem to belong to a group of people who get annoyed if others praise something and if they hear about it often. Granted, popularity is not a signal for quality (and we as senior techies should possess and practice this kind of critical thinking much more than many other people!) but this is also tech and I'd like to pretend that at least part of all decision-making processes are based on merits. ;)
I'll give you a non-tech example. "Game of Thrones" was hugely popular and I was acting seemingly like you do now -- I kept hearing about it so much that I actually made it a goal to NEVER engage with it.
Obviously that's a bit irrational, if not a bit damning for the person practicing such methods in their lives.
But again, in tech it's not exactly the same. If you keep hearing about Rust, then critical thinking and objectivity demand that you ask yourself why and assess it with a clear head and without bias.
You seem to claim to have (mostly) done so but reading into your seeming-rebeliousness against Rust, I have some doubts. Hence this call-out (and the thread between me and you itself).
> Yes, there's no zealotry here, and it's great, but I'm exposed to a wider community than HN people.
I understand, yet IMO you should make up your own mind and not get irritated just because something gains popularity.
Sometimes there are good reasons for the popularity. Now in my day work I am pissed that the languages I work with don't have sum types. :\ Fixes so many bugs...
> Current me knows everything about code, and my future me which inherits that code.
You are surely aware that is not enough unless you actively go out of your way to check how other people do things, right? But I won't pursue this further, I believe we're in agreement and only the degree of stuff is under question from my side.
> As a recovering grumpy, I'll do. I don't like to be bitter grampa (to be). I'm fine with the grampa part, but not with the bitter part.
Well that's all that I asked for really. Thanks.
> Of course, but I'm trying to incorporate the good practices I can use as a team of two (as aforementioned).
And one of them should IMO be: "when you need something that you'd write in C/C++ and it is not highly specialized (meaning no good Rust library support) then try writing it in Rust".
Several huge organizations came forward and said memory unsafety contributes to at least 70% of all zero-day vulnerabilities. Surely at this point being religiously fanatical about memory safety should be common sense, I'd think.
> My personal state of the art of this practice is at [1]
You didn't have to show me, appreciate it. I do like the well-commented code. But I'd definitely remark that a huge if/else should be broken down into two functions. Maybe the else clause even further -- talking about `if isInputFromPipe(logger)...` in `initFlags`. I'd like the code to tell me what is it doing, not describe it to me how it's doing (and I still don't know the "what" part while reading such code). But that kind of stems from Golang's imperative nature and not everyone wants to write code in mostly FP style. I get that.
> Same, no hard feelings here. I can say that you're good sport even, and I don't use this lightly. I enjoyed what you wrote and writing this comment.
It's important to disagree productively. :)
- bayindirh 3y ago> Hrm. We're not progressing on that front so maybe it's time to stop. I thing we don't have to progress on anything immediately to discuss productively. You put your ideas forward, I put mine. I get yours to ponder on them later, (and I assume) so do you. I think I agreed that my ideas may are colored due to what I have gone through, and accepted to revise them. I'll see where I can go after taking that step. :) > if you have criterias X, Y and Z -- and it just so happens that those X, Y and Z are actually things that fix problems that exist quite often out there. This is not "touting". Yes, and I agree that Rust is good for fixing these X, Y, Z. However, as I said what I have gone through is different. Just hold that thought. > Forgive the generalization but you do seem to belong to a group of people who get annoyed if others praise something and if they hear about it often. I don't mind being generalized. We're humans after all. However, your generalization is wrong, sadly. I don't get annoyed by praising or popularity. I get annoyed by being pushed to accept an idea without thinking on it. What I have gone through is akin to being surrounded by people chanting something, and I expected (or even bullied) to chant the same thing without understanding what I'm buying into. I prefer to do my own research and make my own decisions. Trying to take my freedom from me annoys me with no end. For the record, I have a Vagrant VM which installs a turnkey Rust development environment (IOW, I started to dig into it), yet I put it on ice until gccrs is released, and learnt Go instead, because it proved to be a better tool for what I was trying to build. > I understand, yet IMO you should make up your own mind and not get irritated just because something gains popularity. Built on previous generalization, just passing if you don't mind. > You are surely aware that is not enough unless you actively go out of your way to check how other people do things, right? But I won't pursue this further, I believe we're in agreement and only the degree of stuff is under question from my side. We're in total agreement. I'm not a team powerhouse by working solo. I just try to do my best, but I can't build my missing parts without a team, and I'm willing to do that if I work in a team. I like developing tools, but I'm not the person who upends team dynamics because who wants to be the only one. I like the craft itself, and will happily adapt to the environment I work in (sans the bullying part, ofc). > And one of them should IMO be: "when you need something that you'd write in C/C++ and it is not highly specialized (meaning no good Rust library support) then try writing it in Rust". I understand and I agree, but I just can't port a library developed by a team of specialized researchers and hand-optimized for a ton of hardware/processor architectures [0] by myself. I can only write what I'm planning to develop in Rust, maybe develop a couple of libraries along the way, but please don't ask me to license them with MIT. That's not gonna happen. I'm not a GPLv3 zealot, and contribute to MIT projects, but my projects are for the users of these projects. Not for the developers who want to build upon them and forget to add credits because deadlines. > You didn't have to show me, appreciate it. Just wanted to share for the feedback, not as a proof, because I value comments and feedback, that's all :) > ... talking about `if isInputFromPipe(logger)...` in `initFlags` That's not a part of the code I'm very proud of, but it's not a hot path, is relatively self contained, and it works. > But that kind of stems from Golang's imperative nature and not everyone wants to write code in mostly FP style. I get that. I'm coming from C64 era. I think imperative (or how computer thinks), and write my code. Starting FP with a Lisp is on my roadmap, and the notes are in my backpack, but that road is a bit bumpy right now. :) > It's important to disagree productively. :) Certainly! :) [0]: https://eigen.tuxfamily.org/index.php?title=Main_Page https://eigen.tuxfamily.org/index.php?title=Main_Page