Hacker News Reader

SubjectToChangeon Musl: List of alternative libs that are lightweight, not bloated and efficient

Less "bloat" doesn't mean more performance. C++ libraries have soundly beaten their C counterparts in HPC, HFT, ML, etc. And in any case it is still possible to write a C-dialect in C++ if you so choose.

SubjectToChangeon Simply Parse in C

The problem is that writing abstractions in C is more difficult than virtually any other practical language.

SubjectToChangeon The US economy and the EU were the same size in 2008, the US is now nearly 2X

Do you really believe that the USA would commit an act of war against Russia to… sell Europe natural gas?

SubjectToChangeon CWE Top Most Dangerous Software Weaknesses

“Modern C++” is not necessarily tied to any specific standard, it is more a collection of ideas and philosophies. Although if I had to pick I’d say it really started with C++11.

SubjectToChangeon C++23: The Next C++ Standard

fmt has been available for years and it works with ridiculously old compilers. It’s great to have it standardized but it’s not a new capability that C++ didn’t already have.

SubjectToChangeon C++23: The Next C++ Standard

And how exactly do you propose library authors should work with user-defined types? Operator overloading is what allows algorithms to be efficiently generalized across types.

SubjectToChangeon C++23: The Next C++ Standard

Operator overloading is one of the cornerstones of generic programming in C++. And perhaps it is a failure of imagination on my part, but it’s difficult to think of a more elegant approach.

SubjectToChangeon XFS online filesystem check and repair

I’ve been running btrfs on my laptop and workstation since 2015 and haven’t had any issues. I get all the advanced FS functionality I want without needing to worry about kernel versions or any of the other hassle of setting up ZFS.

In many ways ZFS feels like the last hurrah of “traditional” file systems. The fact that ZFS finds itself without genuine alternatives isn’t because it’s just that good, it’s because industry players have moved on. If all you need is a monster file server or a local data archive, sure, use ZFS.

SubjectToChangeon XFS online filesystem check and repair

bcachefs will have its share of teething issues. Being merged into mainline is only the first step of a very long journey.

SubjectToChangeon C++ is everywhere, but no one talks about it

No one completely understands Linux. No one completely understands a software package like Siemens NX or CATIA. No one completely understands LLVM. Etc, etc, etc, and the world still goes around.

Having a “small language like C” doesn’t do anything besides move the complexity to application code and hide those details from the compiler. In fact, with sophisticated optimizing compilers and linkers, it’s impossible to predict what any random snippet of code in a large project is transformed into, assuming it exists at all in the final binary.

SubjectToChangeon C++ is everywhere, but no one talks about it

Nothing is forever but this totally discounts the primacy of C++ across tech stacks. Rust and any other language leveraging LLVM is depending on a healthy C++ ecosystem. Anything to do with GPGPU is aggressively C++ based, the entire HPC segment is pivoting hard towards C++ (Kokkos, SYCL), and it’s likely orders of magnitude easier to rewrite the entire Linux kernel in Rust than it would be to rewrite chromium in Rust.

SubjectToChangeon C++ is everywhere, but no one talks about it

This, mind you, is not even counting the fact that most JVM implementations and Node interpreters are also written in C++.

Moreover every major C compiler (GCC/Clang/MSVC/etc) is written in C++. So any C projects depending on those compilers is indirectly depending on C++, e.g. Linux. Not to mention the success of LLVM among other languages.

SubjectToChangeon Making C++ safe without borrow checking, reference counting, or tracing GC

Keep in mind that a lot of C++ users really didn’t have a choice, it was either C or C++ for a lot of applications. In fact C++ is often still the only option, with some segments (like HPC) doubling down on their investments in the language.

So how do we serve those users? Rust doesn’t give them a path forward. Simply getting C++ compilers to agree is difficult enough, much less an entirely different language.

SubjectToChangeon Making C++ safe without borrow checking, reference counting, or tracing GC

Rust only requires you to wrap it in unsafe. And I think C# allows you to do some pretty crazy stuff too.

SubjectToChangeon Making C++ safe without borrow checking, reference counting, or tracing GC

As an addendum, the same goes for many C toolchains. Anything requiring GCC 4.8 or later is depending on a C++ compiler. And projects like LLVM’s libc, Fuchsia’s Zircon kernel, the bareflank hypervisor, etc, demonstrate that C++ really can be used anywhere C is used.

C++ is the new C in the sense that it’s the language everything else is built on and I expect it will be even more difficult to displace than C. For instance, the complexity of C++ makes it next to impossible to incrementally rewrite in another language, simply writing a production quality C++ implementation is a gargantuan investment so a superset language is questionable, and the C++ community is committed to evolving and improving their language whereas C has largely ossified. Perhaps C will outlive everyone reading this thread, but C++ will outlive C.

SubjectToChangeon Making C++ safe without borrow checking, reference counting, or tracing GC

I think it’s generally accepted that writing code is nearly universally easier than reading code, in any language. That aside, getting a mechanical check on memory safety for the price of some extra language verbosity is obviously worth it IMO.

By the same token, it is common to see criticisms of the complexity of templates in C++, but templates are the cornerstone of “Modern C++” and many libraries could not exist without them.

SubjectToChangeon JEP draft: Move the JDK to C17 and C++17

C++ has constructors, designated initializers are redundant.

SubjectToChangeon Linux Namespaces Are a Poor Man's Plan 9 Namespaces

/proc is for stuff like shell automation, not normal 'file' use.

Systems like /proc/ are cornerstones of the “Everything is a file” concept.

The idea is that files are just byte streams/arrays, and pretty good to be optimized.

