hyperpape

80% of what? There are 85,000 H1B visas per year, and vastly more job postings (and hirings of citizens) each year.

I don't think AI is the cause, but it was a hell of a lot stronger 3-4 years ago.

Regarding silly configurations: https://danluu.com/googlebot-monopoly/.

> There has been a surprising amount of scientific research around this issue

This article includes a throwaway link to the wikipedia page at the end of that quote. I recommend reading the relevant section (https://en.wikipedia.org/wiki/Line_length#Electronic_text), because it's pretty limited. There is really no way to tell if it (or Glyph) are accurately summarizing the research.

Maybe, but even if true, it's still very clearly different from what the parent said.

To me, "I"m gonna try and fix it before I buy a new one, but that's probably what I'm gonna have to do" is a fine sentence.

That's not what "try and" means though. It's perfectly fine to say "I'm gonna try and fix this" when you don't know if you can fix it.

(Source: I say that shit all the time).

I think the difference is that since libraries do not specify version ranges, you must manually override their choices to find a compatible set of dependencies.

The solution is version ranges, but this then necessitates lockfiles, to avoid the problem of uncontrolled upgrades.

That said, there's an option that uses version ranges, and avoids nondeterminism without lockfiles: https://matklad.github.io/2024/12/24/minimal-version-selecti....

Note: maven technically allows version ranges, but they're rarely used.

I think Maven's approach is functionally lock-files with worse ergonomics. You can only use the dependency from the libraries you use, but you're waiting for those libraries to update.

As an escape hatch, you end up doing a lot of exclusions and overrides, basically creating a lockfile smeared over your pom.

P.S. Sadly, I think enough people have left Twitter that it's never going to be what it was again.

> But if you want an existence proof: Maven. The Java library ecosystem has been going strong for 20 years, and during that time not once have we needed a lockfile. And we are pulling hundreds of libraries just to log two lines of text, so it is actively used at scale.

Maven, by default, does not check your transitive dependencies for version conflicts. To do that, you need a frustrating plugin that produces much worse error messages than NPM does: https://ourcraft.wordpress.com/2016/08/22/how-to-read-maven-....

How does Maven resolve dependencies when two libraries pull in different versions? It does something insane. https://maven.apache.org/guides/introduction/introduction-to....

Do not pretend, for even half a second, that dependency resolution is not hell in maven (though I do like that packages are namespaced by creators, npm shoulda stolen that).

This is useful, though it leaves open the question of what it means in practice that the grant-making organization is disappearing.

You're right to distinguish imitation from simulation. That's a good distinction and I think the paper is discussing imitation--using similar learning algorithms to what the brain uses, fed with realistic data from input devices. But my point still stands with imitation.

> This paper outlines the case for believing that we will have superhuman artificial intelligence within the first third of the next century. It looks at different estimates of the processing power of the human brain; how long it will take until computer hardware achieve a similar performance; ways of creating the software through bottom-up approaches like the one used by biological brains; how difficult it will be for neuroscience figure out enough about how brains work to make this approach work; and how fast we can expect superintelligence to be developed once there is human-level artificial intelligence.

The paper very clearly suggests an estimate of the required hardware power for a particular strategy of imitating the brain. And it very clearly predicts we will achieve superintelligence by 2033.

If that strategy is a non-starter, which it is for the foreseeable future, then the hardware estimate is irrelevant, because the strategies we have available to us may require orders of magnitude more computing power (or even may simply fail to work with any amount of computing power).

The entire discussion in the software section is about simulating the brain.

> Creating superintelligence through imitating the functioning of the human brain requires two more things in addition to appropriate learning rules (and sufficiently powerful hardware): it requires having an adequate initial architecture and providing a rich flux of sensory input.

> The latter prerequisite is easily provided even with present technology. Using video cameras, microphones and tactile sensors, it is possible to ensure a steady flow of real-world information to the artificial neural network. An interactive element could be arranged by connecting the system to robot limbs and a speaker.

> Developing an adequate initial network structure is a more serious problem. It might turn out to be necessary to do a considerable amount of hand-coding in order to get the cortical architecture right. In biological organisms, the brain does not start out at birth as a homogenous tabula rasa; it has an initial structure that is coded genetically. Neuroscience cannot, at its present stage, say exactly what this structure is or how much of it needs to be preserved in a simulation that is eventually to match the cognitive competencies of a human adult. One way for it to be unexpectedly difficult to achieve human-level AI through the neural network approach would be if it turned out that the human brain relies on a colossal amount of genetic hardwiring, so that each cognitive function depends on a unique and hopelessly complicated inborn architecture, acquired over aeons in the evolutionary learning process of our species.

It's wild how far off these predictions are, and yet there are still people to take them seriously.

No matter how impressive you find current LLMs, even if you're the sort of billionaire who predicts AGI before the end of 2025[0], the mechanism that Bostrom describes in this article is completely irrelevant.

We haven't figured out how to simulate human brains in a way that could create AI and we're not anywhere close, we've just done something entirely different.

[0] Yes, I too think most of this is cynical salesmanship, not honest foolishness.

> While there have been improvements, Java performance work seems to have stopped after 2011 or so.

No idea how you got that impression. Here is an incomplete set of important changes:

- major developments on Graal and native code compilation for applications that prioritize startup time and memory use (I think Graal was started before 2011, but has changed a huge amount since then).

- the concurrent G1 garbage collector became the default, making most applications have much lower pause times (I believe it was released in Java 7 in 2011, but was not mature, only became a default in Java 9, and has regular improvements since then).

- the Shenendoah and ZGC concurrent garbage collectors were not started until well after 2011

- project lilliput, which reduces the header size of Java objects from 16 to 8 bytes is landing in Java 25, which comes out this fall

- specializing strings to use 1 byte/character for ascii strings, and 2 bytes for non-ascii strings

- virtual threads shipped in Java 22

- work on a vectorization API

- plenty of work on reducing the startup time of the JDK and modularizing it

One where I'm not sure about the timeline:

- https://docs.oracle.com/javase/8/docs/technotes/guides/vm/cl... class data sharing to lower overhead of running multiple JVMs on a single node

P.S. I'm not writing this to comment on the the parent's claim that Java is faster in some contexts.

So, it seems like there is some kind of national variance here? Bolt works well in Portugal, I've used it in Porto, Lisbon, and even Caldas da Rainha (smallish town an hour north of Lisbon). All told, we've taken more than a dozen trips, I think.

- Someone else says it's good in Portugal https://news.ycombinator.com/item?id=44640459

- Someone says Malta is good, France is bad: https://news.ycombinator.com/item?id=44640424

- Someone says Northern Europe is fine: https://news.ycombinator.com/item?id=44640369

- Another saying Denmark is fine: https://news.ycombinator.com/item?id=44640111

There's a pretty big gap between "its JIT research eventually became Hotspot" and "Smalltalk can be made to perform on a par with Hotspot."

> Moores law is dead Amdahl's law

Yes, but the OP specifically is talking about CI for large numbers of pull requests, which should be very parallelizable (I can imagine exceptions, but only with anti-patterns, e.g. if your test pipeline makes some kind of requests to something that itself isn't scalable).

I can't speak to every European country, but Portugal also has a lot fewer stop signs and traffic lights than the US (roundabouts are one reason, but there are multiple four-way intersections on my street that would have stop signs in the US).

Given the way American streets are set up, rigorously enforcing stop signs is probably beneficial, but I think other factors about how streets are arranged and how people drive are more important.

> But English orthography isn't meant to serve foreigners.

Or natives. It is slower for children to learn to read English than other languages.

> databases are complicated beasts and tens of thousands if not more working years of the smartest people have been working on them since the 70s

Yes, but they've also set themselves a much harder problem. Instead of "find the proper execution for this particular query, armed with all the knowledge of the database you have" they have the problem of "find the proper execution for all possible queries, using only information that's encoded in DB statistics."

So it's no surprise that it's quite easy to find places the optimizer does silly things. To take one instance that bit me recently: or clauses representing different tables cannot be optimized well at all in postgres (https://www.cybertec-postgresql.com/en/avoid-or-for-better-p...).

I'd still rather have optimizers than not--the optimizer does well most of the time, and my current work has far too many queries to hand-optimize. But you do end up seeing a lot of poorly optimized queries.

I agree most working mathematicians have limited interest in foundational topics. To me, that seems harmless enough.

> approximate those aspects of physical reality that are primarily relevant to the endeavors of humanity.

This is the comment that made me think that you were saying we needed more work on foundations for math as it is used in the sciences, and that doesn't match my understanding. Did I read it differently than you meant it?

This ignores the fact that it is not so easy to find natural interesting statements that are independent of ZFC.

Statements that are independent of ZFC are a dime a dozen when doing foundations of mathematics, but they're not so common in many other areas of math. Harvey Friedman has done interesting work on finding "natural" statements that are independent of ZFC, but there's dispute about how natural they are. https://mathoverflow.net/questions/1924/what-are-some-reason...

In fact, it turns out that a huge amount of mathematics does not even require set theory, it is just a habit for mathematicians to work in set theory. https://en.wikipedia.org/wiki/Reverse_mathematics.

The maintainers are probably all making personally reasonable choices that we should support.

But it’s still sad that there’s probably no world where someone will still focus on jemalloc with professional support from their employer. It means that an important piece of technology will not continue improving.

Forking is possible, but it doesn’t look like the kind of project that many people could fork and improve, it requires a lot of focus by people with specific domain knowledge.

That said, the important question isn't "can the model experience being shutdown" but "can the model react to the possibility of being shutdown by sabotaging that effort and/or harming people?"

(I don't think we're there, but as a matter of principle, I don't care about what the model feels, I care what it does).

It's weird that the author is bothered by the concept of waste being applied to software, because when people talk about waste in software development, one of the main forms of waste is inventory: the effort put into building software that has not yet been used.

Or, in the article's terms, things you've built but have yet to receive the feedback "that's shit" so that they can be iterated on.

Right, which is why it's extremely confusing that the author wrote:

> In this case, you could work just one ten-hour shift per week, and in so doing, earn more than 30% of what you need to live well at this particular house with just four days of work per month.

What he probably did was write that one shift is more than 30% of what you need, then switched gears to write about four days of work per month, but forgot to remove the 30% number.

Huh? My in-laws came from industrial maintenance/construction companies in rural North Carolina. They vote for Trump, majority of them go to Southern Baptist churches. I spent two years living out there and working for one of their industrial maintenance companies.

This is not what they aspire to, or what 95% percent of the people living there aspire to.

Sure, the fishing sounds good, and the country living, but living without a car? No TV? Never eating out? That's weird, man.

This guy's life is no more representative of how most people in red states live than any blue state office worker who idly talks about going to live on a commune is representative of how people in NYC live.

Sure, lots of folks from any culture have a dream of getting back to the simple life. But it's an idle fantasy for almost everyone.

The author makes a big deal out of not having a car, and the math gets a heck of a lot worse if you add a truck.

I think you've arguably left out some interesting options in the middle.

Honestly, this is the weirdest way the author could've written that sentence.

He should've said either "one 10 hour shift per month will make 30% of what you need to live here" or even "one 10 hour shift per week will make more than what you need to live here."