Hacker News Reader

Counterpoint - slowing down the rate of change of a properly designed language makes it stronger. Having a vast amount of bolted-on cruft with inconsistent design principles makes a language pretty horrible. Example C++.

It's a fun exercise to think about how you would do C++ fresh starting with ansi C, given what you know now based on the actual experiences of C++, Java, D, Rust etc. C++ has had a tendency to attempt to solve the current problem while being tightly coupled to it, problems which may not even exist later. I submit STL allocators as an example of this.

What's the best way of enforcing taste? Slow down the changes, put barriers in the way? That's horrible, sure, but is there something better? Benign Dictator maybe? Bjarne's taste has improved considerably (and I'm sure I could have made a bigger hash of it than he did starting out too).

> Counterpoint - slowing down the rate of change of a properly designed language makes it stronger. Having a vast amount of bolted-on cruft with inconsistent design principles makes a language pretty horrible. Example C++

Isn't C++ an example of a language that moves slowly and still has lots of bolted on features? Having used it a bit, I would use Rust as an example of a language whose features are very thoughtfully considered and not "bolted on" at all.

If we're just looking at C++ and Rust and drawing conclusions, I would expect the conclusion would be "moving super slowly correlates with more bolted on features, not fewer".

C++ is an example of a language whose features were very thoughtfully considered and not bolted on at all when it was as young and untried as Rust is now.

By C++98 the language was already a hot mess, only 13 years after the language debuted. It's been 10 years since Rust first appeared, and its featureset shows no signs of cruft, nor does its trajectory indicate that it's going to acquire a lot of cruft in the next 3 years.

I think it's more likely that Rust just benefited from lots of hindsight with respect to C++'s mistakes.

Note also that since C++11, the language has been evolving quite quickly and the features released since have been some of the most thoughtful.

Either C++98 is 16 years after it debuted, or it has only been 6 years since Rust appeared. You can't tweak both these timelines in opposite directions and claim to be comparing anything.

