241–250 of 251 posts
[flagged]
https://hn.algolia.com/?sort=byDate&type=comment&dateRange=a...
Perhaps you don't feel you owe article authors better, but you owe this community better if you're participating in it.
> So what is out there for me, if not C++ or Rust? Ada. I write C++ professionally and used Rust for about a year, but don't use it anymore. In many ways, Ada feels like a much simpler implementation of the C++ feature set. The language lets you focus on intent, while still having a lot of control. Yes, Ada's still alive and kicking, it has a package manager, documentation generator, parsing/semantic analysis library…
Does Ada compile for mobile platforms (Android/iOS/etc) ? Does Ada support lambdas ? (can't find this)
> Does Ada support lambdas ?
No, but you can declare functions inside functions and also use function pointers. When I started using Ada I thought this was a huge issue, but I haven't run into problems with it in practice.
Earlier quoted context omitted.
You are _way_ overstating your case. For those who are not familiar with C++, the past ~12 years have seen _massive_ changes to the language, the standard library and the surrounding ecosystem. Yes, old programs still run, but they are simply not what you would write today nor how you would write today. In fact, the C++20 changes are so significant that it will take years for developers to even transition to utilizin…
Without the ability to break ABI, the C++ standard library is dead. "The Day The Standard Library Died" https://cor3ntin.github.io/posts/abi/ C++ ABI is also a joke. You can neither take advantage of it nor avoid it. Why have an ABI then ?
I agree that the ABI should be broken. However, the standard library is not dead, for 2 reasons:
1. There could be switch to an std2 namespace for new versions of things, or of the whole library. And then std3 etc.
2. There _will_ be a switch to standard library via _modules_, and with that switch the ABI is changing anyway, so it could be used to make changes to existing ABI
... that being said, a lot of the standard library, while not dead, is kind of brain-dead, like std::map and std::unordered_map; or how you need the mountain of code that is ranges to be able to say `vec2 = transform(vec1, my_func)`, even though that was perfectly doable with C++11 at the latest, etc.
> Why have an ABI then ?
Because that way compiled code can work with other compiled code without them being compiled together? :-(
Earlier quoted context omitted.
You are _way_ overstating your case. For those who are not familiar with C++, the past ~12 years have seen _massive_ changes to the language, the standard library and the surrounding ecosystem. Yes, old programs still run, but they are simply not what you would write today nor how you would write today. In fact, the C++20 changes are so significant that it will take years for developers to even transition to utilizin…
Of course they're adding things to C++. They've been adding things to C++ for decades. I don't anticipate that slowing down for many years if ever. Watch Herb Sutter talking about the question of whether C++ is "finished" a few months back. Bjarne wants Unified Functional Call Syntax, which is the sort of crazy "automatic foot-shotgun" feature that C++ deserves and will fit right in†. Herb wants a pattern matching sy…
The point is not the _adding_, it's the effective _replacement_. It's like a toolkit with some lame tools. Even though you keep them in there for old time's sake, you add new tools which you use instead of the old ones. So, yes, your toolkit is heavier, but working with the updated toolkit is not like it was working with the old one.
> C++ is too complicated
Well, it is certainly complicated. Certainly more complicated than anyone would like, including the WG21 bigshots. But its (effective) design principles necessitate complexity:
1. Multi-paradigmaticity (sp?)
2. Backwards compatibility
it could drop one or both of those and be much simpler, like you suggest.
> The only way to actually fix that would be to face the monster and slim down C++
Except then it wouldn't be C++, but another language - which is fine. Another famous quote by Stroustrup is: "Within C++, there is a much smaller and cleaner language struggling to get out"
... but that language would not be Rust, it would be slimmer underpinnings of is idiomatic C++20 today. Or perhaps of what idiomatic C++26 would be :-P
> C++ isn't too unsafe it's just too easy to get things wrong
I disagree; or rather, these days, I disagree: This has, paradoxically, gotten much much better - because of all of those additions you decry. They have made it so that you can steer clear of unsafe and complex territory for a lot more things. You write more intuitive, safer code; and are better protected by the libraries you use and by improved tooling. It's true that the underpinnings of these libraries are now (usually) bigger and more complex, but the end result for the developer is the opposite.
---
PS - I would really love UFCS to get into the language, I think the opposition to it is kind of inane.
Earlier quoted context omitted.
Of course they're adding things to C++. They've been adding things to C++ for decades. I don't anticipate that slowing down for many years if ever. Watch Herb Sutter talking about the question of whether C++ is "finished" a few months back. Bjarne wants Unified Functional Call Syntax, which is the sort of crazy "automatic foot-shotgun" feature that C++ deserves and will fit right in†. Herb wants a pattern matching sy…
> Of course they're adding things to C++ The point is not the _adding_, it's the effective _replacement_. It's like a toolkit with some lame tools. Even though you keep them in there for old time's sake, you add new tools which you use instead of the old ones. So, yes, your toolkit is heavier, but working with the updated toolkit is not like it was working with the old one. > C++ is too complicated Well, it is certai…
UFCS fits perfectly with C++ culturally. In particular UFCS means when Library A provides a function that says it can twiddle a foozle, Library B that provides foozles and explicitly doesn't want you twiddling them can't stop anybody calling foozle.twiddle() and C++ says as a programmer the resulting mess lands in your lap.
> Except then it wouldn't be C++, but another language - which is fine.
Hogwash. It's C++ if they say it's C++.
When I first wrote some C++ I could write:
auto foo = something();
But, today if I write:
auto foo = something();
That was not another language, it was still C++ it was merely changed in an important way. In C++ 20 and particularly in the decision to not take Epochs, they decided C++ must never again be changed.
> They have made it so that you can steer clear of unsafe and complex territory for a lot more things.
No. Putting a little wooden fence along the crumbling edges of a fast mountain road and saying "Now it's safer" is almost worse than not bothering. It is concerning that this fools people.
Real safety looks quite different, consider my misfortunate::Maxwell type in Rust. The Rust traits this implements are definitively safe. If you try to store a bunch of Maxwells in a Hashset things won't go well for you since Maxwells aren't Equal (even to themselves) and yet they all Hash the same. But whereas in C++ such things get you Undefined Behaviour and all bets are off, in Rust we have safety and so the behaviour may be useless (e.g. infinite loop) but it is never Undefined. Our program is wrong but because it's safe we can successfully reason about why it doesn't work.
Earlier quoted context omitted.
We should cut people some slack about this, especially considering that the language itself is case insensitive :P I'm not sure what actually triggers the confusion about this, but it is Ada, not ADA. It's not an acronym, I'm curious about the origin of the incorrect all caps version, but it seems like there's a forgotten historical reason for this.
Ada came out of the DOD so assuming it's an all-caps acronym makes a lot of sense. ;)
Earlier quoted context omitted.
Does Ada compile for mobile platforms (Android/iOS/etc) ? Does Ada support lambdas ? (can't find this)
See https://blog.adacore.com/android-application-with-ada-and-we... > Does Ada support lambdas ? No, but you can declare functions inside functions and also use function pointers. When I started using Ada I thought this was a huge issue, but I haven't run into problems with it in practice.
Earlier quoted context omitted.
Without the ability to break ABI, the C++ standard library is dead. "The Day The Standard Library Died" https://cor3ntin.github.io/posts/abi/ C++ ABI is also a joke. You can neither take advantage of it nor avoid it. Why have an ABI then ?
> Without the ability to break ABI, the C++ standard library is dead. I agree that the ABI should be broken. However, the standard library is not dead, for 2 reasons: 1. There could be switch to an std2 namespace for new versions of things, or of the whole library. And then std3 etc. 2. There _will_ be a switch to standard library via _modules_, and with that switch the ABI is changing anyway, so it could be used to…
C++ doesn't have an ABI. It just pretends to have one.
Earlier quoted context omitted.
I keep waiting for the announcement that some propeller-head has implement the Rust borrow checker as a template metaprogram, with the caveat that nothing larger than "Hello, world." compiles within a month.
Google tried and failed, and they didn't even try to model reborrowing (a hidden gotcha in Rust): https://docs.google.com/document/u/1/d/e/2PACX-1vSt2VB1zQAJ6...
In short, the type system in C++ just can't quite fully express the requirements.
What I didn't see Google do in that article was trot out any template metaprogramming artillery:
https://www.boost.org/doc/libs/1_78_0/?view=category_metapro...
I met Izzy a few times at cppcon and always came away impressed. I have basically the same thoughts about the c++ community -- it burns people out and it's filled with a ton of negativity and ego and it's very hard to get anything done. While I was at Google I spent some time trying to push for some sort of codes of conduct after a colleague of mine had a reasonable proposal ripped to shreds in email groups with all…
You do not need a code of conduct for complaining about a sexist remark inside a corporation. CoCs ruin projects, create a stifled atmosphere of hate and distrust and it is always the wrong people who obtain power. Persons who are vocally against CoCs can very well be on your side regarding sexist remarks. Personal attacks are difficult to quantify. Often they are a last resort for shutting up someone who thinks they…