[macintux]

Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years.

As the creator says, it’s not for production use. If I’m doing a side project, I’d give this a serious look.

[zozbot234]

> 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.)

[throwaway17_17]

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.

[GolDDranks]

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.

[_bxg1]

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.

[oddity]

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 .

[dgellow]

> 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.

[monocasa]

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.

[firethief]

> and reference accesses will automatically take advantage of compiler-checked 'restrict' constraints,

I think that's temporarily turned off because emitting noalias attributes so much exposed some llvm bug. See: https://github.com/rust-lang/rust/issues/54878

In the long run though, yeah that is an inherent optimizability advantage of Rust vs. C.

[voldacar]

C has restrict

also, gcc and llvm can infer restrict much of the time if you don't manually use it

and I fail to see how having explicit control over struct layout is ever a bad thing

[PeCaN]

'just use rust' is like some 2010s advice everyone's moved on to ATS now

[flukus]

> 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.

[dpc_pw]

> 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.

[pmiller2]

> Rust is actually more optimized than C....

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.

[PeCaN]

>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.

[pmiller2]

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.

[tjalfi]

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.

[0] https://www.research.ibm.com/haifa/dept/_svt/papers/golovane...

[loeg]

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++?"

[pmiller2]

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.

[axilmar]

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.