Imagine if all the energy spent whining on the purity of a system being insufficiently private or decentralized or somehow loyal to a fight against the man, was spent instead on actually improving those systems. They're open source.
IIRC IPFS was the latest in a long line of Distributed Content-Addressed systems that long predate crypto. AFAICT (obviously I wasn't paying much attention) they went crypto (FileCoin) to fund a base population of storage users to bootstrap its popularity.
This is essentially guaranteed. There are lots of useful smaller models that we should be able to run locally. Over time they'll be more and more capable and require less API usage.
You're getting downvoted because your argument is cosmetic, egotistical, and useless. Can you give an objective separation between design flaws and engineering details? One that has zero ambiguity: if I give 100 engineers your criteria and then ask them to categorize 100 different points against it, would give exactly the same results? And would that distinction actually correlate to a historical analysis of programming languages' effects on software project success metrics?
No, because the entire distinction falls apart pretty quickly into "shit I like to discuss and care about" and "shit I don't care about and don't want to talk about."
Systems programming lives and dies by the details you want to ignore. The economics of large software production are mildly affected by language design. But weaknesses there are easily overcome with engineering practices and additional tooling. Almost every complaint about C++ safety I've ever heard hasn't been a problem for me for decades, because I know what libraries, practices, and tools solve those problems. But I've yet to work with another language - and I've programmed in a shit-ton of languages - that gets out of the way as well as C++ when I want to systems-program. Even C. C is strictly lower level, but its lack of abstraction facilities gets in the way more than some of the modern numerical-type-safety stuff of C++ does.
> You're getting downvoted because your argument is cosmetic, egotistical, and useless.
Ouch. (sincerely) I hate to think my ego might be so large and detailed that it could be so irritating to someone through such scarce writing. Are you certain you're identifying me correctly?
> if I give 100 engineers your criteria and then ask them to categorize 100 different points against it, would give exactly the same results?
Fair point, I understand that things I find to be "unnecessary friction" were once very necessary, and are (not infrequently) still necessary today.
> Systems programming lives and dies by the details you want to ignore.
I haven't really given you much to respond to, which is my fault, but I don't think you're yet identifying what I want to ignore, because how could you if I'm not specifying myself entirely? Frankly, I was being too casual with my discourse for many of the people responding to me, I see that now and graciously accept my downvotes. I'd rather have a good conversation than internet karma points, so here goes.
So let me box this in more. A lot of my students just want to get some practice with programming the computer. They want to learn some basic graphics, whether they're using the GPU or not. They want to be direct about programming the computer, and often want to use systems-languages but find C and C++ too difficult to use. It is now common for university students to complete a bachelor's degree while strictly writing Python. *This is the current against which I swim.* I do not think this is a healthy situation. I want there to be: more incentive for students to do "fine grained" (systems) programming. Ultimately, it needs to be more economically relevant _and_ to seem accessible to them. So, in my eyes, if enterprises attempt to use some of the "rounder" (less sharp) tooling *where possible*, students might think they've got a shot and can feel assured there's a point to putting in the effort to learn how to use things like pointers, allocators, profilers, debuggers etc.
I do not want C or C++ to die tomorrow, or next year, or next decade, but in my time writing these languages and their "successors" I do think there are enough meaningful improvements that we owe the next generation a chance to take ownership of something that seems a little less hairy-- even if it is so they can make it hairy and start anew. I simply want them to feel the responsibility and freedom of control.
So what are the improvements? Let's start with C. Let me preface by saying I am aware there are a few tools that are a "must" with C, otherwise you're going to get bit by things like integer conversions or memory corruption. Know your compiler-flags and tools like valgrind and you'll be okay. But what if you didn't have to learn that the hard way? Some of the new languages can put friction in the way of these mistakes, whether by way of incompatible numerical operations on mixed types, or various restrictions on what you can do with a pointer. These are small things, and I hesitate to list many more, but there are so many! I realize I won't be exhaustive enough for you, but we can take it further, sometimes bugs can be introduced via aggressive backend optimizations which operate on undefined/platform defined behavior. Again, in this case, there are languages which simply forego these optimizations by defining the behavior.
Again, I realize there are genuine losses due to these design decisions which I'm advocating for, and I appreciate the pressure you're placing against me to distinguish these from flaws. I don't mean to point at the inventors of the past and to say they just did it poorly, I simply believe the trade-offs are out of calibration now. e.g. C's pre-processor and linkage strategy is to write a bunch of little atomic things so that it all fits in memory. That is still crucial for a lot of the largest systems out there today, but for anything else PLEASE let me write something like `go run .` and be done (this is not an endorsement for Golang specifically.)
The point which inspired me to write any of this is this: the software we run could be faster and lighter if we know how to make it that way. I think C and C++ are good tools to make the absolute fastest and lightest software in a great many cases. Probably the best tools. But what about the people who just want to make a GUI application without learning the framework of the month, or the programming language of the decade? What if you want to know something you can use for the foreseeable future without investing the kind of energy it takes to be a discerning user of C or C++? We're missing out on better software because students are giving up on "finer" tools.
I've tried it, and no. Honestly C++ gets so many complaints partially because so many people use it. It deserves a lot of it.
I just finished my work on a 2.5 yr rust project that was very low-level. The problems I had with it were that the language and library designs will always be behind the current state of the art in performance. Hardware and systems APIs change quickly, and they can shift the optimal design decisions easily for different workloads. E.g. chiplets on your CPUs can change where you want to put your io_urings, their workers, and any relevant sq_poll threads. Your NIC's DMA/TLS facilities can change your memory pool policies - do you want zero-copy APIs, or is the copy required anyways because of all the CPU-local work you have to do? Do you preallocate and feed giant buffers to register with the io_uring, or do you need to share your memory pool with the rest of the application? Do you use a single mutex for the pool, a hierarchy between thread-local and global? Do you also use a chiplet-local allocator?
What's nice about C++ is that your fight isn't against the language and runtime. They don't care what your situation is. They'll work. You do have to assemble it, and other languages make some assemblies a lot easier to do.
Yes Rust and its libraries are getting better. But so's C++.
On embedded, your fight totally is against language and runtime. Since you cannot gave conformant freestanding C++ without exceptions, rtti and most of STL, "using c++" on embedded always turns into "using gcc" or "using clang" — their mutually compatible, but completely standards non-conformant extensions that make writing for embedded reasonable to even attempt. At that point, is the language still c++?
Meanwhile, both rust and zig will gladly compile your standalone function into standalone binary.
Nope. Vim and Neovim users can use the cusor-agent cli for agentic stuff and there prefered editing tool for editing. All the major providers have a cli specific version these days. Probably because folks actually didn't want to actually use the cursor Gui and once Claude code came along those folks jumped ship and went full cli again
