simplotek

> C++ is famous for being bloated.

No, it isn't. If anything, it's famous for its spartan standard library. It only received smart pointers in C++11 and a file system library in C++17.

> It desperately needs to be able to remove stuff but it can't because of its desire to maintain ABI compatibility with binaries compiled on older versions.

This is outright wrong. Some standards already deprecate and remove features, like std::auto_ptr going away in C++17 or volatile in C++20.

You're trying to pass off too many baseless assertions as undisputed facts.

> I think in 10-20 years the C++ community will regret enshrining "modern" into so much of the literature.

In other circumstances I would agree, but cmake coined the term "modern cmake" when they released cmake 3.0 and with it their support for target-based projects, and after a couple of decades of "modern cmake" a sizeable portion of the cmake community still failed to update their code.

> Long build times

Build times in C++ projects nowadays are mainly the result of naive approaches to project structure and total lack of care towards modularity. On top of that we also have helpers such as ccache and the like to further reduce build times by not having to build at all.

> Back in 2010, I read the c++faq religiously, tried to warp my projects to it in college, and in the end produced nothing because i was too busy trying to be a big boy.

You're just admitting to having created your own problem, and suffering consequences for it. Nothing in your comment pertains any issue with reading coding guidelines in general or specifically the C++ ones, let alone any comment in particular.

> Now, the c++faq is obsolete.

That's your personal assertion, and one that does not sound informed at all.

I keep track of the C++ coding guidelines. In general they are nice rules of thumb. No one wants to build a religion around them.

> If the language spec is such that operator -> can’t have a sensible signature, (...)

The language spec has zero to do with this. You're commenting on a discussion on static code analyzers. The specific gotcha you're commenting on mentions that the overloaded operator -> from smart pointers returns a raw pointer to the object being managed, which apparently causes static code analyzers to lose context (it's a raw pointer). The gotcha just mentions a way to help out static code analyzers to not lose context. There's nothing wrong with the spec. At most there's a tip to help out current static code analyzers keep track of semantics.

The worst part of people criticizing C++ is that 9 times out of 10 they base their criticism on ignorance or misconceptions.

> Ah, "make C++ better by adding more features", we meet again

What's your plan to improve something that does not involve adding improvements?

> How are you going to work on long term plans with elections every 2 or 4 years?

The executive and legislative branch make decisions, supposedly seeking consensus as part of their decision-making process.

If you're arguing that consensus are not important or a basic requirement of a democracy, and long term plans can only be implemented if they are dictated by an autocratic government then the problem is another one.

> The problem with Brazil is that the country is just too big. It will never happen, but I'm confident that the solution to Brazil's rampant corruption and violence is to break up the country.

What leads you to believe that your proposal is effective? You're just arguing in favour or removing layers of accountability as a solution to rampant corruption.

> I mean the goal is more performance, especially if you can get more performance out of the same hardware.

Are there actual numbers demonstrating this?

I mean, people are advocating wasting billions revamping infrastructure. What kind of performance are you hoping to buy with those billions? And are those gains worth it, or is just sake for the sake of change?

Sometimes things are indeed good enough.

> What you're talking about though isn't just coming up with new ideas or even new products. It's replacing hundreds of billions in infrastructure wholesale.

I'd put it differently: it's paying up hundreds of billions in infrastructure to have some sort of gain.

And which gain is that exactly?

I see a lot of "the world is dumb but I am smart" comments in this thread but I saw no one presenting any clear advantage or performance improvement claim about hypothetical replacements. I see a lot of "we need to rewrite things" comments but not a single case being made with a clear tradeoff being presented. Every single criticism of TCP/IP in this thread sounds like change for the sake of change, and changes that aren't even presented with tangible improvements in mind or a clear performance gain.

Wouldn't that explain why TCP is so prevalent, and no one in their right mind thinks of replacing it?

> Yes!!! I have been saying for years that lower level protocols are a bad joke at this point, but nobody in the industry wants to invest in making things better. There are so many improvements we could be making, but corporations don't see any "immediate shareholder value", so they sit around happy as pigs in shit with the status quo.

If this was true then how do you explain that the likes of AWS, the same company who ended up investing in developing their own processor line, doesn't seem to agree that none of the pet peeves you mentioned are worth fixing?

> If it is the town square, Musk apparently wants to be the hobo that walks around shouting about conspiracy theories.

That is certainly a way to generate attention and traffic in the site he sank half his money in.

> I'm not making those assumptions.

Except you are. Your attempt to refute the fact that the Netherlands has not hit any limit is to make baseless claims that "it has more land suitable for residential housing".

> Elon Musk's link:

That site is renowned for publishing bullshit made-up articles such as how Hillary was dead and replaced with a body double.

https://www.nytimes.com/2022/10/30/business/musk-tweets-hill...

Please refrain from spreading it any further.

> The Netherlands has a lot more land suitable for residential housing and a lot less density. If this is hitting "the limit", then they're not doing it right.

Why do you presume that all land suitable for residential housing should be destroyed by residential housing? There are far more types of uses than that.

There is far more to life than having a place to work and to sleep.

> It definitly is, because despite being mostly C#, outside the graphics engine itself, they have decided it is the right tool for some of their projects.

No, it was not a reasonable remark. Pointing someone else's choice changes nothing. The point that you keep missing is that performance is a key decision factor, one among many, and baseline performance penalties imposed by a particular choice of programing is a factor that adds up to all other choices. If you degrade the performance of your offering without any relevant tradeoff, you're making it harder to justify it's adoption.

Feel free to insist in your personal assertion. Those who care about performance feel strongly about gratuitously pile performance penalties without any meaningful tradeoff to show.

> You were complaining about 1% performance deltas else-thread (...)

You should revisit that corner of the thread to revive your memory. The discussion was about adding an extra 1% performance penalty for reasons, not the importance of a 1% delta either way.

> And yet even the likes of Sony and Nintendo are working in major titles with Unity.

I don't think this is a reasonable remark.

The whole point is that the 1% penalty is added on top of whatever choices "the likes of Sony and Nintendo" make. If they have alternatives that ensure them a performance win just by chosing the right tool to work with Unity, they won't choose the wrong one.

> He really hates the bots, so he'll probably close up the API.

How relevant is the API though?

Is it possible to put together a Selenium script that posts a tweet?

> A second data point is: other languages improved enough, Java is just another one among many.

To me, C# not only caught up with Java, but also overtook it and left it miles behind. Developing services with .NET Core is an absolute pleasure, and feels so effortless.

Beyond tradition and legacy code, what does Java have to offer?

This should be the top comment. The last commit to the repo was posted 5 years ago, and all development seemed to have stopped on 2018

> I don't think Gankra is confusing them as much as asserting that a full specification should almost never be required reading for a user of a language (...)

My point is that this line of argument makes no sense.

It's like claiming that dictionaries and English grammar books are not needed because kids learning their ABCs almost never require reading those to learn how to speak English.

Rust standardization opponents insist in these moot strawmen arguments. They completely miss the whole point of a standard. Standards are critical because how things work need to be specified in precise terms that are set in stone. Standards are read to gain deeper understanding of a language. They are used to clarify corner cases and obscure issues and behavior. You do not need a ISO standard because you want to write a "hello world". You need an ISO standard because you are a mature professional that understands that "it works on my machine" is not an acceptable answer to any question you have on how a programming language supposedly works.

> Linux doesn't even obey ISO C's Memory Model.

Red herring. If I recall correctly, Linus publicly stated a number of times that C's memory model is relevant for userspace code but OS development has its own requirements.

Amusingly enough, I recall that this discussion was about Rust, and the way that Rust proponents advocated pushing Rust's memory model onto Linux.

> C did not become successful because of its specification, it got a specification because it was successful.

I disagree. The need for a standard specification of what the C programming language is sprung from the need to ensure that multiple independent compiler implementations were actually compatible and supported the same sets of features.

If a nonstandard C ecosystem had to endure the pain of either targeting products from specific vendors or waste time maintaining a caniuse database of C features, the amount of wasted effort to just keep code building would make things too challenging and troublesome to maintain. Consequently, we would see gradual fragmentation both within the C-like ecosystem and in other potential C-like successors that ink offered minor changes.

> As far as I know, they keep running with the last supported version of macOS.

During the past 3 years I was forced to upgrade from Mojave to Big Sur to Monterrey, each and every single time because otherwise my 2019 MacBook pro would not be allowed in the network as it was running unsupported OSes.

No, they do not keep running with the last supported version. Having a successful boot sequence and seeing blinking lights is not the end goal of spending over $2k on a luxury computer.

> Ask parser writers, I guess?

I've written many parsers, including for s-expr following rivest's RFC. S-expr take about half a dozen states to pull. A packrat parser for s-expr can fit in a single page. You don't even have to scroll to see the whole implementation. What are you talking about?

What exactly do you feel parser writers will tell you regarding s-expr?

> Rust's documentation is taken very seriously and often praised! But we focus on documenting actual APIs (with examples that we actually run in CI to make sure they don't break!) (and links to the actual implementation to dig deeper!).

