Hacker News Reader

Rust actually can do things C++ can't do. People who use Turing equivalence to equate language capability are just uneducated imo.

There's another "truth" of PLs: Curry-Howard. So a language with a richer type system can express more propositions than a lesser one. Just because two languages are Turing equivalent doesn't mean they are Curry-Howard-equivalent.

So the things some languages can do that others can't happen at compile time.

And tbh, you'd probably be better served by a language that isn't Turing complete but allows you to express rich types than a Turing complete language with a bad type system. Very little of people's code needs Turing completeness.

Can any code written in rust be transpiled to c++ without losing something?

If "something" includes safety and maintainability, then no.

Maintainability doesn't matter in this case. I would assume all the safety features of rust could be implemented in the transpiled code.

If maintainability doesn’t matter, what are we even talking about though? If a solution is maintainable in Rust and an utter nightmare in C++, the answer to the question is “nope” for all practical purposes.

No. There is no version of the env! or include_str! macro! in C++ (they are implemented in the compiler for Rust). These macros can be used to the get the values of environment variables or the contents of arbitrary files at compile time. You could of course implement them within a build system, but there isn't a way to replicate these macros with just pure C++ being passed to a compiler, even with pre-processor macros.

File embedding seems to have been a low priority for the standard, perhaps because there's always been workarounds, but it has gotten some attention recently with the std::embed proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p104...

> Very little of people's code needs Turing completeness

The Wikipedia page on Total Functional Programming [1] has a nice (even if contrived) example of this with Quicksort. I feel like my undergrad complexity class did me a disservice by emphasizing Turing Completeness so much without discussing any other aspects of abstract computation, like lambda calculus, type systems, etc..

[1]: https://en.wikipedia.org/wiki/Total_functional_programming

> Rust actually can do things C++ can't do. People who use Turing equivalence to equate language capability are just uneducated imo.

This is a very myopic view, and misses the point entirely. The entire notion of a "Turing machine" is that any Turing-complete machine can compute any result that another Turing-complete machine can compute. No mention is made of how the results are computed or how the programmer approaches the problem on each machine.

Any Turing Complete language can be used to do the same work as any other Turing complete language or mechanism.

The expressiveness of any particular language does not factor into the equation at all, and does not matter at all when speaking of what is computable and what is not.

You are talking about language features, which is an entirely different topic. All Turing-complete languages are equivalent in terms of their abilities; that is to say that they can all compute the entire set of computable results.

Right I'm saying there are other theory-grounded ways of discussing language capability beyond Turing completeness.

> > “I think C++ can do anything Rust can do, and I would like it to be much simpler to use.”

> I think Bjarne isn't getting the issue with C++.

In my opinion, put succinctly, the issue with C++ is that it can do things that Rust can't. And, as it turns out, most of the things that it can do over Rust aren't important for solving problems (one of those things is explicit memory management).

> Rust people [...] accuse [...] stolen

There is something that many developers struggle with, and it seems to be cropping up here. You are not your work, folks. Go back and honestly look at your very old code, it's probably not good, it's probably not good at all. There's no reason to be ashamed of that, because your work is not your identity.

If your work becomes your identity, you lose the ability to critique your own work objectively (biologically/psychologically), which really impedes your ability to improve your work.

But do you agree that Rust stole many things from C++?

Because that was his point, the whole argument about developers identifying with their work seems to sidetrack the original discussion.

Of course Rust "stole" many things, there wouldn't be much of a language if it didn't. C++ is a crucial piece of history in the evolution of programming languages.

> the whole argument about developers identifying

Taking inspiration from C++ is inseparable from developing a language today. Arguing about who "stole" ideas is sidetracking the overall discussion, in the first place. The development of C++ is being hampered by the perception of a threat/enemy who "steals" ideas - which is a very human and normal way to act. If the discussion is "them/Rust" vs. "us/C++", then the reasoning behind that counterproductive mindset is worth talking about.

It's certainly possible to see it this way. However, I'd like to argue that there is a certain kind of value to what you consider a problem as well. Quoting Bjarne from the article:

> “But besides adding object orientation to C, he also remembered his earliest design goals for C++. “I wanted very great freedom of expression, very great generality. [...]”

I can only speak from my own experience here, so it's anecdotal, but the main reason I love using C++ is precisely this "great freedom of expression", which is most likely, but at least in part, a direct consequence of the fact that it "tries to be everything to everyone". When writing C++, my mind often wanders and comes up with code and designs that would either be actively discouraged in the majority of other (opinionated) programming languages, or straight up impossible to implement. It's a great and highly valuable (possibly creative) experience that I haven't, to this extent, experienced in any of the other (numerous) languages I've been using. I also feel it makes me a better software engineer as a whole, even when I'm not working with C++ (which is actually most of the time). Beyond that, I also feel it's one of the reasons why C++ is so successful.

Obviously it also leads to the fragmentation you described, and it's perfectly valid to criticize, but I wish people would, more often, at least acknowledge that this kind of programming language is still valuable in certain ways and situations.

