| |
| ▲ | tombert 5 hours ago | parent | next [-] | | Me neither. I have some very smart friends who think it's the perfect language, but I kind of prefer almost every language that has come out after C++. I feel like the language adds some very strange semantics in some very strange places that can be hard to reason about until you've spent a lot of time with the language. This wouldn't necessarily be so bad if not for the fact that most people who write C++ have not spent sufficient time to understand it (and I consider myself in that group, though I don't write C++). I have mixed feelings on D, but I'm very grateful that Rust came along. Rust is arguably even more complicated than C++, but the good thing is that getting a lot of these complications wrong will simply not allow your code to compile. It's a huge pain in the ass at first but I've become grateful for it. I still write C very occasionally, but Rust has supplanted like 95% of jobs that were formerly C. I still really need to play with Zig. | | |
| ▲ | eska 5 hours ago | parent | next [-] | | Sounds like you would appreciate this talk: https://m.youtube.com/watch?v=wo84LFzx5nI&pp=ygUSVGhlIGJpZyB... Personally I use C or something, anything other than C++ really, if I need something more ergonomic or provably correct. Many excuse C++’s design history with “they didn’t know better”, but the oft forgotten history explained in that video shows otherwise. | | |
| ▲ | tombert 4 hours ago | parent [-] | | I haven't played with Zig yet, but it does look like what I want C++ to be; something unapologetically low level but given some high-level constructs for safety and ergonomics. I haven't had a huge impetus to learn it because Rust has been happily occupying that space for me but it certainly can't hurt to play with Zig. I should write an Ffmpeg codec with it or something this weekend to try it out. | | |
| ▲ | sufficientsoup 3 hours ago | parent [-] | | I've been having fun trying out Zig recently; would recommend. FYI that they released a big batch of API changes in April (version 0.16.0) so be mindful of learning from old resources. |
|
| |
| ▲ | foobarian 4 hours ago | parent | prev [-] | | Would you say Rust is more complicated than C++, or just harder to write? I think that complication a la C++ where there are too many features for the language's own good is a different problem than being a clean language but with higher order features that require a bit more, I don't know, focus? | | |
| ▲ | kstrauser 4 hours ago | parent | next [-] | | I make a strong distinction between complexity, the inherent amount of moving parts in a thing, versus complication, the amount of frippery involved in dealing with the complexity. Rust is complex. It's solving complex problems. It's not complicated, though. There's not much you could remove without creating leaky abstractions. In my opinion, C++ is equally complex. It's solving the same kinds of problems as Rust (although it'd be fairer to say "Rust is solving the same problems as C++"). However, it's hella complicated. There's a vast number of twists and turns to keep in mind if you want to use it, and most of them are things you could not have anticipated by reasoning about it from first principles. If you took the design goals of Rust, and reinvented it from scratch, it'd probably end up looking a lot like Rust. If you were to reinvent C++ from scratch, I bet it wouldn't remotely resemble modern C++. If anything, I bet it would also end up looking like Rust, and the fractal of powerful footguns would be left on the cutting room floor because "that's insane, there's no way anyone would want that". | |
| ▲ | tombert 4 hours ago | parent | prev [-] | | I think there are certainly different complications in Rust than C++. The RAII can be roughly the same in the naive sense, but there's having to worry about Send and Sync and Pin and fighting with the borrow checker and all that fun stuff. Gauging how "complicated" a language is somewhat subjective, so it's kind of hard for me to give a straightforward answer. I think it's certainly easier to be (some definition of) productive with C++ than with Rust. I feel like to do anything even remotely non-trivial with Rust, you kind of have to understand everything, because if you don't do it in the "Rust way", it often won't compile. I think this is a good thing, but it does make it harder to get started. C++ has a lot less consistency and (kind of) more features, and lots of strange semantics to go with those features, and so if people actually use them it can get confusing and hard to read pretty quickly. My knowledge is a bit out of date, to be clear; previously whenever I need something in the C++ domain, I could fairly easily just reach for C and use that instead. Now Rust is available and I think overall better (though I do sometimes miss how utterly simple and dumb C is). | | |
| ▲ | asa400 3 hours ago | parent | next [-] | | > having to worry about Send and Sync and Pin and fighting with the borrow checker and all that fun stuff. To be fair, the alternative to having to worry about Send/Sync/Pin is not "not worrying about Send/Sync/Pin". It's having to worry about correctly enforcing the constraints they describe on your own, without any kind of mechanical help. E.g., not moving data to another thread that shouldn't be and not accessing data from multiple threads that shouldn't be. This stuff is intrinsic. In this sense the Rust mental model is simpler, because failing to uphold these constraints is no longer "your fault", it's Rust's fault. | | |
| ▲ | tombert 2 hours ago | parent [-] | | I don't disagree; I was coming from Java most recently, and a lot of the equivalents of "Sync" and "Send" were just mental notes I was making myself, and I wasn't really used to it being encoded into the type system. |
| |
| ▲ | foobarian 3 hours ago | parent | prev | next [-] | | > have to understand everything, because if you don't do it in the "Rust way", it often won't compile I confess I haven't dug into it much yet, but this reminds me of how Haskell was. By the time you got a program to compile your project was more or less done. | | |
| ▲ | tombert 2 hours ago | parent | next [-] | | In some senses I actually find Rust a bit harder than Haskell. With Haskell the types are immutable and as such they can be happily shared everywhere. That required basically no rewiring in my brain. With Rust, I had to get used to single ownership or explicit cloning. There's an argument that this is "better", but I found it a bit harder to learn. | |
| ▲ | cratermoon 3 hours ago | parent | prev [-] | | Rust is similar. I don't have a link handy, but I've read a few articles noting experience with programming in rust where a program that compiles works. Provided the logic is correct, of course. |
| |
| ▲ | tialaramex 3 hours ago | parent | prev [-] | | > I do sometimes miss how utterly simple and dumb C is You can make an argument that the K&R C "is" an utterly simple and dumb language, but if it was it's long gone and it's also irrelevant for modern hardware. Today because C only has a single kind of reference, the raw pointer, that means if you want references at all (which you do) you need pointers, and to get decent performance from this sort of language you need pointer provenance, and so now all your reference types involve understanding compiler internals minutiae. Bad luck though, those aren't specified in the C language standard, that's a TODO item from the turn of the century. The committee agrees that C pointers do have provenance but declines to explain how that could possibly work. |
|
|
| |
| ▲ | HeliumHydride 5 hours ago | parent | prev | next [-] | | auto_ptr was effectively split into std::unique_ptr and std::shared_ptr. The problem was that before C++11, there wasn't a way to distinguish between copy assignment and move assignment. | | |
| ▲ | eska 5 hours ago | parent [-] | | Correct. But the C++ language is not a language in which one should just say “screw it” and overload the assignment operator of all things while breaking its contract. Stuff like this is why many purists argue that operator overloading shouldn’t be a thing, because it can lead to shenanigans like this. | | |
| ▲ | tardedmeme 3 hours ago | parent [-] | | On the contrary, C++ lets you try such things, discover that they don't work well, and then undo them. |
|
| |
| ▲ | tempaccount5050 3 hours ago | parent | prev [-] | | Holy shit, I didn't know that. Circa 2004 I was in college and took a C++ class. I spent an entire week trying to get my final project working and couldn't for the life of me figure out what was wrong. It was only a few hundred lines and was like an employee record type demo. I spent about 3 hours one on one with the professor trying to figure it out. I remember that removing the auto_ptr stuff and using regular pointers would make it work (because the problem has to be with the pointer stuff right?), but part of the requirements was that I had to use auto_ptr because it was safer or whatever. We tried compiling it on different systems and nothing would get it to work. He ended up giving me a C on the project admitting "it should work, but that doesn't cut it in the business world" or something to that effect which really pissed me off. I just had a chat with GPT about this and that was almost certainly what was causing my program to segfault. std::auto_ptr<int> a(new int(5)); std::auto_ptr<int> b = a; // a becomes null Wild. |
|
