Bjarne's keynote is quite interesting, he is yet again trying to educate the community to move beyond coding C in C++, and help improve, embrace, modern tooling.
Do you mean "C++ in Constrained Environments"? Honestly, to me it feels very abstract and hand-wavy, lacking demonstration of a real-world problem being solved. It also looks like the same talk Stroustrup's been giving for the last several years, with maybe minor tweaks.
To me talks by practitioners, who have experience in a given field allowing them to know what works and what doesn't, are more compelling. In the past Mike Acton and Chandler Carruth were such speakers. After quickly going over the schedule, this year Ben Saks, Andrew Drakeford, Ivica Bogosavljevic, Eyal Zedaka, Daniel Withopf, Andreas Weis and Ilya Burylov seem to be such speakers. I'll watch their talks when they become available.
Yes it is the same talk, because too many keep writing C in C++, that is unavoidable when the language are 90% compatible at copy-paste level, people are stuck on their own ways without reason to upgrade themselves, and too many students still learn C++ the way it was taught pre-C++98.
Many of those practitioners, do indeed do great talks, but they also live in a bubble far away from 9-5 C++ coders that put out most code.
I advise a CppOnSea 2022 talk, "help me my team is stuck in 90's".
I am sure for many of those people, they do this because they have decided that sufficiently understanding the complexities of C++ provides too little payout (or in some cases none at all) to make the shift worthwhile for them. I don't think accusing developers of "being stuck in the 90's" is the right way to convince them to work differently. If the technology is actually better, you should convince them of such by demonstrating it with many concrete examples.
Contrary to what many seem to believe, just because something is new doesn't mean it is better, even when computers are involved.
> Maybe it’s time to stop blaming devs and instead blame the language?
Ah, blaming the tools: the Hallmark of a master.
Take a moment to think about the problem. You're in a multi-team project, with a few millions lines of code. You're paid to deliver results and meet the client's requirements, and you're already behind schedule. Suddenly the C++ standard committee releases a new C++ standard. What are you going to do? Are you going to
a) continue working on your tickets, or
b) are you going to drop everything to spend weeks updating tooling, projects, dependencies, and put up a series of workshops with the purpose of getting everyone onboard the new shiny toy?
And did you noticed that option b) adds absolutely no value at all?
It's great that you can flip a flag and turn your hello world project into a C++20 project with no work at all, but real world teams that are in the business of outputting real world production-ready code requires a bit more caution.
For instance, I still recall from a previous project I worked with how a n upgrade to C++14 led a dependency to over-eagerly jump head-on to constexpr which caused weird and non-trivial linking errors that took a week or so to sort out. And constexpr wasn't a new addition in C++14.
Upgrading to C++14 - a minor release compared to C++11 and C++17 - caused a weeksworth of weird, nontrivial linking errors.
Do you think that's an unavoidable law, or is it something accidental that could have gone better?
Would you say a similar minor upgrade of the language version in other languages would have also caused a week of similar hard to debug errors, for a project of the same size?
I'm curious who you blame, if you don't blame the tools. You could try to blame people. Or one might say it's just how things are and we can't do better.
I'm just not sure if you see this as unavoidable, or if it's something else that makes you say that? You got me curious.
> Do you think that's an unavoidable law, or is it something accidental that could have gone better?
It was the result of having to develop production code in the real world, reusing real world production code developed by third-parties.
In my particular case it just so happened that the upstream dependency exported interface headers that conditionally defined stuff with C++14 features in spite of what shipped with their binaries. Stuff using constexpr ultimately resulted in tons of hard to track linking errors.
> Would you say a similar minor upgrade of the language version in other languages would have also caused a week of similar hard to debug errors, for a project of the same size?
This was not a C++ problem. This was a problem caused by the way this particular project was designed to toggle C++14 features when they should not be toggled.
Just because problems emerge when updating a project to the next language version, that does not mean the language is held to blame.
This is one of the reasons why I firmly believe half the people in this thread talking crap about software updates and bumping programming language versions are quite frankly talking about stuff they know nothing about and have zero real world experience. There's far more stuff going on in a language upgrade than flipping a switch and rebuilding a project, specially if upstream dependencies made some less-than-advisable decisions on how to release their work.
So you were linking against prebuilt libraries, and you had third party headers for those libraries that were doing some constexpr stuff that was breaking linking because the prebuilts no longer matched the headers?
In C++ if you aren’t able to build your entire stack of dependencies from source you are gonna have a bad time like this at some point. Any prebuilt libraries you depend on better be pure C, headers included.
My experience with migrating real-world projects incrementally from C++98 -> C++20 has been that it is typically closer to a day of work to get everything working with the new standard, and that the benefits have been enormous. `if constexpr` is a particularly standout example of something which has turned things which would have been a week's worth from a C++ expert into something doable in an hour by a junior developer.
I am not surprised by this lack of understanding of human psychology. People will always do the most simple, natural thing that they learned at some point in their lives. You can't expect them to change overnight or even change at all.
A lot of folks who write C in C++ are old gurus who learned their trade long ago.
In the Q&As at the end Stroustrup does give us yet another version of the "We can just do that in C++" safety claim -- https://youtu.be/2BuJjaGuInI?t=4749
"I think that the approach I'm talking about with static analysis and rule based... for modern styles can deliver complete safety"
I expect over the next decade or so, a lot more resources will be thrown at unsuccessful attempts to solve this problem.
C++ has tons of features, many will say "too many", and it accumulates over every revision. C, by comparison, is simple.
But sometimes C is too simple, it is fine for 99% of your needs, but for the extra 1%, you need C++. If that's the case, just write C and compile it with a C++ compiler so you can take that extra feature you need. Just because you are using a modern C++ compiler doesn't mean you should start using RAII, managed pointers, exceptions, and all these things.
Sometimes it makes sense to go full-on "modern C++", but using C++ literally as "C incremented by one" is a use case that shouldn't be dismissed.
Just asking because I'm curious: What are the parts of C++ that you actually use? To me RAII and managed pointers are by far the most useful features in C++, followed by templates (think of them as type safe macros with slightly less horrible syntax, not as generics).
Not the commenter but embedded embedded here so my perspective is a little different.
For me, constexpr for resolving complex build-time logic into constants, cleaner type handling for the math library makes it harder to accidentally pull in a 64-bit libm when we only have a 32- it FPU, and templating for sure.
It's pretty easy in C to reach a point where macros of macros is madness but templates calling templates still works with the debugger and is a powerful mechanism for hoisting complexity out of loops. Also works nicely for writing outer loops once in c++ calling a template specialized to either inline assembly or c++.
Managed pointers sometimes but our team seems pretty good with object lifetimes from a C background, and we don't use too much heap anyway.
RTTI and exceptions we often disable to save code space.
RAII is a little tricky without exceptions, we often use it's easy.
Good point about embedded, smart pointers aren't that great when you try to avoid allocating memory at runtime and never free it anyway. RAII is still useful for managing other lifetimes, though. The last time I worked on embedded stuff the compiler we used generated often larger code for constexpr, so we didn't really use it.
This is similar to me. As far as modern stuff, I'm willing go upto c++20, and I use smart pointers, templates, constexpr, RAII, and STL.
With templates, I use them for generics, but also judiciously to create meta-linguistic abstractions to get around certain limitations of language. For example, I built an ORM using them.
I don't use auto, or lambdas, or even foreach (I use iterators), despite oddly having much more dynamic language experience.
C is simple in a similar way that performing surgery is. Scalpel and whiskey can go a long ways if the training is accurate. A bad surgeon could also be overwhelmed by the amount of modern tools and use the wrong one. But a surgeon up to date on best practices and the wisdom of knowing what the instruments designed for is most likely going to have a higher survival rate.
This, I believe, touches upon the accidental versus essential complexity theme.
I believe people, in general, agree C is too simple of a programming language to actually deal with all the essential complexity of modern software development in various cases.
The actual complaint people have about C++ is that it has too much extra unnecessary accidental complexity due to weird ways features interact.
The analogy of the Surgeon I believe should be adjusted having these two points in mind. Generally speaking, surgeons would agree that "scalpel and whiskey" are too simple of a tool set for doing modern surgery. However, if you take modern surgeon tools and add a bunch of weirdness to them, then surgeons would reject them on the grounds of being more complicated than needed.
> A bad surgeon could also be overwhelmed by the amount of modern tools and use the wrong one.
When this is contrasted with the C++ situation, I believe the comparison would be fair only if all the modern features in C++ had to do with the inherent essential complexity of software development. That is not the case (at all). Expert developers have been talking about how C++ is unnecessarily complicated for ages (before C++03 even; back when things were simpler in terms of weird language feature interactions).
I agree with your overall point, but I feel like RAII is practically the key feature that C++ provides over C (:
Or at any rate, I wouldn't say it is anything to do with "modern C++". It was there from the beginning, and C++'s object lifetime rules are pretty core to the language IMO.
I'm curious, since you phrased it that way: what C++ feature(s) do you tend to reach for first, when moving from C to C++?
It's also interesting that Bjarne thinks that we can get full Rust-like memory safety through static analyzers for C++: https://youtu.be/2BuJjaGuInI?t=5000
But so far I haven't seen any convincing evidence that would prove (or give a high degree of confidence) that it can be done. It this just wishful thinking on Bjarne's part, or is there somewhere I could read on how he thinks that could actually be done in practice?
Would someone mind giving a description of "writing C in C++"?
It seems a bit off to me to claim it's a superset of C while banning the subset of C.
Like it or not, C++ does have things like raw pointers, null terminated arrays, setjmp/longjmp, and macros. That's part of being a superset of C. Using them in C++ is still C++ if it's compiled by a C++ compiler.
It may not be idiomatic, but I'd love to see the C++ community come up with a single definition for idiomatic C++. And to preempt the answer of "idiomatic C++ is Modern C++" -- How about things like exceptions, rtti, and iostream?
> Would someone mind giving a description of "writing C in C++"?
For starters, write non-idiomatic code which employs (exclusively or not) a subset of features.
Imagine writing Python and only using free functions, while vehemently refusing to use stuff like classes or list comprehension or exceptions or anything at all. Similar to "writing C in C++", this would be "writing shell scripts in Python".
> Like it or not, C++ does have things like raw pointers, null terminated arrays, setjmp/longjmp, and macros. That's part of being a superset of C. Using them in C++ is still C++ if it's compiled by a C++ compiler.
You're missing the whole point.
"Writing C in C++" is synonymous to "not using new C++ features that are safer and faster and better than the old C features".
It's completely irrelevant if the compiler supports raw pointers or preprocessor macros. The whole point is that, say, intentionally using raw pointers when you have smart pointers is hardly justifiable, and you're not doing yourself any favor.
I can understand if people want to avoid using classes. But list/dict/set comprehensions make building complex data structures easier and more performant.
Usually, if one avoids OOP features of Python, that means he/she likes to use more functional features. And vice-versa.
I imagine it's the same with C vs C++. People use malloc/free, classic for loops and structs+functions only because that style fits their mindset better.
Bjarne even gave an example at the talk with span versus pointer and length as argument.
Writing C in C++ means exactly that, writing C++ code in the subset that is also valid C, while ignoring everything else that the language offers regarding type safety, including basic stuff like RAII, or templates instead of macros.
Technically it is C++ code, in practice can be compiled with a C compiler as well.
Rust's advantage is that it performs static analysis at compile time. The only reason to believe that identical static analysis can not be done without the magic of Rust is religious fervour.
All static analysis is performed without executing the program. That's the definition. Whether an analyzer is runs before codegen or after is not an incredibly meaningful distinction since both can be integrated for developer environments in precisely the same way.
The magic of rust is that it forces all code to go through this static analysis to even compile. You can't avoid it. Even `unsafe` goes through it but with some additional freedom. The language is designed around static analysis, for example there's syntax for lifetimes and mutable/immutable references with their lifetime.
I see no evidence that C++ (or any language) can provide the same level of confidence, without having the same sort of support in the language itself. An analysable fragment of C++ might be a thing; rust level guarantees for the whole language is very unlikely.
That the language does not force you to use static analysis does not entail that it is not possible.
Where I work, most C code can not be checked in to source control until the CI bot is satisfied with the static analysis run. That's necessary because of C's separate compilation model: static anaylsis requires whole-program analysis to track aliasing.
Rust is a single tool that does (or may do, when opted-in) static analysis. It's not the first, not the only, and probably not the best. Other development environments use separate tools for separate operations. Engineering has always had its lumpers and dividers. Rust and Windows is for lumpers, C and Unix is for dividers.
Chromium is hardly a compiler or tooling project. Even if their devs aren't hacks, appeals to authority based on their perceived expertise hardly make any sense.
Having said that, there is no better litmus test than showing something working. If Dr Stroudtrup strongly believes in C++'s ability to provide Rust-like memory safety guarantees, there's no better person than him to prove him right (or wrong). If he does not have a proof of concept in the works, he's not in a good position to substantiate his claim.
I don't agree. Chromium is an end-user of compilers and tooling that originated in forking a third-party desktop app. Developing C++ compilers and static code analyzers is way way outside of their wheelhouse. What they can and cannot do outside of their wheelhouse is hardly relevant or representative.
I think you under estimate just what level expertise and pull modern web engine requires. Google funded a ton of the work to support clang building code for Windows explicitly so they could standardize on clang for Chromium on all platforms. In turn they used the fact that they use a single toolchain across all platforms to add support for things like control flow integrity, which involved low level ABI and runtime changes to to the compiler and libc++. That requires tight cooperation between the Chromium and the compiler teams, and is definitely beyond a typical "end-user of compilers and tooling."
Admittedly my claims about Chromium are based on my observations as an outsider, but as someone who works on tooling (linkers) at a different large company that also has a web engine written in C++ I can tell you it is consistent with what I have seen up close... web engines (and particular JavaScript JITs) tend to push C++ tooling hard and often inspire major investment by the teams working on C++ specifically to support them.
In fact, over the years I have seen a number of people (including C++ committee members) who transitioned back and forth between the C++ compiler teams and the JavaScript JIT teams because they sometimes work very closely together, so in my experience the level C++ expertise on lot of the teams developing web engines tends to exceed anything but the actual C++ tooling teams supporting them, and developing C++ tooling is most certainly in their wheelhouse.
Statically provable memory safety is probably possible in some sorts of code, like business process logic where performance isn't critical, and you can use std:: containers and copy everything.
A browser is a much more demanding environment, involving code generation, multithreading, caching, and low-overhead interfaces to complex data structures. Memory safety is extremely hard in that case.
For correctness’s sake let’s add that the problem domain of Chromium doesn’t allow for only-safe Rust. Recursive life cycles are not enough here, and for performance reasons (A)RC is neither.
That is, it uses placement new to constructs the object inside a GC'd heap.
-----
I don't believe the C++ idiom is any faster, and it makes the code larger (and potentially slower).
Am I missing something?
I think the issue is that the monomorphization happens for each T and not for each sizeof(T), and even doing it on sizeof(T) is not really necessary for fast code.
Oil has more fine-grained and ML-style strong types than any other shell implementation, via ASDL and C++. So I try to take advantage of additional type safety. But sometimes it's not worth it. I suspect the macro is better here. It will be somewhat annoying to change all the code, but probably worth it.
A point that I rarely see raised is that in mission critical or safety critical applications, exceptions and implicit heap allocations are, with good reason, explicitly banned.
The way they killed C++/CX and insist everyone uses COM with tooling that was already bad enough in the Visual C++ 6.0 days, 20 years ago, they could start by sorting out the mess at Microsoft in first place.
Currently the positive part is that VC++ is the most compliant in ISO C++.
Note that other than the spaceship operator, all Herb's former proposals for reflection, exceptions and parameters have fizzled out at the committee, nothing happened after his CppCon talks.
I don't know that they've "fizzled out" it just takes a while. There have been papers this year on reflection, comparing different versions of it. I'm hopeful for that and exceptions making it in soon-ish
C++ is a continually evolving language. It's becoming a legacy only due to people thinking hasn't really changed the past few decades, something that isn't the case.
If that's how we define a non-legacy language then COBOL is also not a legacy language; after all the newest standard was released in 2014, with a new standard currently in development. (:
To me, a legacy language is such that people used it for the prevailing share of code of certain kind, and now the prevailing share of new comparable projects gets written in different languages.
I think that C++ is moving towards becoming a legacy language (with a huge legacy of important codebases written and maintained in it), but it's not yet there. Rust and Go keep replacing it at different ends of spectrum though.
> To me, a legacy language is such that people used it for the prevailing share of code of certain kind, and now the prevailing share of new comparable projects gets written in different languages.
That's certainly a definition, but C++ would still not meet the definition of a legacy language by that measuring stick. C++ remains one of the most popular programming languages in the world in spite of the inception of alternatives. For instance, TIOBE (I know) lists C++ at the 4th place of it's popularity ranking, and features 4th place in GitHub's pull request ranking for 2022.
Also, we should keep in mind that C++ was basically the only relevant programming language available for some domains, such as Windows desktop development. Since then, Microsoft put its collective weight in C# to portray it as the one and true technology, and in the process pushed C++/CX and C++/WinRT as part of UWP, which aren't exactly C++. If one vendor changed its mind and decided to roll it's proprietary solutions as C++ competitors, that's hardly an issue with the merits of C++.
One thing that C++ does not have but some niche wannabe competitors have is teams of PR and evangelists selling the idea that a few loudmouths generating noise day and night represent a change in the baseline.
TIOBE's mechanism is counting search results of various highly ranked search engines.
These search engines confuse C, C++ and C# all the time. So I'm sure there's some level of mutual inflation of rankings going on there, even if you accepted search results as a meaningful metric.
Similarly, I'd be a little suspect of the SQL variants rankings
It’s astonishing how fast the zeitgeist has changed in the upper echelons of the C++ community. Only a few years ago everyone was excited that the language had broken out of its 0x-era rut and into a regular cadence of significant modernizing improvements. The word “renaissance” was used often. Now everyone seems miserable.
> Only a few years ago everyone was excited that the language had broken out of its 0x-era rut and into a regular cadence of significant modernizing improvements.
The 0x era started around two decades ago, a few years after the release of C++98, and arguably ended over a decade ago with the release of C++11. This isn't something new.
> Now everyone seems miserable.
I don't see any misery. If anything, what I see is projects bounded to old C++ versions due to real-world constraints.
Modern C++ is fantastic. Memory errors are rare and easily contained since data structures can be treated as values. It is flexible down to a very low level, but most programming can be done at a much higher level.
Ignoring inheritance and using templates, you can just make programs about simple data structures and loops. No hacks needed to work around garbage collection or excessive memory allocation, it's great.
Hardly miserable. But we do need to address the fact that people are not starting new projects in C++. It is a fact, and that fact has a well understood reason. Solving that issue the regular way, through implementation, committee and then standardization, seems herculean. In fact, it is probably never going to happen. That contributes to negativity, but it is not hopeless.
Translating a modernized, possibly memory-safe version of C++ to standard C++ is definitely one such possibility, and it is great that someone who is as capable as Herb Sutter is working on it.
> ...people are not starting new projects in C++. It is a fact...
That's absolutely not true. I've seen plenty of new projects in C++ in the last month alone. A lot of the time when someone writes a binary wheel for python, it's in C++ for example. I'd ask for citation, but I can't imagine how someone would demonstrate a negative claim like this.
Is that even feasible? Could you resurrect Fortran or COBOL by bolting on modern features to those languages? Herb’s the genius that we don’t deserve but I have to think his generational talents are going to waste by plugging a sinking ship rather than designing the successor to C++ (rather than the Carbon devs who seem incapable of recognizing good design).
I agree with your point but Fortran is actually a bad example for your case because it has been revamped throughout the years (with the latest standard in 2018) and Fortran is used extensively in simulation and HPC applications
Fortran 2018 already has modern features. What modern feature are you specifically talking about that Fortran lacks? There is more to arrive in Fortran by 2023 and 2027.
of all the recent "C++-v2" languages (carbon, etc) this is the only thing so far which seems to solve exactly the issues I encounter while developing with the language day-to-day
I think it is more natural because it tackles things like exception handling in a new novel direction: Zero-overhead deterministic exceptions, among other things. He picks up all the things that clearly have great potential (and some have been proven to be very good in other languages) and is making a frontend for them.
Carbon, on the other hand, is just Google code standard as a frontend. No exceptions, weird naming schemes etc. It's like a coding guideline made language. The guys behind it clearly know performance though, so I am not saying it won't be that. But will it be a great language? I don't think it can compete with what Herb Sutter is trying to achieve. I am of course willing to be proven wrong.
As I see it, Carbon have in its explicit goals to fix both the syntax issue and the major ABI retrocompatibility issue, while herb approach is to just deal with the syntax: Sure it is better than nothing, but I'm willing to bet that this will not convince most of people that saw their idea being killed by the committee on the ABI altar.
Has anyone recently written a non-trivial greenfield project using modern C++20? Or know of any such interesting projects on GH with very well written C++20?
It's my first real foray into C++ (most of my experience is with Julia) so code quality/awareness of idioms, etc are probably lacking, but it's using C++20 and I'd appreciate pointers if anyone has any: https://github.com/JuliaSIMD/LoopModels/blob/main/include/Ma...
So far, I think C++20 seems like quite a nice language.
But generally when people say "modern C++20" they are asking about the use of the modern STL concepts as well as the modern language additions. This is evidenced by looking at how much CppCon talks emphasise the STL
I'd say https://gitlab.com/exotracker/exotracker-cpp has fairly decent code quality (though I'm obviously biased as the author), but it's not feature-complete or useful, and I've put it on hiatus because it's a struggle to implement high-level editing, mouse interaction, copy-paste, etc.
A small critique of your code (though it does seem to me the overall quality is decent): watch out for unintended ADL. You call lots of unqualified namespace-level functions (like load(...)). This triggers ADL, and it doesn't look like it's always intentional.
Oof... ADL scares me, but I don't know which load(...) you're referring to. src/serialize.cpp has a single such function call, am I supposed to avoid using the name `load` or qualify it with the namespace path (perhaps I shouldn't have nested namespaces so deeply, but I don't want to change it now)? Everything seemed to compile and work fine the last time I touched this codebase.
> Oof... ADL scares me, but I don't know which load(...) you're referring to. src/serialize.cpp has a single such function call
Yup that's the one I mentioned. It was just an example though, there are lots of others.
> am I supposed to avoid using the name `load` or qualify it with the namespace path
The latter. i.e. you should write serialize::load() (or ::serialize::load()) unless you intend ADL to occur.
> Everything seemed to compile and work fine the last time I touched this codebase.
Yeah I wasn't claiming it wouldn't compile right now. The problem is that it has a higher risk of changing behavior in the future. In this example, if this function is ever introduced:
namespace kj { auto load(InputStream &stream) { ... } }
then suddenly that function will get called instead of yours, which may or may not result in a compiler error.
It's not exactly the biggest footgun in C++, but "well-written" C++ code tries to be careful about pitfalls like these.
I want a language with the pragmatism of C++ rather than the "mutability excludes aliasing, no lifetime errors allowed, at the cost of usability, and no defined unsafe pointer semantics so far" unfinished experiment of Rust, with better sum type syntax than std::variant, and eliminating C++ footguns luke {implicit conversions, implicit copies, mixed-sign integer comparison, silently overriding virtual methods, C-style casts of multiple inheritance pointers is UB...}. Perhaps Cppfront holds promise, possibly Carbon or Jakt, maybe Zig though it lacks RAII when convenient and its return value semantics (much like Carbon's) is a footgun: https://github.com/ziglang/zig/issues/5973.
I think the text editor, [Kakoune](https://github.com/mawww/kakoune), was written as an experiment in modern C++ language features. Its documentation says it requires a C++20 compiler, though I don't imagine it was originally for that version, since it was started before 2020.
How much value does this conference provide? Would you attend it on your own dime?
I see many presenters going from one C++ conference to another to give essentially the same talk. Specifically, I looked though the talks of the CppCon 2021 several months ago (as most of the presentations became available online) and found very few with a new material. It wasn't enough for me to consider paying upwards of $2K for them.
At this point the only reason I'd consider attending such conference is to make professional connections.
I wonder if with all its recent advancements and features C++ can still be, however weakly, considered a general purpose language or at this point it is firmly a specialist language for niche application?
I don't know about you people, but this whole twitter thread pretty much sums up why I don't bother engaging too much in online communities whatsoever. I don't care what happened there and who feels offended or whoever should be excluded for whatever reasons. I feel if someone did something wrong we have an established system for this called court.
This whole public shaming and social justice warrior thingy feels to me just medieval wrong. This is also the reason why I like HN as here the focus is pretty much tech related which gives me somewhat peace of mind.
Not all grievances are best suited for court, and courts are not always impartial. There are also legitimate reasons to exclude someone from a gathering without them breaking laws.
I'm sure it's nice to be able to put your feet up and ignore that whole messy social justice thing, but unfortunately a lot of people don't have that opportunity.
I respect your opinion but I disagree strongly with your claim that this is “medieval”.
Courts have the power to truly end people’s lives. Because of this power they must have the highest standard of proof: innocent until proven guilty.
However, many crimes are very difficult to prove, which means courts mostly can do nothing about things like rape, harassment, etc.
That’s a good thing on some level, we don’t want to put innocent people in jail.
But if we leave it at that, and simply disbelieve all stories not proven by courts, then the vast majority of victims of crime will be totally left without support.
That’s why personal policies like “believe women” exist… not because they are more true than “believe the courts” but because both policies are flawed and so together they provide better coverage of innocent people than either policy could alone. For the innocent victims who haven’t been protected by the law, the “believe women” community has their back. For innocent victims who have been falsely accused the “believe the courts” community has their back.
I believe this diversity of belief is essential.
And so, I support you being a “believe the courts” person. But I would like you to consider that this leaves you in a position where you can’t support a large number of victims of crime. And therefore that’s a job other people, with a different attitude to the courts, must step in and do.
I don't think anyone has anyone's back. All it takes it one group of people to demonize you, and the damage is done.
When some terminally online lefties doxx you and try to get you fired, does some other group of people sweep in to your defense, in your experience?
Your characterization of “believe women” existing as a counterbalance to the flaws of the legal system is compelling, although it still doesn't seem like a good idea. One system is unchecked vigilante bullshit, while the other system is a transparent, evidence-based process. It's like "the medicine doesn't work; let's sacrifice goats and bloodlet instead".
Nitpick: it's not “believe women”; it's “believe ALL women”, which is more hilarious. (And frankly sexist, as it strips women of the agency to lie, which -- spoiler-- is a thing people do all the time.)
I agree with the idea that someone who was convicted twice of sex crimes in a leadership role is a bad idea and that by including them you may be excluding others.
Although I am curious about your opinion about other senarios. What is the person was found guilty in a US college Title IX court? Or what if it was just an accusation online? These are the questions we should get clear answers to now so when they (inevitably) happen, we know how to act, we don't have a twitter debate war to decide.
I don’t think there is any universal answer to your question. I think individual people should make individual judgements in individual scenarios about what to believe.
Sometimes I may believe an accusation and sometimes I may not. I don’t want to offload that responsibility to anyone else, in a court or anywhere.
On one hand we would like to support folks serving their time and coming back to society as full citizens. I don’t think any of us would support stripping ex-cons of the right to vote or support themselves.
On the other hand, we also recognise that we can’t force people to work with those they don’t want to. This isn’t theoretical. One of the members of the committee is a rape survivor and doesn’t want to work with a rapist. The wide support in society for sex offender registries indicates that many people feel the same way.
That’s the dilemma - only one of these two people will ultimately work on the committee. Inaction is a choice. If we do nothing, it’s the ex-con, and we lose the other person. This is the choice the ISO CPP leadership has made.
It’s complicated a bit further. Many other folks on the committee aren’t comfortable working with a rapist either. So in exchange for supporting one ex-con, you lose several people.
Being "uncomfortable" with somebody should not be enough to forever lock them out of society. What happened to "diversity and inclusion"?
> "That’s the dilemma - only one of these two people will ultimately work on the committee."
There's actually nothing preventing either of those people from working together on the committee. The individuals in question should be allowed to make their own informed choices, based on their individual situations. This should include things like the degree to which they would be cooperating together, the nature of the cooperation, and the practicalities - as long as they are within the boundaries of the law (which also includes anti-discrimination laws).
This person was convicted of raping someone. You feel safe interacting with them in person, but others might not.
It would be good to show a bit more empathy. Don’t dismiss them just because you don’t feel the same way.
> diversity and inclusion
Don’t misrepresent what this means. Inclusion is about including people who’ve been excluded through no fault of their own. Is your claim that a convicted rapist has done nothing to deserve to be excluded?
> "This person was convicted of raping someone. You feel safe interacting with them in person, but others might not."
The fact that some people may "feel safe interacting with them in person, but others might not" is exactly my point. We shouldn't be locking people out of society forever and ever based on feelings. We need to work locally to try and find optimal solutions to specific problems, and provide the tools needed for the individuals involved to make the best out of the situation (within the boundaries of the law, which includes anti-discrimination laws).
> "Don’t misrepresent what this means. Inclusion is about including people who’ve been excluded through no fault of their own."
That's your interpretation of this, but that's not the universal definition of "inclusion".
Also, do you actually know the specific people involved, and the specific details of what happened? People commit crimes due to any number of factors (experiencing abuse earlier in life, mental conditions, being a victim of a crime themselves at some point, different struggles, etc). You yourself just suggested that "it would be good to show a bit more empathy", so how about you actually follow your own advice?
> "Is your claim that a convicted rapist has done nothing to deserve to be excluded?"
No, that's not what I claimed at-all. It's always amusing to see the logical leaps a SJW will go through to try and get a point across.
First - when you say "excluded" - could you be more specific? Excluded from what exactly? From life on earth? From ever leaving home again? From ever interacting with other human beings? What exactly would be an appropriate life for a person in this position, according to you?
Second - this person, according to you, has been convicted. In a democratic, law-abiding society - this means they've been handled by the legal and correctional systems, which are the only two systems that have a monopoly on "judging" and "correcting" people. It's not up to a C++ conference to "judge" or "correct" people.
Third - this person may very well be trying their hardest to heal, move on, and start over. What are you doing to help such people come back and reintegrate into society?
Fourth - why stop at one specific class of crimes? Let's throw out everybody with a record. Tax issues? Stealing candy at a gas store when you were 12? Bad divorce?
How about speeding tickets? I don't feel safe working with people who drive recklessly. We must make sure there aren't any such people in CppCon 2022.
Got arrested by the police at a violent BLM protest? Too bad, you're locked out of society forever. Or... wait, that's not the people you're actually after here, are you?
Would you send your daughter to an event with knowledge organizers conspired to hide the fact one of the speakers, authoritative figure young people would look up to and trust, is a registered sex offender? More specifically the one from above link.
> Fourth - why stop at one specific class of crimes? Let's throw out everybody with a record. Tax issues? Stealing candy at a gas store when you were 12? Bad divorce?
This is really disingenuous. When you're interacting with a stranger, and you find out they had a bad divorce, do you suddenly feel concern that they might divorce you?
Let's go in the other direction. Do you believe child sex offenders are suffering injustice when they are not allowed to interact with children? How about drunk drivers that are permanently banned from driving (hypothetical though that may be)?
> "This is really disingenuous. When you're interacting with a stranger, and you find out they had a bad divorce, do you suddenly feel concern that they might divorce you?"
I think you got the general spirit of my comment, and I don't want to play tit-for-tat over the examples I provided. Why should the bar for banning people from associating with C++ conferences only stop at one specific class of crimes?
> "Do you believe child sex offenders are suffering injustice when they are not allowed to interact with children?"
No, I never said that.
What we're seeing here is a coordinated social justice campaign (taking place on Twitter and other social networks) to ban an ex-con, who is an otherwise free human being, from associating with a C++ conference.
I think it's a good question to ask, because I agree the social justice cancel war feels a bit silly, generally speaking. But you equated one of the most violent crimes with misdemeanor petty theft of a 50 cent candy bar. That doesn't make any sense.
> On one hand we would like to support folks serving their time and coming back to society as full citizens. I don’t think any of us would support stripping ex-cons of the right to vote or support themselves.
The person in question is a registered level 2 sex offender. This means they are not a full citizen and are still serving their time.
So, no, we don't want to support allowing registered sex offenders to attend, present, plan, etc. a large conference and community, and this is less complicated than you describe. The community has been very clear and aligned in their dismay.
Yeah I mean, he's a pedophile rapist, so like, that's a bit worse than being an ex con. I'm not saying he shouldn't be allowed to work anywhere but he doesn't really need to be in a leadership role giving talks at a conference.
You are mistakenly (or deliberately, I guess) conflating ethics with legality. Rape is different from homosexuality because homosexuality isn't harmful or morally wrong.
My parent post specifically used the word "crime" my response was to show that "being a crime" is not a good reason.
Also morality is subjective. For example, the government of my country argues that homosexuality is immoral (obviously I disagree). So the question is whose moral are we considering? Your personal morality? Mine?
And is it moral to ostracize someone from society because of a crime they have been punished for?
> So the question is whose moral are we considering? Your personal morality? Mine?
The morals of the community in question. The laws and customs of unrelated countries or communities are immaterial to the decisions of this particular community.
> And is it moral to ostracize someone from society because of a crime they have been punished for?
It's one thing to ostracize someone from society entirely. It's much less extreme for one particular community to say that someone with a track record of abusing authority or positions of trust shouldn't be put in a position of authority or trust.
There are only a limited number of positions of authority in this community, and plenty of people who are perhaps more deserving of that position who don't have a track record of abusing such positions. It was noted that this person received financial support from the conference. Maybe that didn't need to happen, given there are others who were not financially supported?
> The morals of the community in question. The laws and customs of unrelated countries or communities are immaterial to the decisions of this particular community.
So it is OK for me to demand a homosexual co-worker be fired if the community of my workspace is homophobic?
It's not. Nobody in 2022 serves sentences for being black, according to the law (unless the justice system made a mistake). It was a rethorical question.
it's the paradox of tolerance. a jewish person might be unwilling to work in a place that tolerates an open nazi, and a racist might be unwilling to work with a black person. The point is that you have to make a decision at the end of the day, because not making a decision is also making a decision. And usually it's not the people who hate black people who will choose to leave. So while this is an example where you would obviously not want to respect the wish of the person uncomfortable working with someone else, it's not the way this situation usually goes. usually it's the rape victim or marginalized person who will end up leaving.
According to the law in most places, there are no such places that tolerate an "open nazi" because being a nazi is a crime. There are law against antisemitic speech. There are also laws against racism. You don't have to make a decision at all, the decision has been made for you. Well, I guess you have to make a decision to follow the law or not but that's an extreme.
If someone in a conference is open about being a nazi or a racist, you call the police, maybe collect some evidence first, etc. Whatever is needed in your country to report an offense.
And yes, I agree... usually the victim will leave the place, not having enough energy to be an activist on top of dealing with their troubles and/or fearing the consequences. That's unfortunate. But that's where it gets complicated, for the victim. Not for the conference organizers.
i guess, i feel that's missing the point of the example, though. Like I could have said open racist (which is not against the law as you imply) instead, i just picked a random example.
But you are making the decision that this is something for the victim to deal with, not the organizers. That's not at all a given by default. As you yourself point out, the same standard is not applied to nazis, so why pedophile rapists? If you are in a position of power it is your job to make these decisions one way or the other, it's not a foregone conclusion.
I'm saying they should follow the law and refrain from doing more than that. I feel the law is currently sufficient to deal with this situation and we don't need a cancel campaign online.
It’s currently 100% legal (at least in America due to the first amendment) to be a nazi, anti semite, or racist and to express your opinions as such. So following the law doesn’t do anything for this community.
As far as I'm aware, organizations like the American Nazi Party or the National Socialist Movement (United States) are legal in the US. Even Germany failed to ban its neo-Nazi party (the National Democratic Party of Germany) despite the court acknowledging that its goals are anti-constitutional and similar in nature to historical National Socialism. As long as you color within the lines, it is possible to be an open Nazi in most places.
You're still allowed to exclude them on the basis of being Nazis in most places in the US. Political affiliation/ideology is generally not a protected class.
I was merely adding that even in a country where being an open Nazi is legal, it is still legal to exclude Nazis from your place of business, not arguing against you.
That's not really the paradox of tolerance. At least not the version attributed to Popper.
The relevant quote from The Open Society and Its Enemies is:
> But we should claim the right to suppress them if necessary even by force; for it may easily turn out that they are not prepared to meet us on the level of rational argument, but begin by denouncing all argument; they may forbid their followers to listen to rational argument, because it is deceptive, and teach them to answer arguments by the use of their fists or pistols.
It's about the right to suppress those who leave the arena of debate and move to extra-judicial force, such as the extra-legal violence used to keep black people subdued during segregation (the work was published in 1945, segregation is very relevant).
What you described is people not wanting to work with people that hate them.
I am conflicted about this. On one hand I understand the emotional response and find rape and cp incredibly repulsive but on the other hand I wonder if this goes too far since apparently the person served their sentence and it's been a decade since (without any inappropriate or illegal activites?).
From their proposed letter[1] they say: "We are not pursuing this person throughout their professional life trying to remove their livelihood." while simultaneously saying: "In this case we see no other option than to remove the person fully from the conference and we recommend that most other C++ communities consider this as well."
And they re-iterate over and over that the offender shall not be named (while simultaneously being known to quite a few people apparently - which would be a prerequisite to have the offender removed from other communities as well) and therefore the only alternative is removal to prevent the offender from abusing their position of power to harm someone again.
While this is a little shaky I wonder why there should not be other options. Since apparently the board knows who X is, they could easily book security for the event and keep a tighter watch on the person. I will go out on a limb and say if person X was excluded from the conference while also seeking to repeat their offenses they will find another venue so the problem is not solved, rather offloaded on someone elses shoulders. Surely the person proposing the removal would not see that as a viable alternative?
There is also a linked petition to ban convicted sex offenders from the standard meetings which I would find more rational if the crime was very recent, the person had repeatedly commited the crime or shown inappropriate behaviour since. It[2] verbatim says: "The choice WG21 has is between an individual convicted felon and diversity and inclusivity. There is no third option, as inaction is a decision for the status quo and the convict." which I find bewildering. First of all I don't understand the logic behind only including sex offenders because even in their frame of reference inclusivity would be threatened by people convicted of fellonies regarding racism or any other type of violence, and second of all - leaving their frame of reference - why is it that they insist that a person who did something bad will do it again. They make it sound like the harm that has been done is inevitably gonna happen again. I am not so sure if this is a smart position to take.
I was very hesitant to write this and I'd like to be educated if I am missing something fundamental here, but I have trouble agreeing with the position that people who served their time after being convicted of a crime (which is the legal and at its core societal measure for "things being settled") should continue to get punished because someone feels like it's not enough. And I also have trouble seeing how harm is actually prevented this way and not just off-loaded.
> they will find another venue so the problem is not solved, rather offloaded on someone elses shoulders
It's not the CppCon's responsibility to play court/police here.
If this person served time and is not a suspect in any other ongoing investigation, CppCon has no role to play other than accept his presence. If they remove him based on other people's feeling torward ex-cons, they open themselves up for getting sued for discrimination (which, ironically, the people complaining here should know how that feels like very well).
The concern is less that this person (they've been named in other threads - this issue is not new) will attack people at cppcon but that the leadership has decided that a rape survivor refusing to interact with this person is a violation of the code of conduct.
Note this action was supported from a lot of established members in C++ community, including C++ standard library chair, who asked for "New C++ Leadership"[1] and many googlers.