Yes, if you are mainly focused on getting a job done with minimum friction (and maybe maximum speed), there is a high chance that there is a language better suited for the task than C++ in today's age. That does not make C++ obsolete, quite the opposite in my opinion. I believe the fact that C++ isn't as opinionated or streamlined as other languages shouldn't be considered an "issue" or a "problem", but a feature.

That great freedom in expression is probably what leads to many bugs from expressing things "too freely".

Generic wise phrase: Perfection is not reached by adding more and more things, but by taking things away, until only the true core ideas remain, on top of which one builds the rest.

This is something C++ is very far away from attaining. What one wants for maintainabIlity, simplicity and understandability is the core concepts, not 120 keywords and different meanings of keywords depending on where they appear.

> "That great freedom in expression is probably what leads to many bugs from expressing things "too freely".

I agree.

I'm not sure why C++ needs to attain perfection of this specific kind - or any kind, for that matter. You could also argue that the great freedom and flexiblity were preconditions for (or at least greatly aided in) the creation of languages like Rust. Through them, people learned what to be aware of; and were thus capable of "distilling" this knowledge into such languages.

My point is: there is nothing inherently wrong with a language choosing to be liberal/maximum generality, allowing for a playground on which new ideas and learnings can happen. I consider C++ to be of that kind, it has served this purpose for a long time in my opinion.

Don't get me wrong though, I'm perfectly aware of all the issues that come with it, and I'd not advocate C++ as the language of choice for the majority of software nowadays. I reject the idea though that C++ should now be considered obsolete, redundant, or anything that goes into that direction just because some people now believe to have found some kind of (final) "perfection" in new languages.

And also, there was a time where he really loved templates (hell, all of us did).

But yes, you are completely right: teams developing ultra complex languages (e.g. C++, Scala, Ada) usually fail to understand that the fact their language can do everything all the other languages can do is exactly the problem.

The value of these other languages is precisely choosing not to have certain features.

> Bjarne points out how much he hates templates

I don't think he's saying he hates templates in general:

> “I’m not a great fan of template meta-programming"

He's not a great fan of template meta-programming which is a specific use (or abuse depending on your point of view) of templates. Though it is a fairly popular use of templates now.

He‘s not British but was several years at an English university.

If I interpret this sentence with English understatement, then indeed, he hates templates.

That just seems like a big stretch. No templates means no STL. The STL is a pretty big jewel in the C++ crown at this point. No templates and no STL means we'd have some kind of container libraries with long inheritance hierarchies kind of like what we had in the 90's prior to the introduction (and implementation in compilers) of templates.

The subtlety (also missed by the parent comment) is that he specified template metaprogramming, not templates in general. As I understand it, template metaprogramming refers to deeper uses of templates to do compile-time programming.

(I interpreted his British-rooted understatement in the same way as the parent comment.)

> Worse, many of the new language features can't be properly implemented because they would break someone else's C++.

And yet, I understand where the baggage comes from. My favorite language when I was young, Python, went through a decade of stagnation because programmers couldn't be hassled to write print('hello') instead of print 'hello'. It's frustrating, but almost all languages gather baggage over time.

This comment is probably tongue in cheek, but I think the slowness of Python 3 uptake was mostly caused by a perceived lack of beneficial features to the large HPC/scientific computing crowd. Breaking syntax changes (outside some very obscure things like trigraphs) is what C++ has been looking to avoid (for good/bad).

By “I think C++ can do anything Rust can do, and I would like it to be much simpler to use.” I think he’s saying that he knows there’s an issue with the complexity of C++. See his quote “Within C++, there is a much smaller and cleaner language struggling to get out” https://www.stroustrup.com/bs_faq.html#really-say-that

Features can’t really be removed from C++ because a major advantage of the language is compatibility with existing code. However, within that constraint, C++ is driving toward a simpler, cleaner, safer dialect. It’s a hard problem.

> The issue is that C++ can do everything that every other language can do, which means it's not a language

None of statement are true...

C++ cannot do everything. C++ can do most every other "system programming languages" do, but that's by design that they are all system programming languages.

Even if C++ can do everything as other languages, that does not make it beyond a language. C++'s system is coherent. It is complicated, but no where it contradicts itself in any major fashion.

How come the "current best practice" programming model changes with every language release?

This is the main complaint with friends of mine. They get up to date on C++ whatever. Then spend a couple of years writing code in another language. And when they come back to C++ it's now C++ whatever + n and they're like WAT is this language?

That generally does not happen with other languages.

Sure it does, drop someone using Pyton 2 into a Python 3 code base, Java 8/Android Java into Java 14, C# 5 into C# 8, and watch them struggle with the modern idioms and toolchain updates.

> Many of these C++'s are incompatible with each other.

> Worse, many of the new language features can't be properly implemented because they would break someone else's C++.

Could you give an example?

One would be, some are using the new-style enums (with the unhelpful syntax "enum class") while some are using the old-style enums.

I think you are describing an interface change, which is not surprising to break existing code. If you added or removed an item, you could also likely be breaking code.