For uninitialized memory reads, which is one of the biggest classes of issues, valgrind can still be invaluable. MSAN is one of the more difficult things to get setup and remove all the false positives. You typically need to transitively compile everything including dependencies, or annotate/hint lots of things to get the signal-to-noise ratio right. Sometimes its just easier/better/faster to run it under valgrind.
That's the athletic department as a whole. At my alma mater, which is on that list as one where the athletics department costs 500-1000 per student, our football team (which is consistently mediocre) and basketball team were, as far as I know, profitable, and subsidized other D1 sports. I believe that cost also covers the funding for things like intramural sports, the student athletics complex (gym), and various other athletics adjacent things that are student-services shaped, and not D1-sports shaped.
I struggle to resonate with what you are saying, as my experience is the opposite. I'm curious where this discrepancy is rooted. Reckless hypothesis: are you working on majority latency or majority throughput sensitive systems?
I have seen so, so, so many examples of systems where latencies, including and especially tail latencies, end up mattering substantially and where java becomes a major liability.
In my experience, actually, carefully controlling things like p99 latency is actually the most important reason C++ is preferred rather than the more vaguely specified "performance".
The specific example that comes to mind was translating a Java application doing similarity search on a large dataset into fairly naive Rust doing the same. Throughput I guess. It may be possible to optimize Rust to get there but it’s also possible to (and in this case did) end up with less understandable code that runs at 30% the speed.
Edit: And probably for that specific example it’d be best to go all the way to some optimized library like FAISS, so maybe C++ still wins?
I've seen C++ systems that are considerably slower than equivalent Java systems, despite the lack of stack allocation and boxing in Java. It's mostly throughput, malloc is slow, the C++ smart pointers cause memory barriers and the heap fragments. Memory management for complex applications is hard and the GC often gives better results.
I've seen so may flat profiles due to shared_ptr. Rust has done a lot of things right but one thing it really did well was putting a decent amount of friction into std::sync::Arc<T>(and offering std::rc::Rc<T> when you don't want atomics!) vs &mut T or even Box<T>. Everyone reaches for shared_ptr when 99% of the time unique_ptr is the correct option.
I see comments like yours more than I see anyone suggesting actually using shared_ptr widely. In my experience, most people (that use smart pointers - many do not) prefer to use unique_ptr where they can.
I don't think anyone is suggesting shared_ptr explicitly, more that if you're coming from Python/Java/etc it's a similar to a GC memory model and a bit more familiar if that's where your experience is. I've observed in a number of codebases unless you're setting a standard of unique_ptr by default it's fairly easy for shared_ptr to become widely used.
FWIW I consider shared_ptr a bit of a code-smell that you don't have your ownership model well understood, there are cases to use it but 90% of the time you can eliminate it with a more explicit design(and avoid chances of leaks + penalties from atomics).
Bear in mind that my ultimate perspective is that you shouldn't use smart pointers (or C++) at all.
But even if you think they have some value, it isn't a flaw in a language if it's not immediately obvious how to write code in it for people that are new to it. If you're coming from Python or Java, then learn how to write C++. There are probably as many books on C++ as on any other language out there.
Badly written C++ will be as slow as well written Java. Absolutely. But there is no way any Java code will perform better than well optimised C++. High performance C++ use custom allocators to completely avoid using malloc (for example).
From my experience with embedded coding you are correct. Most stuff lives and dies enclosed in a single call chain and isn't subject to spooky action at a distance. And stuff that is I often firewall it behind a well tested API.
I agree entirely with the premise here save one subtle bit at the start. I think there is grave danger in reducing "vector database" to "vector search" as equivalent domains and/or pieces of software. I would argue that for "vector databases" there's alot more "database" problems than "vector" problems to be solved.
I fear there's going to be alot of homerolled "vector search" infra that accidentally wanders into an ocean of database problems.
> I would argue that for "vector databases" there's alot more "database" problems than "vector" problems to be solved.
Why the need for new technologies then? Databases are well studied. Vector search is relatively easy to implement. Sure, there are some new insights to be gained by respecting a hybrid approach - but they are clearly overvalued.
Machine learning is supposed to make things easier. If you implement vector search across your company's data, there's no reason a LLM couldn't simply do the various SQL-style operations on chunks of that data retrieved via KNN. I'm not aware of this approach being used in practice - but I still think the obvious direction we are heading towards is to be able to talk to computers in plain english, not SQL or some other relational algebra framework.
It's much easier to start from a database and add vector search as one of the features, then to go backwards. We have spent 7.5 years on the DBMS part, while the vector search can literally be added in a week...
And that's why every major modern database is now integrating such solutions :)
The only reason you and others seem so desperate to redefine bailout so you can call it a bailout is because you want to attach the negative connotations to that word to “hurt” the people you want to be hurt.
We should be clear... in these large organizations... HEAD is always broken. But it has the advantage of being broken for everyone, tested by everyone, fixed by everyone, and thus fixed for everyone. And this usually makes it far better than the alternatives.
Having 1000 dependencies with versions pinned means you are living alone and will run into fewer issues, but when they do come, they will be absolute nightmares that no one else is dealing with and no one can help with. And one day you'll have to do the game of begging someone else to upgrade their version of a downstream thing to fix the issue, and they won't, so you'll try to get the other group to backport the fix in their thing to the version you can't upgrade off. And they won't. etc. etc.
Full versioning is the worst of all approaches, IMO, for large complex interconnected codebases (especially ones that are many-to-many from libraries to output binaries) but it absolutely is sometimes the only viable one (for example, the entire open-source-ecosystem is a giant(er) version of this problem, and in that space, versioning is the only thing that I can imagine working).
Supply chain attacks are worsened if everyone lives at the head. Staying far enough behind that some brave (and hopefully small) project discovers the compromise of a repo for some dependency five layers deep before you re-pin to a new version is probably the best mitigation short of some permissions based model like Austral is working on.
C++ doesn't have the same kind of head as you are thinking. The standard gets pretty well-tested before being standardized as the most recent ("head") version. C++'s head gets more testing than most libraries ever get for any version.
Anyone with proper experience on C++ ecosystem knows this isn't the case.
Not only is ISO full of DR and things that probably shouldn't have been standardized in first place (thankfully some of them were latter removed), there is plethora of compilers to chose from.
Those three compilers don't work everywhere, aren't allowed everywhere, and mostly works isn't "The standard gets pretty well-tested before being standardized as the most recent".
How were GC API, auto_ptr, modules, concepts and co-routines pretty well tested?
In those three compilers they surely weren't, so in which ones?
Most people are using more than one compiler at the same time. For instance, MSVC plus some combination of clang-based tooling for static analysis and/or local dev.
And folks using a full stack of MS tooling are probably using the EDG compiler as an implementation detail for IntelliSense support.
Yeah everyone seemed to have atarted talking about living at head in general. My concerns about living at head for c++ is primarily compiler and static analysis support. I like my pipeline to build for clang and gcc and run unit tests in both clang tidy modernize, gcov, cppcheck asan etc.
By the time all of that is supported for a language release we are on the next one, and I value that pipelene more than the changes currently being made.
The flip side is that exposure to software vulnerabilities is lengthened if people stay on older versions. So, you’ll be less vulnerable to intentional bugs in the software, but more vulnerable to unintentional bugs - and the latter are far more likely in practice.
Granted, the former can be quite a bit more severe - but that’s why we should do things like build on dedicated servers with restricted access to the internet etc.
There are older versions (no new features) and then there are older versions (no security updates). Most security updates don't break compatibility and can be installed without modifying anything that takes that version as a dependency.
This works as long as compatiblity-breaking changes are kept rare so that you can feasibly have someone doing security updates for each of the incompatible versions.
That was my thinking. In Austral that is a thing, but in c++ not so much. And if you are building the dependency from source, which is pretty common, the common build systems are all Turing complete themselves so they can take over your pipeline and do bad things.
Run your CI in an allow listed only network and only allow access to either your private, security scanned, mirror or else keep well trusted things. Even if a bitcoin miner gets into the stack it can’t send the results to the source so it is less dangerous.
But it can insert itself in your pipeline so that anyone who depends on you is also infected. We have already seen CI worms for thevlack of a better term. One was briefly spreading in crates.io early last year as part of the "crate depression" thing.
> We should be clear... in these large organizations... HEAD is always broken.
I don't know about all of them, but a lot of them have CI set up such that HEAD is never broken for some definition of broken.
Practically speaking it's basically impossible to fuzz test everything, but typically builds and reasonably fast and reliable tests are run before HEAD includes new changes.
Being efficient about supporting this workflow is more or less what monorepo build systems like bazel, buck, and pants were designed for.
> it has the advantage of being broken for everyone, tested by everyone, fixed by everyone
The correct word here is not advantage but risk.
While making a product you rely on something, some other product/package. Thousand of them if you are unlucky. If you have 1000 packages to collaborate in the development/testing/QA of them you will do nothing else! Also try building a house on a concrete that is still maturing, with tools not ready yet, I dare you! Careful developers rely on reliable things. It is a shame in this industry this is not available. Either released(!) things are not ready yet, or are in demise already, the sweet spot is tiny.
It depends on the context: in a React Native project you are almost guaranteed to realize the hard way that you depend on abandonware that won't ever support the latest React Native version or the latest smartphone operating systems, while in a Python project you are almost guaranteed to attempt to use something that is hard to install or compile, or just doesn't work on your slightly divergent platform (e.g. Windows).
FWIW, I joined HN 14 years ago (wow) and there's never been a time in those 14 years that HN wasn't convinced that facebook's demise was just around the corner.
This is true, but the main reason was that people have been predicting this was that young people don’t want to be on a social network with their parents. This social dynamic prediction has played out, and Facebook did the 100% predictable thing that all rich entrenched players do — they bought the smaller competitors, most famously Instagram.
I fully expect them to continue to be able to monetize their user base, and purchase smaller competitors for a while.
The most recent warning flag for me is their rebranding. Announcing a major pivot to center on Occulus (I’m sorry “the metaverse”.), when VR has been nothing more than niche gaming is very weird and troublesome.
On the bright side, Facebook is a giant ossified megacorp. All that’s going to happen is some division is going to get new signage, and every PM is going to update their slide decks to say “metaverse”, and everyone is going to do what they were already doing.
As an ex-employee, Facebook is many things, but ossified it is not. The internal impact/metric-oriented culture means that new bets are encouraged and rewarded, whereas product teams that are keeping it safe will eventually get disbanded.
FB’s predilection to reorg every six months, isn’t a sign of strength. It’s actually a sign of dysfunction. They’ve just been able to power through by being extraordinarily lucky in the social networking space. It’s tire spinning.
The company hasn’t released a noteworthy product in at least a decade.
I joined HN 12 years ago and I don't remember things that way at all. My impression is that it's extremely rare for anyone to claim that FB's demise is imminent, but it seems like it has become more common for HN posters to comment on FB's decline in recent years. ...but you could say the same thing for Apple, Amazon, Netflix, and Google as well -- it doesn't seem to be FB specific to me.
MySpace died because it became a minority player in a quickly growing landscape, at a time where alternatives were available.
To simplify, if you have captured over 50 percent of the entire english-speaking Internet population, sure you have a huge network effect behind you. But if that population count is multiplied by 100x and your numbers don't grow alongside that, your network effect is not as strong.
My wife was working there at their peak (and left at just the right time—I like to think that their decline was the inevitable result of her departure). They had such high engagement that they had a hard time selling enough ads to fill all the available ad slots.
Including my ex-account period I have been reading HN for 12 years now, while I agree Facebook has always been unpopular on HN. It was since may be 2015 it became extremely one sided. Even the very rare few who speak up with Facebook financial and user growth are all gone. ( Arguably speaking lots of things on HN have become one sided )
There is this phenomenon I witness time and time again, people confuse what they wish to happen; the decline or death of Facebook with any real facts.
It is like saying Apple is doomed for 10 years and yet Apple is now a 3 trillion company.
> they seem to be advocating for some sort of dualism.
This paper is doing the opposite. It's arguing that other papers/ideas advocating dualism are going the wrong way and purely physicalist explanations are the best path forward.
Purely materialist explanations, you mean? Platonic dualism, as advocated by folks like Max Tegmark, isn't non-physicalist. And it needn't be dualist even — if the world is made of math and the materials emerge by implication.
What does it mean to be "made of math"? This reads like gibberish to me. Mathematics deals with formal abstraction. Geometry, for example, abstracts the spacial characteristics of matter from matter and focuses on them solely while ignoring everything else. (This actually reminds me of Bertrand Russell's structuralist account of physics and how it omits much if not most of reality.)
(Also, Platonism does posit an immaterial realm of the forms in which all material things participate. But this participation relation is problematic, something Aristotle pointed out in the Third Man Argument and something Plato himself knew.)
1. The laws of physics at the time scales, space scales, and energies of the human brain are "known" and we have deep reasons to believe that more will not be discovered. He spends a great deal of space explaining and arguing that the credence that physics is "complete" in this regime should be very, very high.
2. Given the current laws of physics, there is no place or room for non-physicalist explanations of consciousness (or, I suppose, for other dualist ideas like a soul) because there is no mechanism for them to effect change in the physical world.
3. Anyone who wants a non-physicalist approach to consciousness must either claim they can violate the laws of physics in our brains, or cannot affect the physical world.
> Anyone who wants a non-physicalist approach to consciousness must either claim they can violate the laws of physics in our brains, or cannot affect the physical world.
There is a strand in (an obscure corner of) Buddhism that maintains that:
- The fundamental "substance" in the Universe is awareness.
- Awareness creates the body and the sense organs.
- Awareness projects the external world through the sense organs.
In this model, there is no claim that consciousness violates "the laws of physics". It just disputes that the physical world is fundamental. And this model certainly doesn't ban consciousness from affecting the physical world (that it created).
I don't believe for a moment that this model was meant to explain things, like a scientific explanation; it's meant to present a "view" (a way of looking at experience) that is helpful to meditators. It's very much the opposite of the instinctive way of interpreting experience. In part, it's meant to disrupt pre-conceived notions about experience - so it's also meant as a challenge.
How does free will play into this? If the world is run by all physical laws, then I had no choice typing this out and submitting it, rather then closing the tab right now.
My "decision" isn't real.
If it is an actual conscious choice, that was not calculatable by the exact state prior, then consciousness is fundamental.
One possibility is that from an omniscient perspective, free will is indeed meaningless.
But then again it can be argued that everything would be meaningless from an omniscient perspective: time, space, matter, energy, freedom, love, whatever
That is unless there is some sort of actual absolute meaning to the universe, which is a very boring and treacherous line of reasoning that i won't entertain here
However he existence of an omniscient entity would completely break physics as we know it so any physicalist/rationalist approch to understanding the universe can fairly safely rule it out
Free will may exist as a result of the unknown factors of human consciousness, their actions and consequences and their relations to the physicial world.
Personally I find that thought quite pleasant, because it means that free will does exist from a human perspective, and I happen to posess one of those.
You had the choice because all the processes that determine your actions happened in your brain, which is a part of you: you are not a puppet controlled from outside.
What is your conception of free will? Is it just "randomness"?
If your actions are not determined by your thoughts and desires .. then they would just be completely random. How is that "free" will?
My conclusion after a good amount of reading and thinking on this:
Free will, defined as autonomous decision-making partially influenced/affected by the external environment, does exist.
Now 'autonomous' = determined by the agent, i.e. the decision to have pizza today is determined by something in you, not fully determined externally, but that something is likely not your conscious experience.
In that sense, free will does not exist.
But that does *not* mean that everything you do is predictable because P!=NP. Even God, if s/he exists, does not yet know what you will do tomorrow, s/he's waiting to find out.
So: you are not free, but you are not bound to something either.
A decision is a situation in which you did one thing but could have imagined doing something else. It is a necessary concept due to human uncertainty about what will happen in the world -- including our own behavior.
We will never be able to perfectly calculate the causal chains of the universe before they unfold, so we operate in a world of uncertain chances and maybes.
I recommend reading "Elbow Room: the varieties of free will worth wanting" by Daniel Dennett to get a better handle on what the term "free will" might actually mean.
It depends what you mean by free will. Non-philosphers almost always mean "libertarian" free will when they say that, and yes, this same argument also basically outlaws libertarian free will as well. There is no physical mechanism by which you can alter your brain physics to "choose" things.
Carroll and others have a compatibilist notion of free will which is a more subtle concept that I'm not sure I'm qualified to actually explain.
I remember once upon a time being pretty interested in understanding "what is consciousness". The more I have learned about neuroscience, the more plausible it seems that what we know as subjective experience is just an emergent behavior of this super complex lump of jelly in our heads. If you look at what the thalamus does, it seems like consciousness might even just basically be the function of that brain region.
