SubjectToChange

OpenMP is arguably in a better place today than it was ten years ago. For instance, MSVC added support for newer OpenMP standards and implementations now support genuine device offloading. Indeed, OpenMP is probably the most popular parallel programming interface for C/C++/Fortran in use today.

Sure, OpenMP is not a pretty API, nor is it likely to yield best-in-class performance. But OpenMP is highly portable, it enjoys first-class support GCC and LLVM/clang, and it’s very straightforward to get “good enough” performance with minimal code changes. Personally, I think it’s wonderful.

Comparing all of the open issues of the llvm-project to GCC is obviously unfair. For instance over 500 issues are related to MLIR, 1700 issues are related to BOLT/lld/lldb, almost 3000 issues are related to the various clang tools that GCC does not offer (clang-tidy, clang-format, clang-doc, etc), another 442 issues are related to HLSL support, 281 issues belong to LLVM libc, various sanitizers have another 200 open issues, etc. Not to mention the extra compatibility clang offers, e.g. clang-cl, nor the fact that clang tries to be compatible with (undocumented) GCC idiosyncrasies.

Comparing open issues in the llvm-project repository is basically equivalent to comparing the open issues in GCC, binutils-gdb, glibc, and various utilities. Moreover, the LLVM project is intended as a compiler infrastructure/library framework, so it naturally has a larger surface area for bugs/issues relative to GCC. I mean, it’s not like GCC offers a generic API to interact with GIMPLE, or any other of its numerous internal representations.

I’m not sure if you are complementing or denigrating golang’s tooling. Most “STEM software” packages are horrendous in terms of user/developer experience, to the point of hampering their utility. For instance, MPI really reminds HPC users that we are in “STEM”, but not for a good reason.

Golang has good “implementation level” tooling, but that is still nothing when compared to tooling available to Java and C#. Even if GoLand is closing the gap on the IDE front (idk, I haven’t tried it), golang simply doesn’t offer the features found in OpenJDK or Dotnet (GC parameters/implementations, profiling/introspection data, interoperability/ffi, etc.). It just feels like golang’s tooling looks good when it’s competing against python, ruby, or JS/TS.

>Your comment boils down to "I'm smart", which in the end, isn't terribly smart.

They are saying that a programmer should be able to cope with the cognitive dissonance of not immediately understanding something.

>Celebrate laziness and a want for simplicity.

Concepts like generics might be intellectually more challenging, but they are clearly the “lazy” approach for actually writing code. Writing and maintaining multiple versions of the same function, or using code generation, is intellectual lazy but manually intensive.

>and there is a tremendous amount of marketing online for passive.

There’s a lot of advocacy for passive investing because it’s practically the only good option for retail investors. Managed funds can actually afford to advertise.

There are problems with passive investing becoming such a large portion of public investment, it is practically corporate welfare. But when the alternatives are at or around 2 and 20, with most performing worse than index funds, it’s irrational for the average person to do anything but passive investing.

They can’t be hemorrhaging cash when they IPO.

>stable and/or well compensated, high status job. Not exploited/abused much.

Oh, they definitely deserve a union.

>unstable and poorly paid, low status job. Abused and exploited often.

Hmm… their job doesn’t really seem “cool enough” to have a union. They should just take it and shut up. I mean, they’re losers after all.

I’m sort of joking but it’s interesting how so many people “gatekeep” unions when people in unglamorous lines of work need unions more than almost anyone else.

I'm not "playing a game". "Feld" purports to be a FreeBSD ports committer. Someone with commit rights on a major project would know how to properly file issues and work with other maintainers. But "feld" doesn't seem to know how to do that. Perhaps "feld" had a bad day, or maybe him and the rest of the FreeBSD ports contributors/maintainers just operate in this way, I don't know.

>Where did they say you did?

They said it in the part where you got all confused and responded to me.

>If

“If you break the law, then you go to jail” is not “you broke the law, you are going to jail”. I didn’t judge the entire FreeBSD community based on this blog post.

Where did I judge the FreeBSD community?

Worse yet, despite publishing seventeen blog posts between filing the issue and finally responding to it, he has the gall to open with "Sorry I missed your replies (life gets busy)".

I don't see how OpenSSL can recover from it's 3.0 disaster. They would basically have to write off the past few years of development work and start over from version 1.1.1

The blog author seems like a real piece of work. He ghosts the WolfSSL maintainer for over 160 days and when asked to open a new, more specific issue, he instead chooses to write a blog post denigrating the project. The WolfSSL maintainer was nothing but courteous and helpful throughout the entire exchange.

>...they aren't really interested in RFC compliance.

Yeah, well "feld" can't claim to be "interested in RFC compliance" either when he ghosts the issue for months and chooses to write blog posts instead of opening a new issue. Good grief.

If this is what the FreeBSD community is like, I want nothing to do with them.

I like how ZFS doesn’t have “bugs”, it has “defects”.

A CPU produced after a certain date is not guaranteed to have the every ISA extension, e.g. SVE for Arm chips. Hence things like the microarchitecure levels for x86-64.