If your point is simply that “files are efficient because they are just dumb bags of bytes”, then you are in a rude awakening.

SubjectToChangeon JEP draft: Move the JDK to C17 and C++17

There's a weird tendency to lump together C and C++ into "C/C++", as though it was the same language.

It’s about as weird as writing “HTML/CSS/JS”, or “Java/Kotlin”. Like it or not people write related languages and technologies that way.

Makes about as much sense as Java/Javascript at this point.

Do you know what “ISO/IEC JTC1/SC22/WG21/SG22” is? It’s the C and C++ Compatibility Study Group for ISO C++. For instance the only reason C++20 added designated initializers was for improving C compatibility.

Stop pretending C and C++ have nothing to do with each other. Using “C/C++” is fine.

SubjectToChangeon Linux Namespaces Are a Poor Man's Plan 9 Namespaces

When everything is a file, what is a "file" becomes flexible.

It’s really “Everything has a File Descriptor”, nothing about the concept of a file has changed.

It's in essence no different than OOP or actor model or what have you.

I’m sure there’s an isomorphism that could be drawn but it does nothing to show that it’s an equally good paradigm to write software in. IMO, it’s a tortured abstraction.

SubjectToChangeon Linux Namespaces Are a Poor Man's Plan 9 Namespaces

Plan9 is the perfection of a dead end.

SubjectToChangeon Linux Namespaces Are a Poor Man's Plan 9 Namespaces

And in exchange for that performance we got one of the most insane /class/ of unfixable CPU bugs ever imagined.

What do Spectre and Meltdown have to do with “everything as a file” system architecture?

SubjectToChangeon Linux Namespaces Are a Poor Man's Plan 9 Namespaces

Care to explain? How does something like procfs map better to hardware than an explicit API?

SubjectToChangeon Linux Namespaces Are a Poor Man's Plan 9 Namespaces

…we're using insane amount of code and cpu load to solve really simple problems on daily basis.

Piping programs together is almost always going to use significantly more resources than one program doing it all. More code doesn’t necessarily imply more resource usage.

Plan 9 is not an answer to every problem, but it's just impressive how much it can do with so little code.

I don’t want to be all around negative about plan 9, but I don’t see it as really solving any interesting problems. Indeed it is far easier to write slim, elegant systems when forgoing feature parity and/or competitive performance.

SubjectToChangeon Llama.cpp: Full CUDA GPU Acceleration

“Apple got bored of it when they decided Metal was the future. AMD got bored of it when they developed rocm and HIP”

Apple backed OpenCL because they needed an alternative after their divorce with Nvidia. No one was going to target an AMD alternative when they had such a trivial market share, so it had to be an open standard. Initially this arrangement was highly productive and OpenCL 1.x enjoyed terrific success. Vendors across compute markets piled support behind OpenCL and many even started actively participating in it. However this success is what precipitated the disastrous OpenCL 2.x series. In other words, OpenCL 2.x was far too revolutionary for many and far too conservative for others. What followed was Apple pulling out to pursue Metal, AMD having shoddy drivers, Nvidia all but ignoring it, and mobile chip vendors basically sticking to 1.2 and nothing more. Eventually this deadlock was fixed after OpenCL 3.0 walked back the changes of 2.x, but this was in large part because the backers of 2.x moved to SYCL.

As for AMD, OpenCL was a tremendous boon when it was first introduced. At least initially it gave them a fighting chance against CUDA. But it was never realistic for OpenCL to be a complete CUDA alternative. I mean, any standard that is basically “everything in CUDA and possibly more” is a standard no one could afford or bother to implement. ROCm and HIP are basically AMD using an API people are already familiar with software underneath to play to the strengths of their hardware.

“AMD are also the main competitor in the space but all but totally dropped support for GPGPU in desktop cards, trying to instead focus on gaming for Radeon and compute in MI/CDNA.”

Keep in mind that AMD has been under intense pressure to deliver world class HPC systems, and they managed to do so with ORNL Frontier. I don’t blame them for being selective with ROCm support because most of those product lines were in flight before ROCm started development in earnest. That said, Nvidia is obviously the clear leader for hardware support, as therefore the safest option for desktop users.

SubjectToChangeon Llama.cpp: Full CUDA GPU Acceleration

SYCL is still very early on in development and I don’t see it really picking up until support is up-streamed to the llvm project, at the very least. That said, I am a firm believer in the single source philosophy. There just isn’t a tractable alternative.

SubjectToChangeon Llama.cpp: Full CUDA GPU Acceleration

Chalking it up to “software incompetence” is a bit simplistic, to say the least. AMD was on the brink of bankruptcy not too long ago and their GPU division was struggling to even trend water. They didn’t have an alternative to CUDA because they couldn’t afford one and no one would use it anyway, OpenCL stagnated because most vendors didn’t want to implement functionality that only the biggest players wanted, and their graphics division had to pivot from optimizing for gaming (where they could sell) to optimizing for compute as well.

Now that AMD has the capital they are playing catch up to Nvidia. But it’s going to take time for their software to improve. Hiring at boat load of programmers all at once isn’t going to solve that.

SubjectToChangeon I use C when I believe in memory safety

Name a better plane. The F-35 is a great plane and its export success reflects that.

SubjectToChangeon I use C when I believe in memory safety

The behavior of malloc and free often isn’t explicit.

SubjectToChangeon I use C when I believe in memory safety

> As I said above .. there's no need for glibc et al.

Christ, I wrote it as an absurd notion in the first place. This is honestly like writing “go ahead and wear underwear on your head” only to have someone tell repeated tell you that isn’t necessary. Well, no shit.