HN user
That's the point of the challenge: "are there unknown properties of models allowing us to construct a poison for any network given enough input-output pairs".
The very point of CS as an academic discipline is _generalization_.
Linux the kernel is fundamentally inferior to NT from 30 years ago, Linux the userspace is barely tolerable, Linux as an ecosystem is an amateur clownshow barely held together by corporate donations of drivers and absolute dedication of a handful of volunteers of wildly differing skill.
If your biggest innovation of a decade is a carbon copy of a feature introduced in NT 3.5 in 1994 AND THEN it turns out most serious people disable it because you cannot even copy a feature without introducing new vulnerabilities - that's a sign of quality.
Sometimes having a good kernel matters more than having a good userspace.
That's... definitely a way to describe Sean Barrett, whose excellent libraries popularized this style.
Zero accountability. Which proves yet again that accountability is the final frontier.
That, uh, says a lot about Google, doesn't it?
Take a look at Github accounts of people pushing it, and you will see a clear pattern - it works, apparently, for a _very_ specific subset of people.
[flagged]
Why would I want to write a C++ parser?
IDL/DDL is the source of truth, moving the type definitions there is the whole point. There is only one definition for each type, which is in the *DL, corresponding C++ headers are generated and everything is statically known.
If you would check my comments, you would see I am quite aware. And no, it will not, just like it was with streams, ranges and whatever else.
Which problem would this solve for them?
Well, either you carefully vet which C++ features you use and my assumption still stands, or you don't - in which case I would rather not like to work in your company.
Which use cases? What exactly you can do with "existing metaprogramming facilities"?
Reframe it as "you can do precisely what you need by generating code" and there is your answer.
Which is far better than to rely on a party which, as I said, has precisely nothing to do with what anyone needs. Which will inevitably produce solutions that can only partially (I am being generous here) be used in any particular situation.
As for "possibly buggy" - look, I can whip up a solid *DL parser complete with a C++ code generator in what, a week? And then polish it from that.
The committee will work for several years, settle on a barely working design, then it will take some years to land in major compilers, then it will turn out it is unusable because someone forgot a key API or it was unfeasible on VAX or something like that.
And my build process is not complicated, and never will be. It can always accomodate another step. Mainly because I don't use CMake.
Whip up some kind of in-house IDL/DDL parser, codegen from that.
Which, precisely, additions do not fit my points?
It's the other way around. You are the real programmer and the committee and the "modern C++" crowd are more interested playing with legos instead of shipping actual software.
No way anything std::meta gets into serious production; too flexible in some ways, too inflexible in others, too much unpredictability, too high impact on compilation times - just like always with newer additions to the C++ standard. It takes one look at coding standards of real-world projects to see how irrelevant this stuff is.
And like always, the problem std::meta is purported to solve has been solved for years.
Sure, it took only what, 40 years of intensive hardware improvements* for assembly to move to the fringe? And we still reach out to it more often that I would like to because reasons?
Yep, I guess you can train an LLM on a bunch of binaries to get it to mimic a SotA compiler with some accuracy, which may or may not improve over time, but come on. Times where there were free performance increases are gone, and this is not the area where shipping any bullshit real fast will get you any sort of advantage.
* Which are unlikely to happen again in the foreseeable future.
Rust is - by design - antithetical to pretty much every idea of rapid application development paradigm Delphi/VCL and to lesser extent Qt adhere to.
It doesn't matter how many of Rust UI toolkits there are. Consider that there are a lot of Rust game engines, and pretty much zero games written in it, because even C++ gives you better trade-offs in that particular space.
LLVM is basically a resource pool for C++ compiler development. As such, it is highly C++ specific and leaks C++ semantics everywhere.
It's especially funny when this happens in Rust, which is marketed as a "safer" alternative.
Would you like a segfault out of nowhere in safe Rust? The issue is still open after two years by the way: https://github.com/rust-lang/rust/issues/107975
It seems the community is severely overexposed to bad practices and implementations of OOP and conversely severely underexposed to the success stories.
153 comments as of time of writing, let's see.
C-F: Java: 21 C++: 31 Python: 23 C#: 2
And yet: Pascal: 1 (!) Delphi: 0 VCL: 0 Winforms: 0 Ruby: 2 (in one comment)
This is not a serious conversation about merits of OOP or lack thereof, just like Casey's presentation is not a serious analysis - just a man venting his personal grudges.
I get that, it's completely justified - Java has a culture of horrible overengineering and C++ is, well, C++, the object model is not even the worst part of that mess. But still, it feels like there is a lack of voices of people for whom the concept works well.
People can and will write horrible atrocities in any language with any methodologies; there is at least one widely used "modern C++" ECS implementation built with STL for example (which itself speaks volumes), and there is a vast universe of completely unreadable FP-style TypeScript code out there written by people far too consumed by what they can do to stop for a second and think if they should.
I don't know why Casey chose this particular hill to die on, and I honestly don't care, but we as a community should at least be curious if there are better ways to do our jobs. Sadly, common sense seems to have given way to dogma these days.
That's one part of it, yes. A browser API providing a few GBs of persistent storage with proper isolation and user management, obviously with some kind of compression/decompression going on to save both download times and loading times.
As an example, consider Infinity Blade, the poster child of mobile gaming: released in 2010, 595 MB download, 948 MB installed. Even the first version of WebGL is capable of providing this kind of experience, we just cannot get it to the user via browser.
WebGPU is supposed to be properly sandboxed.
The bigger issue is that WebGPU is basically dead on arrival for the same reasons WebGL is - it is impossible to get enough data to the client for it to actually matter, Awwwards-style design tricks notwithstanding.
I suppose browser vendors understand this and don't really care for either.
Could you please tell what languages and technologies other teams use?
Comparison statements are meaningless if there's nothing to compare to.
Build confidence _and then_ just be yourself. Because if you lack confidence in yourself, how can you convince another person to have confidence in you?
Have you considred the bicameral mind hypothesis? Because what you are describing sounds like a strong evidence supporting it.
From someone who had been lonely for a better part of his life, there is a solution that works.
Build a bit of confidence (gym being the simplest way) and get out there, because whoever you are, there is someone else out there who looks precisely for you. But you aren't gonna meet them if you sit tight, so get out.
Internalize this: you are attractive and you have worth, right now. You are good enough. And someone is waiting for you out there.
And that answer is both wrong and actively harmful to people involved. But it sounds clever and insightful, so there's that.
Writing a book on a topic is an art unto itself. Even most technical books have a coherent narrative, carefully crafted to bring the reader from point A to point B.
If you want a quick reference on a well-known topic, then sure, use an LLM. Or a search engine. Chances are it will even answer you correctly (but also chances are it won't, and if it is a new topic for yourself - strap in, you're in for a ride).
But if you want to really understand something, then you will have to do your research, and a lot of this research has already been summarized into tangible artifacts optimized for your consumption which LLMs would never be able to replicate.
Even if you can convince one to regurgitate a book verbatim, the narrative thread would be lost unless you weave it yourself with your prompts - but would you, the learner, be able to do re-enact the narrative better or even on the same level than the original author who posessed the knowledge on the topic?
Even if this would be possible, it won't be idiomatic.
The argument is that Go is making a _wrong_ set of trade-offs.
It was designed, specifically, as per Rob Pike, for _bad_ developers. Developers who couldn't be productive at Google because they weren't properly taught at unis [0].
Then it caught momentum and then here we are, discussing a bad language designed for bad developers as if there is nothing better we can do with our lives.