Hacker News Reader

Comment by arcticbull | Hacker News Reader

> But why can’t I just quit then? What’s the matter? The matter is, none of the languages, especially the so-called “C++ killers” give any real advantage over C++ in the modern world. All those new languages are mostly focused on holding a programmer on a leash for their own good.

This, very specifically, is the advantage these languages have over C++.

The benefit isn't the universe of things you can do (they're all Turing complete, you can do anything) - it's what the language stops you from doing. This is the thing the C++ committee never understood or at the very least never appreciated.

View on HN

In other words, the “feature” those languages have is reducing the cognitive complexity and more tightly bounding the risk.

Newer languages are adding friction or dropping altogether things that you rarely or never want to do, to more tightly constrain the space of possible actions to the set of desired actions.

so experienced cc devs dont need it and the dream is mostly about creating experienced devs who write fast software damage limited by the guardrails of the environment? so its basically the c#\java world of cheap oo software crawling over moores plateau hopping for one more silver bullet that will fix lowcost development,trying to solve the expensive quality dev shortage once more by cheapening out.

Worst take you could have had on this.

Experienced c devs are people too.

People make mistakes.

We can make tools which reduce the frequency of certain classes of mistakes (c++ has a few of them now as well)

Those are pretty cool tools.

At least in aerospace we use C++ because we need a bare metal language and C++ is the most full featured/widely used one. Rust is great but toolchain support just isn’t there yet and ADA/Spark aren’t widely used anymore for new development.

If Austin Powers was a programmer:

On a leash? What? ... [if only I could work in a] consequence-free environment, I'll be sound as a pound!

why do you think the designers of those new languages know what is good for you?

Because they tell me to stop managing memory by hand, as we have mountains of experiment proof that no one[0] is good at it.

[0] I meant what I said.

um, modern c++ has for at least the past 10 years advised people not to manually manage memory.

not really, RAII/shared_ptrs is still manual memory management, just less footguns

well, i would not recommend shared_ptr except under rare circumstances, but i don't see what can be wrong with RAII. in fact, it is the languages thar don't have RAII that have the problems, IMHO.

its the same as the tools rust provides you, so if that's true it bodes poorly for the supposed c++ successor.

One thing I love about C++ is it (mostly) stops me making type errors, compared to dynamic languages - "compile and it works". Adding type constraints makes programming safer, easier, and results in better compilation.

You can add other constraints (e.g. temporal constraints) and get similar benefits, on top of the above.

It also means you only get one third of the stuff done. Nothing "compiles and it works". That just means you suck at finding bugs :p

Some dynamic languages do have type constraints these days, e.g. PHP.

Because I believe safety critical places like aviation are the ones that actually get things right. You can't pile on every demand on the human in charge and expect improvement. We're just not great at taking every possible detail into account. Doing lots of grunt work all the time reliably is what we have computers for.

In my old age, I find the more permissive a language is, the more painful it is to code in long term. Perl is great for simple things, but C++ was a vast improvement because it catches a lot of nonsense that Perl will compile just fine.

And debugging is so expensive that eventually writing code fast is near worthless. Whatever you gain you more than pay for in debugging afterwards.

C++ unfortunately doesn't go far enough.

yes - i switched from C to C++ a long, long time ago (late 1980s) because C++ was so much more strongly typed (i still don't understand why other C programmers have stuck with C). i'm less than convinced with the promises of rust (for e.g.), but have only written trivial programs in it.

Because simpler languages are inherently better than more complicated ones.

why? says who? assembler (about as simple as you can get) better than (for e.g.) C?

And even simpler is the iota combinator which is by itself turing complete. So a single letter plus matching parens is about the simplest language as you can get. But I can't imagine anyone wanting or even being able to program in it.

Assembler is a bad example for simplicity. Perhaps brainfuck fits better in this case.

Simpler aka Python, Ruby, Basic, Pascal, not "lower level".

i don't see those languages as being "simple". quick to program in, yes. but assembler is really pretty transparent, once you get into it. heck, i used to program in machine code (i don't recommend it) without too many problems.

"Simpler" isn't really a good adjective to classify languages. You have to be way more specific on what "simple" means. Are we talking characters needed to implement 'hello world?' Time to first memory access segfault? Number of pages in the specification (which, at this point, I'm not sure whether Python or C++ wins out...)? Lines of code in the compiler / interpreter?

Simpler languages often put more burden on the programmer.

There's a balance.

Well no, what do you think the word simpler means?

C is a simple language.

Rust is not a simple language.

Lisp is also a simple language.

Lua is simple as well (well… maybe not…)

JavaScript is not.

C++ is not.

C isn't a simple language, really, because it has a ton of implicit assumptions and inconsistencies, undefined behavior and all the failure modes you have to keep in your head at all times.