By 1985 C++ has a published book describing the language (which I still own somewhere, it's terrible) and a commercial implementation as well as Stroustrup's code.

While in June 2011 Rust isn't even "pre-alpha" and is just learning how to bootstrap.

Wikipedia says C++ and Rust first appeared in ‘85 and ‘10 respectively. Therefore C++98 is a 13 year old version of C++ and Rust today is about 10 years old. It’s entirely possible that Wikipedia uses “first appeared” to mean different things in either article, but I’m assuming (rightly or wrongly) that they aren’t doing that.

The inception of C++ programming language began in 1979 when Bjarne Stroustrup was working in his Ph.D. thesis.

https://www.stroustrup.com/hopl2.pdf

Yes. Let's see how much cruft Rust has in 10-15 years as usage accelerates?

For example Rust's GPU support is not great right now - and it may very well feel bolted on a few years down the line.

> whose features are very thoughtfully considered and not "bolted on" at all

Rust has it's dangerous, unsafe warts. As someone learning rust, finding out that string slices can cause panics was utterly shocking to me. string slices should have had character indices not byte indices. This was a feature that was NOT thought of carefully. It completely goes against Rust's philosophy as a "safe", catch-errors-at-compile language.

C++ is the poster child of cruft and slow moving development, so it doesn't seem that these properties are correlated.

Yeah at first blush. Then you look at when C++ was new and being standardized it was moving pretty damn fast compared to anything else. They had a whole catchphrase "Remember the Vasa!" In an attempt to justify curbing enthusiasm for at least some of the many and disperate proposals.

Now, despite the big changes of C++11 as the watershed it has slowed and is doing better for it. Correlated? Maybe. Good taste should also slow the rate of change of "What do I have to deal with as a programmer in this language?" Also if the original language design that people found good enough to use was done really well then it shouldn't need too much change on top of it?

Point taken, you can use C++ as an example for anything. Even opposing points. It really has it all! (Like it or not)

Compared to C, C++ isn't that slow moving.

Not many languages take C's ultra-high-inertia approach. Perhaps Scheme and Forth.

Ada, 4 standards in 4 decades (1983, 1987, 1995, 2012).

Most people using it will probably also claim it is a feature rather than a handicap.

Reminder that Ada already had modules (Packages) almost a decade ago.

The frequency of the updates are only part of the story though. C had C89, C99, C11, C17. C++ had C++98, C++03, C++11, C++14, C++17, C++20. C++ is updated more often, but it also makes more significant changes in each version than C does.

I don't know Ada as well as I know C and C++, but I believe Ada lands somewhere between C and C++ in terms of how fast-moving it is. Makes sense that Ada is pretty slow moving, given its purpose.

> slow-moving development

> too much feature churn

Pick one, please.

High-latency but high-bandwidth. C++ features take forever to land, but there's always something big in the pipeline, for better or worse.

The OP said "cruft" not "too much feature churn". Very different things.

Can you point to the comment you quoted the "too much feature churn" from?

you can have both if you hire more developers on the project.

C++ moves at lightspeed compared to Fortran, which might get some kind of templates around 2030.

C++20 added modules to the language more than 3 decades after Fortran had it already in the language.

Rust has the best approach. Stable and unstable branches, so that language changes can be trialed on real projects and modified or backed out as required.

Getting more eyeballs on a language change and getting language users involved in its development leads to more strength than simply spending more time on each change.

> Having a vast amount of bolted-on cruft with inconsistent design principles makes a language pretty horrible.

From what I can tell the vast majority of changes to Rust are small things like "Adding a method to Vec". These aren't really the type of things that turn into cruft/ radically change the language, but we also don't have to wait years for them.

Editions, like for Rust, seems to be a solution. If you add a feature because it's really popular at some point but then decide to remove it, you can. This allows for removing legacy cruft after some time, so newcommers and new codebases don't have to care about it. And it's codified and enforced by the compiler, not "here's a list of what you can use". On the other hand, it creates churn. But you can't have evolution, no cruft and no churn. It's a "pick two out of 3" situation.

Editions can fix syntax level flaws, but many semantic flaws or flaws in the standard library can't be fixed like that.

Why not?

Editions can only change the very front-end of the compiler, and the standard library must be able to be used in all editions, so it’s not really possible to change on a per-edition basis. There’s only one copy of it globally unlike other Rust packages.

Got it - thanks, I'd never really considered that.

Hum... I do think the amount of bolted-in features correlates basically to age and unwillignes to fix past mistakes. It also seems to depend a lot on the strength of the initial stable idea.

The speed of change before it stabilizes has a strong inverse correlation with the number of features that don't fit well, and after it stabilizes I don't see much of a correlation overall.

I'm pretty sure C++ advances much faster now than Rust will in 30 years.

Then again, you'll just point to how awesome it is that Rust doesn't change and stays stable and easy to use for years.

It's all just rationalizations for the emotional investments you've already made.

As someone who's literally never written a single line of Rust and has shipped lots of C and C++, this is a nonsense argument. So what if C++'s model has "worked" for 36 years? It survives through momentum, it really doesn't matter how well the model works because it's hard to replace. Same with C. There are virtues to both languages and their standards processes, but big players wouldn't be pushing towards adopting Rust if the C and C++ models actually were up to the needs and standards of software in 2021.

C++'s standards process and pace haven't stopped the stdlib from being filled with bad implementations of primitives that people have to replace with libraries like Boost or custom per-vendor implementations - why do you think so many companies (game studios, facebook, etc) ship their own versions of the C++ STL, or prohibit the use of the STL entirely? Why do so many libraries ship with a C++ wrapper over a C public interface instead of the opposite? Why do binary-only libraries written in C++ so often ship with unique builds for various compilers instead of a single binary like a C library? The main answer to all of these questions is that C++ is deficient by design in all sorts of ways - underspecified ABI, low-quality stdlib specs, bad encapsulation, bad performance characteristics, etc.

I think a lot of it is that modern languages (python to some extent, rust Julia etc) implimented many more of their features themselves. Julia, for example, has some basic stuff defined in C, but 70% of the code is just Julia. Since most of the changes between releases are in the language, they don't introduce new syntax or make the language feel messier. They just slightly expand what the language can do easily.

Scarecrow. I’m far from emotionally invested in rust and I’ve dealt with the downvote army of zealots who want to rewrite everything in rust. I’m not the evangelist you think I am.

C++ is just losing here.

Agreed (and I'm dealing with an army of Rust zealots right now on proggit). Rust has a track record of carefully considered features and a process that allows it to continue making changes to the language while managing compatibility. I do expect Rust will slow down and bureaucracy will slip in in the next 30 years (because I fully believe Rust will become very popular and many big companies will come to depend on it for security and critical real time systems), but I don't think it will move as slowly as C++ does these days.

Is “scarecrow” the same thing as “strawman”?

A scarecrow is a straw-man. :)

Strawman is less offensive.

Wait, “scarecrow” is offensive now? How?

If it only had a brain?

Yeah, and in 30 years I won't use either because I am a fickle man and do not marry my programming languages. I will be using Bouillabaisse - the fastest moving language this side of the Seine. I'm sure someone on Hacker News will tell me that Bouillabaisse won't be as fast moving 30 years from then but at that point I'll be using Caracole - the fastest moving language this side of the Kuiper Belt.

This long lifecycle is a double-edged sword between stability & features, but you can grind down one of those edges with enough discipline on backwards compatibility.

One compelling example could be the direction MS has started to take w/ .NET Core/5/6+:

- Submit issue/PR on the dotnet/aspnetcore repo on GH (anyone can do this).

- Conversation starts almost immediately.

- Suggested changes could be merged in a matter of weeks.

- Expect your changes to become available in an official release in under a year. Pre-release builds much sooner than that.

- Expect an LTS release the following year.

I have personally experienced this workflow a few times. It is incredible to have this type of feedback loop with something that has historically been a total black box of proprietary decisions.

There are still a ton of places where you don't have much leverage, but the fact that there is any movement possible from the community at all is incredible to me (again, from a historical perspective around Microsoft & .NET).

I don't have to learn how to draft a PhD thesis in order to add value to the ecosystem. Ideas should not be filtered so harshly in my opinion.

This kind of aggressive evangelism is hurting Rusts reputation a lot. I wish people would just stop it. Why do some Rust fanboys have to keep shitting on every other language all the time???????

Something new is likely to try to correct perceived mistakes in something old. It shouldn't be taken as aggressive to try to say that one approach is better than another tbh.

And God help you if you point out strange warts and syntactic choices in Rust. You will be eviscerated.

The part that's not mentioned, and a reason why some people wonder why their approach didn't get traction is missing. Before starting any of these steps you need your own analysis of what will make your change successful. You'll probably only be able to make the best analysis if you socialize your idea with relevant people in the community in private.

This seems really obvious, but it's a pattern that repeats with engineers engaging in what is only partially an engineering effort. Similar issues occur in the python-ideas list other places. When you follow this approach you can remove the risk of premature investment in the steps listed.

On the other hand, this glacial pace had it's upsides as well

I think having an implementation isn't needed. However having an implementation proves that the idea is feasible and simplified verifying it.

Also you don't have to be in the meeting in person, however a paper without author or somebody else who can argue for it will have a hard time to get the attention considering the number of papers in the queue.

If rust ever reaches the ubiquity that C++ has, it will have same barrier to change that C++ has.

Will it? Rust has editions which C++ does not have which seems like a potentially significant mitigation.

How are "editions" any different from C++ standards versions?

You can use new features from new Rust versions/compilers on old editions, as long as the new features don't require backwards incompatible changes. You can't use features from new C++ standards when targeting an older standard.

You can, they just often live in somewhere like std::experimental

Standard revisions are like snapshots in time. Editions are a way of introducing surface-level changes into the language, which are guaranteed to interoperate. Most features land in as many editions as possible simultaneously, the edition differences are purely the things that would be breaking changes, and so require you to opt into which ones you want.

Both strategies have advantages and disadvantages.

Editions are opt-in at a per-package level. You can write Rust 2015 code that wouldn't be valid Rust 2018 because of breaking changes, while using libraries that use Rust 2018.

Linking different C++ releases together is kinda possible in C++ too: https://stackoverflow.com/a/49119902

    For GCC it is safe to link together any combination of objects A, B, and C. If they are all built with the same version then they are ABI compatible, the standard version (i.e. the -std option) doesn't make any difference.

Ignore the part of the link where it talks about gotchas with linking together binaries made by different compiler versions because in Rust this case isn't supported at all.

Right, I knew I should have said "without shenanigans".

The difference is that editions are a first-class, supported mechanism for managing interoperability between code targeting different "standards versions". It's not up to the user and the linker to conspire so that things work out, it's part of the language, and you don't need to limit your public interfaces / generic code to the lowest version.

(I don't know if this is the best policy? It seems like it could be a big burden on implementations in the long run.)

Without a formal recognition of this (ie: editions) you can have horrible silent ABI breakage in C++. See this Jason Turner video: https://youtu.be/By7b19YIv8Q

> allowing for breaking changes

Cute for toy projects but a big disadvantage for any another kind of programming. There's a reason established languages like C++ or C# are taking compatibility very seriously.

And it's probably the same reason Rust takes compatibility very seriously. What's with the "us vs them" attitude?

I think that was bad phrasing on GP's part. Rust only allows breaking changes for edition changes, which are opt-in. Libraries in older (or newer) editions can still be used together in your project, no matter which edition you are using. Rust allows for breaking changes in a way that doesn't actually break anything.