CppCon 2022
cppcon.org
cppcon.org
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.
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 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.
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.
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.
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.
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.
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.
"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.
Maybe I am misunderstanding? Don’t you have to solve inter-procedural pointer aliasing first?
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?
(I'd be inclined to take their word on it over Bjarne's.)
I'm not sure this is where I originally read their conclusions, but lots of info about this, regardless: https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76D...
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.
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.
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.
So both could be true.
Visual C++ support for it is pretty much WIP, full of false positives.
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?
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.
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.
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.
C++ is not a superset of C.
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.
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.
And they only just barely managed to get something usable in the beginning. Rust ergonomics have improved a lot since 1.0.
The criticism here is that C(++) advocates often claim the language is fine, and static analysis is enough to fix the problems.
Rust is hopefully just a stepping stone to something better, but the assumption that no new language semantics are needed is denial.
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.
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.
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.
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++?
An example is I wrote a varadic template for a GC allocation interface:
T1* obj1 = Alloc<T1>(arg1)
T2* obj2 = Alloc<T2>(arg2, arg3)
https://www.oilshell.org/release/0.12.5/pub/metrics.wwz/oil-...
The total vmsize is 1217792 and the 2 Alloc<> entries are about 10% of that.
So my conclusion is that it would have been better to use a macro all along, which would look something like:
T1* obj1 = ALLOC(T1, arg1)
T2* obj2 = ALLOC(T2, arg2, arg3)
T1* obj1 = new (gHeap.Allocate(sizeof(T1)) (arg1)
-----
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.
template <typename T, typename... Args>
T* Alloc(Args&&... args) {
assert(gHeap.is_initialized_);
void* place = gHeap.Allocate(sizeof(T));
assert(place != nullptr);
// placement new
return new (place) T(std::forward<Args>(args)...);
}
So there is nothing to really break up
So no standard library for you.
Which likely implies "no C++".
Which keeps us writing in C.
It is his ongoing work as he presented it on CppCon today.
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.
See: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p07...
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.
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.
https://madnight.github.io/githut/#/pull_requests/2022/1
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.
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
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.
Doesn't matter, because it was made public Herb Sutter's presented his own language as solution to fix C++ at this year's CppCon,
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.
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.
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.
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.
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) { ... } }
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 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.
Here is a thread about it: https://twitter.com/pati_gallardo/status/1501211140310904841
Why am I not surprised?
As a female PoC, I am convinced that all of this pseudo-activism is either out of pure fucking boredom or personal vendetta.
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.
[1] https://patricia.no/2022/03/08/proposed-cppcon_safety__inclu... [2] https://www.change.org/p/ban-convicted-sex-offender-from-iso...
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).
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.
If I don't want to work with a black person, do I have a right to demand they be fired?
(this is a theoretical question)
Unless this is true, your comparison between being black and being a rapist isn't valid.
Well, in USA many people served lifetime sentence of forced labor for being black, so I guess the answer is "yes"?
And is it moral to ostracize someone from society because of a crime they have been punished for?
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?
So it is OK for me to demand a homosexual co-worker be fired if the community of my workspace is homophobic?
For instance, I have no problem with the Catholic church banning gay priests. But I'm not outraged because doing so isn't banning gays from society.
Who gets to decide that? For many religious people, it is both (and actually criminal when proven). We take our religion seriously.
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.
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.
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.
> "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).
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?
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?
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)?
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.
"Megan’s Law refers to a collection of laws that mandate the notification of sex offenders in a particular community to the people that live there."
Here is how it looks in practice https://dailyvoice.com/new-york/yonkers/news/sex-offender-co...
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.
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.
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.
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.
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.
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.)
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.
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.