851–860 of 929 posts
Earlier quoted context omitted.
Stuff like Slotmap should be part of the standard library instead of some github project with open issues that isn't updated for over a year.
Yeah. FFS, they don't even have a JSON parser in the standard library...
I'm just a programmer who's been doing this for 20 years. I don't have the credentials of Mark, who is a legend. But I fully agree with him. There will be specific exceptions, but if you have the choice between Rust and C++ you would be making a big mistake to not choose Rust. The language is simpler, cleaner, safer, and more enjoyable to work with. The build tools are far more pleasant. The IDE experience is compara…
I learned Fortran, PL/I and IBM 370 Assembly Language in College. I learned C and then C++ because I loved my craft.
Earlier quoted context omitted.
That's a bold claim (since both languages are Turing complete). I presume you meant safe Rust? But that's kinda the point. If something is memory tricky it is supposed to go into unsafe so you can make a safe abstraction around it. Unless you meant actually all of Rust. In that case, please share what's inexpressible in Rust.
No. I mean that there is a great deal C++ can capture and present in a library that cannot be expressed in Rust. Much of this will never be in Rust because of this or that early choice of direction. At the most basic level, in Rust you cannot overload operators. You have no opportunity at all to code a move constructor. I could list off others all day long, but you probably would not understand most. Then there are t…
I gave you a working example of operator overloading in Rust a while ago.
Why do you still state that Rust doesn't allow that? Is there a problem with the example?
I know a lot of different languages and have a feature matrix for reviewing them, and I would know if operator overloading didn't work since it's a row in there. It definitely does work in Rust (it's similar to Python's operator overloading).
Earlier quoted context omitted.
They certainly don't care enough to enforce it. >Dynamically linking to a MIT lib is not the same as distributing an MIT lib Would you mind citing the clause that makes that distinction?
I’m not a lawyer and this is not legal advice, but… > The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. When statically linking, you’re including a copy of the software, so you’re required to include the notices. When dynamically linking, you’re not including the software. Seems pretty straight forward to me.
Earlier quoted context omitted.
The fact that Rust has a whole other ecosystem is the main thing that gives me pause. For all their faults, C and C++ targets the ecosystem you have: gems, pip, Conan, Nix, ...doesn't matter. They don't expect you to port to a new ecosystem. They can contort to meet your needs. Herb Sutter's latest proposal and, to a slightly lesser degree, Carbon are more interesting in that respect.
Nope, C and C++ target the C and C++ ecosystem. If that’s the ecosystem you have then presumably that’s because your a C or C++ developer and that’s what you’re used to. Personally I find installing C and especially C++ libraries a massive pain.
Earlier quoted context omitted.
Wut? Makes no sense to me.
Here's an example of C++ code written intentionally with all the latest C++ features: https://gist.github.com/caiorss/c7db87df674326793431a14006aa... It looks pretty much nothing like a C program doing the same job. A lot of those features were made to make C++ a safer language to use. Eg, with a construction like: for(const auto& it : ast){ You can't accidentally walk past the end of the array by going one item too…
Checks linked resources
while(!ss.eof()){
ss >> token;
p >> x;
if(!p.fail() && p.eof()){
struct stack_empty_error: public std::exception{
const char\* what() const throw(){
return " ==> Error: stack empty." ;
}
};
auto x = _stack.back();
_stack.pop_back();
return x;
Also, when I press Ctrl-D, I get an endless loop printing "EXPR+> stack". Typical C++ program...
Earlier quoted context omitted.
If you think memory-safe languages are some anti-jailbreaking/rooting conspiracy... well, have you heard of Java? No. Rust saves countless hours of frustration by eliminating frustratingly-hard-to-debug mistakes that humans commonly make when writing programs. Rust is pedantic, so you don't have to be. Rust saves companies money because Rust software requires noticeably less maintenance. Try it sometime. Don't worry,…
It's not just about jailbreaking or rooting. A lot of other user-hostilities can be defeated because something isn't quite as secure as it could be, and from that perspective, making things "more secure" is active hostility. "We are not truly free if we do not have the freedom to make mistakes." I guarantee that man will always be able to break what man can make Not with the rise of strong crypto. Java isn't used for…
We don't build bridges that fall down and declare that we've done it out of the need to preserve freedom to experience gravity.
Software engineering is an engineering profession and building reliable software that works as intended is the goal. It's never been the goal to build breakable software... It's been a side effect of decades of engineering compromises to make a product buildable with the tools and resources available at the time. Tools and resources are better now, and it's high time we stopped building things that make it easy for an attacker to steal from your grandmother by compromising her bank's website.
I can assure you that systems will still be hackable and I can assure you that if they aren't, it will be of value to somebody to build a flexible at-your-own-risk system from first principles. The vast, vast majority of humanity is best served by having tools that do what they are designed to do.
I would think that someday I would stop getting shocked by things I see on Hacker News, but the "We need to keep using c++ because buffer overrun attacks are good actually" mentality is a new one on me.
Earlier quoted context omitted.
bizarre. not even sure what that linked comment is supposed to do for your argument here. The idea that rust is some plot by "companies" to "prevent jailbreaking" is ..... rough, man.
They're not trying to burn the frog but boil it slowly. This is just another one of a series of small steps.
Earlier quoted context omitted.
> In other words, it's possible to put C and C++ on the same footing as Rust when it comes to memory bugs; No. This is only true if you don't care about occasional bugs. e.g. hobby projects. But if you're talking about mission-critical or security-critical software, there is a gap - or a canyon - between C vs C++ vs Rust. And no amount of extra "efforts" by the programmer's part can bridge those gaps completely.
The true test of what I said is "show me the code." The code is my `bc`. [1] Find a memory bug, any memory bug, in my `bc` after 1.0. Rust has occasional memory bugs too; I mentioned that specifically. It still happens. So if you really are correct, break my `bc`. [1]: https://git.yzena.com/gavin/bc