Your confusing two radically different types of documentation.

Specifications, such as the ISO standards for C and C++, are the source of truth of what determines what the language actually is.

Writing tutorials with example code ran in some implementation might help people onboard onto it but it does not, in any way, shape, or form, specify what's the language.

It's like comparing blueprints of a construction site with random videos and photos of the same building.

> Something I find interesting about this discussion is that Rust seems to be held to a significantly higher standard than any other language developed in the last 30 years.

It's not. Rust lags way behind the standards help for decades by languages which the Rust community repeatedly claims Rust is supposed to replace. Rust has in no way, shape or form anything resembling an effort to specify it's core language and standard library in an international standard. Standards are critical because they are objective, clear, and well thought through specifications of how the language works now and anywhere, including and specially clean room implementations.

> I don't think I've ever seen someone lament that Swift or Go or Typescript or Dart or $ANY_LANG don't have an ISO spec.

Most of the top programming languages already are specified in international standards. Including JavaScript.

https://en.wikipedia.org/wiki/Category:Programming_languages...

Also, all of your examples, arguably with the exception of Go, are still in very early and unstable development stages, with projects repeatedly introducing breaking changes. If even the language designers don't make up their minds over what goes into it then we can't really talk about stability.

> To see how it's syntactically simpler than S-exps (...)

Has anyone ever complained that S-expr were too complex? Adding white noise as a tradeoff doesn't seem like a win.

> It reduces legacy cruft.

What you chose to describe as "legacy cruft" is actually the luxury laptop people spent over $2K close 6 or 7 years ago.

> The alternative is you get to keep 20-30 year old legacy cruft, as with Windows.

It's not a choice between bricking perfectly good computers after 6 years or maintaining them for 30 years.