271–280 of 307 posts
Earlier quoted context omitted.
OOP is not C++ best practice these days. For me C++ best practice is: - Smart pointers - auto and const references all over the place - RAII - Pure data structs - Free functions - A little bit of templating but not too crazy Modern C++ reads a bit like JavaScript strangely!
> OOP is not C++ best practice these days. I didn't say it was. I didn't say anything about best practice, only about familiarity.
Earlier quoted context omitted.
Indeed, but to be fair, Rust's smart pointers can be used to create memory leaks just as easily as C++'s. (Overall I think Rust is a much better language than C++, though).
You don't even need a smart pointer: `let bar = Box::leak(foo);`
Earlier quoted context omitted.
I'm quite nooby in both Rust and C++, but for the little interactions I had, I felt like Rust had a much clearer path forward than C++ when I was in doubt, and "how to write in good style" was more obvious. This leads me to the assumption that building a Rust culture is probably easier than building a C++ culture, because it is easier to get junior developers and those coming from other languages up to speed.
Yep. The one big beginner “mistake” I see people make in rust is overusing Box / String / Vec. Rust code that allocates everywhere can be even slower than javascript. The reason? Malloc is slower than you think. Slower than short allocations in V8 or Go. If you want performance, make friends with &str, &[], >, bumpalo, SmartString and SmallVec. (Or similar crates). Removing allocations from the hot path can improve p…
Slower than V8, definitely possible. Slower than Go, very unlikely, since it doesn't have a generational or compacting gc.
Earlier quoted context omitted.
There are settings you can place in .gdbinit to avoid stepping in to internals of anything you don’t want to step into, be it std library classes/functions or your own code. Much nicer than hacky ifdefs.
> There are settings you can place in .gdbinit to avoid stepping in to internals of anything you don’t want to step into, be it std library classes/functions or your own code. This is exactly what I need. For both, C++ and Rust smart pointers. Can you share any more info on how to set this up?
https://sourceware.org/gdb/onlinedocs/gdb/Skipping-Over-Func...
Earlier quoted context omitted.
I would love to hear more about "fsync saga" if you have any references. I know that PostgreSQL had "problems" with fsync(), but they never ended. They just accepted defeat, but so would everyone else who relies on filesystems to store their data. It's even more ingrained than that. The way hardware works, and, especially, the communication protocols around it (eg. SCSI or NVMe) are structured, fsync() is always goin…
See this chain of articles: https://aphyr.com/posts/284-jepsen-mongodb The mongodb organization repeatedly poo-pooed the issues with data loss, and only after repeated public exposure of the issues did they do anything about it. I don't know why people aggressively deny this when anybody can just google it and judge for themselves.
Earlier quoted context omitted.
Segfaults happen, you run valgrind/asan/tsan etc. As long as the codebase is not horrendous its easy to fix. Third party packages complicate things, have to choose/use wisely/appropriately
In Rust they are really rare. Like vanishingly small numbers of them. C++ definitely. SegFaults happen. Sometimes they are even in prod. Rust not so much.
C++ has been around for... what?.. 40 odd years? And any non-trivial project still links with C libraries.
I don't see this problem somehow going away in Rust w/o some revolutionary changes in operating systems, which is the major supplier of decrepit but unavoidable libraries you have to link with in order to get anything done.
Earlier quoted context omitted.
This is the one issue I personally have with C++. How do I `pip install boost`?
Note that a lot of the pip projects are implemented in C++. You install packages for the environment you are targeting. A lot of folks use Conan or vcpkg for pure C++ dev.
Earlier quoted context omitted.
Says who? I love prototyping things in Rust.
Both viewpoints make sense; whether Rust is good for prototyping depends on the domain. If it fits the borrow checker well (like in CLI apps, stateless servers, data transformation) then the borrow checker fits beautifully and seamlessly. In other settings (complex turn-based games, some compilers, GUI), the borrow checker can cause some artificial complexity and prototyping slowdowns compared to other paradigms.
In fact I like Rust for prototyping precisely because I don't yet have tests, and the extra compiler diligence frees me to focus on the prototype.
> Rust is easy to learn. For seasoned C++ programmers, Rust is easy to learn. When they first start out, Rust learners usually spend most of their time making sense of ownership and lifetime. Even if they don't explicitly express these concepts in code, experienced C++ engineers always keep these two concepts in mind when programming in C++. Finally somebody understands this.
Though, people tend to gloss over that C++20 is decently comparable to Rust in terms of semantics and safety, the issue is very few C++ codebases are modern and the footguns are still lurking for the careless.
That said, Rust iterators are very nice and the async story completely mocks the C++20 coroutine nonsense.
Earlier quoted context omitted.
Hot take, I feel like people that complain Rust is hard typically write bade code in other languages. Rust is just preventing you from making common mistakes or using patterns that make your code hard to reason about and debug later.
As a fellow Rust user, please stop saying this. Not everyone who codes like us is a bad programmer. It's this kind of sentiment that gives us a bad name. Rust may influence us into patterns that are better in some (likely even most) situations, but not always. Sometimes the situation calls for other approaches, and that's okay.