It's not that C is simpler, it's less expressive.

I don't think this answers parents question though, which is what does it mean for a language to be simpler? I think that's a good question. This is just a list of examples.

It almost seems like simple is a bad concept applied to languages because what's simple and complex is the idea you're trying to express, accurately, in its totality - not necessarily the language.

I think expressiveness is complexity.

The fewer ways there are to express an idea, the simpler the language is.

Simple languages do not imply simple software (look at lisp)

Good luck programming your next application using the lamda calculus or a Turing machine.

One could actually have both. Spiral provides a lot of its performance by correctly specifying error constraints, which is a form of safety. You could specify architectural constraints by hand too, for performance and portability. (With some good defaults.)

One could technically also get memory and reference safety this way. Which is the opposite of what Rust does for example, where it defaults to do a particular model of referencing memory and makes using any other painful.

It also does not have any constraints on timing or redundancy if necessary.

Automate some of this handling but still keep it explicit and you have a potential winner.

They don’t. What they do is create a system where the system protects itself from human error. They don’t know better than me: I agree with what they’re doing. Automatic enforcement of good things, plus an escape hatch for emergencies, is better than no restrictions ever.

I assume you program in assembly language, then? Can’t trust those structured programming types to know best how to manage your instruction pointer after all. “Functions”, “loops”, “conditionals”, all just fancy words for straitjackets.

I’d love a demographic study of folks who are really unhappy about languages like Rust and Go specifically because they believe they’re crushing their creative spirit. The “I need MAXIMAL EXPRESSIVENESS at all times! Don’t tell me how to do things!” sort

I hesitate to even guess what the findings would look like, but I bet it’d be interesting.

I agree the results would fascinating. The perception from the other side is that rustaceans crave to be bound in the constrictive swaddling of authoritarianism. Which seems to be born out in both the language itself and the foundation.

“the constrictive swaddling of authoritarianism” is a wild way to describe static analysis.

I'm pretty much static guarantees to the bone. But I sort of get where the dynamic camp is coming from. With something like python, you need to understand lists, dictionaries, loops, and the call stack. And then you're off to the races.

Meanwhile with ocaml you need to understand type theory, type inference, algebraic data types, the module system, maybe row poly, (insert a bunch of other things), and now also algebraic effects. And there's no guarantee that the well formed logic of your domain problem is compatible with the type theory your language is using (although, adt + generics almost always does the job if you take a minute).

That being said, the way that's being expressed here does leave something to be desired. Like, if someone doesn't jive well with static techniques that's one thing. But I've never really understood decrying people who get it as suffering from some sort of Stockholm syndrome.

I agree that there is a productive discussion to be had about all of these things, including their limits, for sure. Just that this way (my original parent, not you) isn’t it.

Yep, I think we've got the same position.

Even though I don't agree with the dynamic camp, I like advocating for it because I think there are scenarios where there is something there.

However, the position that the static camp is somehow against freedom and morally wrong is pretty weird to me.

I mean, I don’t need maximum expressiveness, but imo languages with nearly over engineered type systems like rust, to me, lack almost any expressiveness without having to get into macros.

But when programming in assembly you're still beholden to the CPU designers in regards to out of order execution and branch prediction and all those fancy layers taking runtime control away from you. Better to just print your own silicon.

Language implementers ought to know better than me (the user) about programming language semantics, in this case specifically things like memory safety.

Memory safety is a very small fraction of the problems a computer program can have, and replacing them by an immediate shutdown is hardly a very useful improvement on program quality.

> Memory safety is a very small fraction of the problems a computer program can have

And a large fraction of the problems that lead to security situations. Worse, they are often so subtle that they stay in a codebase for decades.

> and replacing them by an immediate shutdown is hardly a very useful improvement on program quality.

That's a pretty absolutist statement about something that's very context dependent.

"Software quality", in my mind, includes "nobody can send me a crafted text message that gives them remote root access on my phone."

Yes, there are security issues beyond memory safety bugs. But these are the issues that are most regularly turned into the most serious exploits and they are hellishly common.

All systems security is about layered defenses. "Oh, log4j exists" is not a compelling reason to avoid changes that can mitigate very large portions of security risk.

There are places where you'll truly never encounter untrusted input and a crash is just as bad as blasting off and performing whatever unexpected computation, but that's nowhere near the entire existing C++ landscape.

Design by contract improves software quality instead of lowering it.

And it explicitly introduces undefined behaviour aka "memory safety bugs".

Design by contract? That technique which “shuts down your program”/panics on assertion failure? You seem to contradict yourself.

This is a bit of a misnomer, languages don't generally stop you from doing things. They just make really damn sure that you aren't doing it by accident.

what do you think those new languages prevent you from doing?

