> Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years.
True, but that's why we've got Rust these days. (Rust is actually more optimized than C, e.g. it will automatically reshuffle your structs to get rid of excess padding, and reference accesses will automatically take advantage of compiler-checked 'restrict' constraints, thus equalizing performance with e.g. FORTRAN.)
How is Rust an answer to not liking C++‘a complexity. With the complexities inherent in the borrow semantics (with the box ref cell stuff that comes with it) and the complexities inherent in the type system and trait system, Rudy seems to be at least as complex as C++. In fact this point gets tossed out a lot, Rust is not a C replacement for C developers, it is at best a C++ replacement for developers who want something more complex than C. Not commenting on the quality of the complexity, just that it seems odd that you would say Rust is an answer to disliking complexity.
But note what those complexities buy you: they bring restrictions and limitations that allow you reason _more_ about the code.
This is in stark contrast to some other complex features that allow more stuff to happen with less code.
Rust is indeed, complex in the sense that it's features are non-trivial, but I find it less complex than C++ in the sense that it has 1) less surface syntax (because of lack of historical baggage) 2) more cohesive, principled feature set (again, hindsight is 20/20) 3) it's inherently more limiting, which helps reading, understanding and reasoning about code.
I have to say, I'm really exhausted with the way every single C/C++/Go discussion on HN ends up having someone chime in to say, "Why not just use ~Rust~?". I'm a huge fan of Rust, as I'm sure many of us are, but it isn't some cure-all. It can't just be dropped into any arbitrary use-case where performance happens to be somewhere on the radar, and magically surpass all other options.
Rust is a compelling alternative to C++ for large scale systems software (browsers, video games, etc) but, as of the last time I checked (~2 months ago) it doesn’t scale down as well as C does, or to as many platforms as C does. A lot of this is that C has an unfair advantage from being well established, but an advantage is an advantage .
> Rust is a compelling alternative to C++ for [...] video games
I think it is unlikely to see rust gain much traction in the game dev world. Everything is currently done in C++, and there is low incentives to move to something "safer" or "more secure", because that's not seen as relevant properties by game developers.
What matters for game dev is mostly (not listed in a specific order):
- raw performances
- low latency
- as low as an overhead as possible when dealing with GPUs
- control over memory management
In that context the borrow checker can be an unnecessary constraint, and the safety concern isn't really something that relevant. In the other hand, the rust package manager is really something that is missing in the C++ world, and would be awesome to have for game devs.
I'd say (as a former RTOS lead) that it scales down as well as C, there just aren't as many backends yet. XTensa, AVR, and 8051 are the notable ones missing.
> e.g. it will automatically reshuffle your structs to get rid of excess padding
This is just more complexity as well. It introduces surprising behavior that can burn you when creating interfaces or serializing and forces the developer to know that the compiler will be doing such magic.
> forces the developer to know that the compiler will be doing such magic.
Do you regularly order your stack variables? :D
99.99% of cases there are no expectations about details of a `struct` and having to think about it all the time is a PITA. That's a good example how silly defaults in C/C++ are. Just because I might need manual ordering once in a while, does not mean I want to be bothered by it all the time.
I think what you mean is that current Rust _implementations_ optimize better than current C _implementations_. There's no reason a C99 compiler can't do those optimizations.
>There's no reason a C99 compiler can't do those optimizations.
No, there actually is, the C standard says structs have to be laid out in memory in the same order they're written and C has much weaker aliasing rules.
C99 has the restrict keyword, which guarantees that the pointer won't be aliased. As far as reordering struct members, there's no reason why an implementation can't provide that as an optional optimization you must explicitly turn on. Providing such an optimization and corresponding compiler flag would not disqualify it from being a conforming implementation.
There have been compilers that did this optimization.
179.art, one of the SPEC2000 benchmarks, has some poorly laid out structs. Sun Microsystems was the first company to introduce targeted optimizations for this benchmark.
GCC also had an optimization pass[0] for this. It may have been removed.
Sure, but Cello's complexity turns me off for the same reasons as C++'s complexity. The question isn't "why not use C++?" in isolation, but instead, "why would you use Cello over C++?"
I agree wholeheartedly with this. You can write high level code in C++, but the cost is a terribly complex language and standard library.
In contrast, the C language is fairly simple, except for a few twisty passages (pointer declaration syntax, anyone?). The standard library does leave something to be desired, but that's not that big of a deal given all the third party libraries out there.
It would be interesting to compare the same program written in straight C vs C++ vs Cello, both for developer experience issues (clarity, simplicity, etc.) and performance. I'll have to have a look at http://libcello.org/learn/benchmarks but this does really seem like something I'd like to use on a personal project someday.
You can't compare C++ and C in complexity in general. Any C program that does the same things as C++ does is bound to be just as complex, and even more so since C lacks many of the C++'s niceties.
+1. Pointers are the pain point for beginners in programming generally and sometimes for those who switch from other languages. This article is good start point for them to catch up if they need to.
It's true. It took me ages to understand indirection, and I didn't fully understand its purpose until I was presented with a programming environment that didn't have it. (Programming a PDP-8 with machine language.) I created my own pointer system and tada, the light switched on.
Absolutely agree that Lombok increases Java readability.
If I cannot use JVM alternatives like Kotlin or Scala (for whatever reasons), Lombok is a perfect tool to help beeing productive.
IMO saving one line with @Cleanup is not worth it but if the class doesn't implement AutoClosable, I think it makes code more readable too.
If you absolutely, really need @Data, why not consider making your fields public? I mean, if the only access semantic is going to be exactly the same as public field why have getters and setters in the first place? It just seems dumb to me and not how Java language was designed in the first place. For me it is trying to fix problems of one bad pattern with another bad pattern (now you have two problems).
Readability depends on how large work you do and how much experience you have. Readability is not just how much code you have, it is about using consistent patterns to solve your problems. Readability is how fast and how safely you can move around the code to understand how it works at any level of complexity.
I have 17 years of experience working with Java commercially.
I am blind to getters, setters, builders, and bunch of other stuff. It does not bother me, I can recognize patterns immediately and just ignore them.
What bothers me is when I don't trust my IDE to find all uses of something because some jackass decided to add Lombok to the project and now my IDE does see all code exactly as it will be running.
This is much more of a readability fail.
When you make global refactorings on an application that has over a million lines of code it is absolutely crucial you can trust your IDE to find all uses of something.
This is true as the point of getters and setters is encapsulation, if you totally ignore it there is no real reason to have them at all and public access is a language feature to use.
