I think it's much simpler than that, because I did it myself, on a HPC scale high performance materials simulation code. Is it simple? Yes. It's easy? No, because you need to design for that and be mindful during implementation (const correctness, guarantees by design, valgrind tests, unit sealing, etc.). I think it can be made much simpler with smart pointers, etc. if speed is not that important.
We push humans too much to develop things fast. C++ is not very conductive to that, yet it's the only tool which works in some cases.
I won't retype my views about Rust because it's all over this thread. Just I'll tell that I'm against vilifying C/C++ as evil because they can be held wrong. I believe things can and shall be able to held wrong. Knowing failure modes and shortcomings is a plus. Because you can then hold dangerous things right, and appreciate things which promote holding things right.
> I think it can be made much simpler with smart pointers, etc. if speed is not that important.
Why all the complex dances, and you even lose performance by doing them as well? Use Rust and it's going to solve most of those troubles for you.
Though granted, you can make a mess in Rust as well (by using various escape hatches) but you really have to try in order to do so.
> We push humans too much to develop things fast.
I agree, most programmers agree in fact. So when are you talking in front of the UN and when do the worldwide regulation against this problem begin? When will companies start getting a 10% revenue fine for not adhering to the regulation?
...You're preaching to the choir here. We all know the ideal theoretical reality. I too wish I had more generous deadlines.
> Just I'll tell that I'm against vilifying C/C++ as evil because they can be held wrong.
It boils down to: Rust can be held wrong in much less ways than C/C++. That's the core argument. Everything else is more or less a distraction, my own comment here included.
Computers should work for us, not we for them. Rust helps my human brain not to misstep. You'd likely label me as incompetent but I'd disagree and say "none of the gnarly details of the bound checking and lifetimes arw interesting for me, I'm writing the code, compiler will correct me if I assumed wrongly". Me and the compiler are a team and we both do what we do best.
> I believe things can and shall be able to held wrong.
As another poster said: do it in your hobby work. If I have to deal with subtle memory safety errors in your professional code just because you have such a life credo then I will curse at you and label you as incompetent.
I love tinkering. I keep it to myself and to other hobbyists. Professional work should be, you know, professional.
> Why all the complex dances, and you even lose performance by doing them as well?
Simple. Because Rust doesn't have BLAS, at least not yet. Though I doubt that I'll ever migrate my high performance code to Rust.
> So when are you talking in front of the UN and when do the worldwide regulation against this problem begin?
No need to snark. I write my comments as streams of consciousness, and I just wrote what I feel. I know it's a simple fact, but I'm not here for stone matches.
> Rust can be held wrong in much less ways than C/C++. That's the core argument.
Yep, and I'm very aware of this one. I think I need to clarify once more: I'm not against Rust. I'm against weaponization of Rust (via LLVM, via RIIR w/MIT, radical evangelism, etc.).
> Computers should work for us, not we for them.
I agree. I want to freedom to explore. Because I'm a hardware geek, and I like to PEEK, POKE, and understand.
> You'd likely label me as incompetent...
No, I don't do that. You have a very wrong image of me in your head. I'm only pro-choice in programming languages. If they are not interesting for you, that's OK, plus your interests are not my business. I have no interest in dictating anything to you or to form you to my liking.
On the other hand, I operate from a slightly different perspective. When I write code, I execute it in my mind at the same time, like a computer. Lifetimes, etc., the whole circus. This helps me to write better code. Then I pass it to compiler, with -Werror nonetheless. The code I write compiles without warning, otherwise it's unacceptable.
> As another poster said: do it in your hobby work.
The thing is, my work is a hobby that pays. I always select the tools before starting a job. What we're writing? Is it speed critical? Is it security critical? What happens if it fails, etc. Put the specs, define the required tools for the job, then start the blueprint in that language. If that's Rust? Go? C++? Erlang? Bash? Malbolge? Select the appropriate one. Don't know it? Doesn't matter. Go, learn.
This is how I do it. I'm not a zealot living with a single language. There are no bad languages, only bad solutions to problems at hand. My beef is always with the community of a language, not the language itself.
That's being said, I'm waiting gccrs to start Rust, because I have a single rule: Toolchain must be GPL licensed. I don't like to depend on a toolchain a vendor can fork and close. The code must stay buildable.
> Simple. Because Rust doesn't have BLAS, at least not yet. Though I doubt that I'll ever migrate my high performance code to Rust.
Perfectly valid, though in the light of this I'd say your arguments against Rust come off as biased in favor of a single use-case and I am sure you're aware of this.
> No need to snark.
Okay, though I am guessing you understood that the snark was because you criticized something that's beyond the control of at least 95% of all working programmers everywhere. I get the stream of consciousness part, I just didn't feel that that part of your comment was helpful of the discussion. Sorry if I came across as rude.
> I think I need to clarify once more: I'm not against Rust. I'm against weaponization of Rust (via LLVM, via RIIR w/MIT, radical evangelism, etc.).
I've read all your other comments and I am not disputing that you are arguing in good faith; IMO that much is visible, I just find it slightly puzzling how your stance on it is kind of going up and down. :)
The second part of your quote above is a bit bizarre because it's been quite a while since I've seen Rust zealotry on HN (at least 2.5 years IIRC). Every community has bad apples, IMO you don't need to preemptively defend against the a-holes that every community has (and that haven't shown up on HN for a long time, as far as I can tell at least).
> The thing is, my work is a hobby that pays.
While that likely does wonders for your mental health (and makes me envy you and get saddened that it's not the case for me) it also comes with this unique drawback that you already observed: you get called out by the programmers who don't work in the area(s) they love for not utilizing guard rails that are a good practice in a team setting. This is also likely made even worse by the fact that you work solo.
Again, good for you, for real, but that also makes you biased in a way that seems... not very team-cooperative. I don't stamp PRs with an approval if they don't cover a certain baseline of testing, type specs (for dynamic languages), some docs / comments, and the like.
Tinkering is nice and all but I'd probably make your life living hell if I had to review your PRs. :D (Have to stop here for a few secs to giggle.)
> I'm not a zealot living with a single language.
Nor is any Rust dev that I knew (dozens). ¯\_(ツ)_/¯
> My beef is always with the community of a language, not the language itself.
OK, that's valid but I'd still urge you to reassess your opinion of the Rust community. I haven't met a legit a-hole in years. There are always some dismissive people on this or that forum but meh, vanishing minority to the point that I don't remember the last time I received a semi-snarky response on a subreddit or on the Rust Users forum.
And finally:
> You have a very wrong image of me in your head.
That is quite likely, written text does not carry tone and spirit at all. Though that always has two sides: I misconstrued some of your comments more negatively than I should but maybe you also didn't come across as neutral as you are saying that you are (example: you seem to be negatively biased towards the Rust community).
No harm done IMO, and I don't think that I disagree strongly with anything you said. I am mostly saying that you working what you love and working solo is keeping you quite disconnected from what are good team practices. Maybe you have a compiler in your brain as you have alluded to but I will trust a good test suite over a human brain every day.
Yes, I'm pretty aware of this, and I keep this bias voluntarily, because Rust is generally touted (hyped?) as a Silver Bullet, and I'm wary of Silver Bullets. So, I want to highlight that fact.
> Sorry if I came across as rude.
No hard feelings. As I said, I'm not under delusion of a perfect life. I just said it.
> I just find it slightly puzzling how your stance on it is kind of going up and down. :)
I have a habit of mirroring the tone of the person I'm talking with. Combine it with the fact that English is not my native language, it's possible that "tone adjustment" is far from perfect.
> it's been quite a while since I've seen Rust zealotry on HN...
Yes, there's no zealotry here, and it's great, but I'm exposed to a wider community than HN people. Unfortunately, HN represents very small percent of the programmers around. A great talk I like about this issue is Robert Martin's "What Killed Smalltalk Could Kill Ruby, Too" [0]. Let's say, I'm marred and bitter from tons of zealotry and flamewars over the years (yes, I'm not young folk).
> While that likely does wonders for your mental health... [Snipped for brevity]
First of all, thanks. I pray that you work in a place you love and never work again. I'm very aware that how being solo makes me different and biased, and I think I highlighted at a couple of places.
On the other hand, I understand what teams and team-related activities are important for code quality. Let's say that I work as a team of two people. Current me knows everything about code, and my future me which inherits that code. So, I always code and comment for my future self, who doesn't know anything about the code. I always sharpen my axe, and try to improve myself as a "team of one". My personal state of the art of this practice is at [1]. I'll reflect what I have learnt from this project to the next one. The fact is while I do extensive C++ testing, I yet to pick up Go's testing abilities. That'll be the next step probably.
> Tinkering is nice and all but I'd probably make your life living hell if I had to review your PRs. :D
Give it a look at [1], and maybe [2], and let's have a chat again. I'm not perfect, for sure, but I think I'm no basement dweller when it comes to code and docs quality. :D
> OK, that's valid but I'd still urge you to reassess your opinion of the Rust community.
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.
> No harm done IMO, and I don't think that I disagree strongly with anything you said.
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.
> I am mostly saying that you working what you love and working solo is keeping you quite disconnected from what are good team practices.
Of course, but I'm trying to incorporate the good practices I can use as a team of two (as aforementioned). Also, I'm mingling with more Free Software teams than I might show.
> Maybe you have a compiler in your brain as you have alluded to but I will trust a good test suite over a human brain every day.
I'll trust my brain first, then evaluate that with the compiler, then evaluate the end product with a good test suite. Then feed what I learnt to myself, so I don't repeat the same mistakes as much as I can. My intuition gives me perspective, but I always operate on the assumption that I'm the worst programmer in the universe (no kidding).
> 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.
> 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. :)
> 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.
Yeah, happened to all of us. Sorry that it happened to you. My discussion with you was sitting on a much more reasonable ground, I believe: namely assess the thing (in this case thing == Rust) by its own merits and niche. And you said you are open to that so my work here is done, so to speak.
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.
On your point 1 here I'll only say that software licenses don't bother me at all. As long as the license does not say "you cannot use that OPEN source software in your CLOSED work or else you owe me" then I'll use it and not give it a second thought.
Morality and legalese concerns in software is something I just don't want to deal with for now, likely forever too.
As for your point 2... actually I did the same. I do love Rust but I had a number of mini projects, commercial and for my own use, where I really wanted to get something off the ground in literal minutes. Golang served me there better than Rust. When I get a little more free time I plan to achieve the same friction-less experience with Rust because it is not like that out of the box but I know for a fact that it can be made to be like that.
> 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 understand. We touched on this already, suffice to summarize that in this case you're fully aware that your assessment is also a bit niche, you know that for less specialized work Rust can be a fantastic fit, you are open to try it and get intimate with it in the future, and as I mentioned already -- that's all I wanted to achieve when discussing with you.
We push humans too much to develop things fast. C++ is not very conductive to that, yet it's the only tool which works in some cases.
I won't retype my views about Rust because it's all over this thread. Just I'll tell that I'm against vilifying C/C++ as evil because they can be held wrong. I believe things can and shall be able to held wrong. Knowing failure modes and shortcomings is a plus. Because you can then hold dangerous things right, and appreciate things which promote holding things right.