Is a bounds check on every container access good for me? Not always. Sometimes my code is correct. But security vulnerabilities are observably a huge problem. And you only need one vuln in iMessage or whatever to get a dissident journalist's phone hacked and then get them murdered by the Saudi government. Is "I know what I'm doing, I promise" good enough for you in that case?

I find it interesting because until about three years ago, C++ was always on the other side of this argument. We fight about static type systems. You could shout at the compiler that you know that your code is correct even though the type system doesn't pass. Why does the committee think it knows better than me! Everything is just bits after all!

Now we are on the other side. C++ people saying "bro I totally promise I'll initialize this data member before it is used, stop making me initialize it in my constructor"

> Now we are on the other side. C++ people saying "bro I totally promise I'll initialize this data member before it is used, stop making me initialize it in my constructor"

C++ has never said this - if a type has a constructor, that constructor will always be used in a data member (or elsewhere).

???

You can absolutely write a type like this.

    class Foo {
     public:
      Foo() {}  // never initialized x
      int x; 
    }

And then using it like this

    Foo f;
    bar(foo.x);  // oops

"But my types are well designed" is the usual response to "why the heck does the language allow you to quietly expose yourself to UB in this way?"

zabzonk said "if a type has a constructor", but I don't think the int type does, which is why you get uninitialized memory here.

Any instance of Foo will run Foo's constructor because Foo has one. The problem is that that instance of Foo won't definitely have x initialized, because int doesn't.

Sure. If for some reason you only care about this with regards to struct types that have constructors that correctly initialize all of their members then you are good by default (sort of, there are weird edge cases here with globals). But "safe for this, not for that" is not especially compelling to me when it is hard to imagine a C++ codebase that doesn't use primitives/pod types somewhere.

Plus, there are stl types that don't guarantee initialization of members. So it isn't like only ever resting on top of stl types is sufficient. std::optional has a non-default constructor but it can happily blow up because of a read of uninitialized data.

And the fact that this is the silent default behavior in C++ is wild to me. Even in languages where it is possible to leave data in an uninitialized state, you should need to loudly signal it.

> And the fact that this is the silent default behavior in C++ is wild to me.

I agree, totally. Backwards compatibility is a cruel mistress.

i said "if a type has a constructor". but if you are fiddling around with ints and chars and the like, then you will need to initialise them. i have been writing c++ since the mid80s and have never found this to be a problem, or at least no more than it would be to use an uninitialised int variable in C.

The fact this is even a distinction anyone has to keep in mind is again an example of the problem. People are awful at remembering these weird little details. We shouldn't expect people do things they're bad at, all the time, and to get them right. And I'll go a step further and say we shouldn't let them by default. They should have to make it super explicit they want to opt into the weird behavior nobody expects.

You can do this in Rust if you want! You just have to use unsafe { mem::uninitialized() } or even better, the newer unsafe { mem::MaybeUninit::uninit() }

The whole point is that you probably don't ever want to have an uninitialized variable you can access willy-nilly, and if you do, you should be very explicit.

Even your statement about C (and C++) isn't quite accurate, right, because anything static is guaranteed to be initialized to zero on creation. So while `int x` is a free for all, `static int x` is gonna be zero. Another thing people shouldn't have to think about!

Principle of least surprise.

i don't actually use ints much in my c++ code. iterators for looping over things. using ints for accumulating is a problem in most languages.

I agree. I wish we had to say `int x = std::uninitialized;`

"In some cases you are safe in other cases you aren't" is not good enough for real safety.

Congrats if you never write bugs. For the rest of us, we will use the widely available data that demonstrates that these bugs recur over and over and over and over even in organizations with strong developers, strong testing culture, and where the use of static analyzers and fuzzing is widespread.

Yes, C also has these problems. Both C and C++ represent significant safety risks, despite powering some of our absolute most security critical applications (the linux kernel and our web browsers). Other languages don't give you these footguns.

This is such a silly send-up. They don't know what's good for me. They tell me what their language is good for. I decide if what the language is good for is good for me.

This is the key insight. I think that the reason why we have so many c++ replacement languages is because c++ is okayish for basically anything. Replacing it completely will necessitate several different languages that are good for different applications.

Okayish was fine or even necessary in the past but the industry has matured to the point where we need more purpose built tools for more specific projects.

Rust is going to be necessary but also zig, hylo, vale, p, Odin, and jai (assuming we ever get a release date). A language able to do everything that c++ can is almost definitely only able to do it all okayish.

How could they know that?

They might know how to design a language such that it tends to produce exceptionally readable codebases, good performance, and improved safety, though. Maybe not all three at once, but some mix of those that’s better than existing languages, perhaps.

The same reason we all use structured programming instead of goto.

Reply on news.ycombinator.com