leapis

Decades of speculative science fiction, thought experiments, and discourse led to this. It’s gratifying to see that we’ve garnered enough concern, a major AI lab risking this to reign in the potential of runaway AI disasters. Hopefully we see other labs follow.

Is there a point at which library maintainer feedback would meaningfully influence a by-default JVM change?

I keep a large production Java codebase and its deployments up-to-date. Short of upstreaming fixes to every major dependency, the only feasible way to continue upgrading JDK/JVM versions has often been to carry explicit exceptions to new defaults.

JPMS is a good example: --add-opens still remains valuable today for important infra like Hadoop, Spark, and Netty. If other, even more core projects (e.g. Arrow) hadn't modernized, the exceptions would be even more prolific.

If libraries so heavily depended upon like Mockito are unable to offer a viable alternative in response to JEP 451, my reaction would be to re-enable dynamic agent attachment rather than re-architect many years of test suites. I can't speak for others, but if this reaction holds broadly it would seem to defeat the point of by-default changes.

Why on earth would you bet your money on some random tool you don't even understand? ... I built a tool for people who knew what harmonic patterns were.

The tool is for drawing "technical analysis indicators", one of the most convoluted ways to ascribe meaning to a random process and something that will only ever be true in the self-fulfilling sense. I don't think it's a surprise that some users are willing to blindly trust the tool, when all users of it are blindly trusting concepts that are built on sand.

Although I'm sure the author is burnt out from the experience now, I'd be interested in hearing how their next side project venture goes- is the experience more enjoyable when you're dealing with a user base that self-selects differently? Or do all users suck equally, just in different ways?

Agreed- I come from a Java/C++ shop where we tried to tackle this dichotomy with interop but it ended up causing more problems than it solved. A lot of the work that Java has done with modern garbage collectors is impressive, but even they admit (indirectly, via Valhalla) that no/low-alloc code has it's place.

I mostly agree with this, but I've been a big fan of having primitive types in config. Most of the time if I have something I want to configure, it's either one of the following (or a map/list-based structure consisting of):

- scalar value

- feature toggle

- URI/enum option/human readable display text

Having float/long/boolean is trivial to validate in the config language itself, and if they're useful and simple enough isn't it nice to be able to validate your config as early as possible?

Yup. We've clearly benefitted- G1 and generational ZGC have large advantages over CMS- but it's a lot of experimentation and trial-and-error to get there, whereas other deprecations/removals are usually easier to resolve.

Nullable is a huge issue in Java, but annotation-based nullability frameworks are both effective and pervasive in the ecosystem (and almost mandatory, IMO).

I'm really excited about https://jspecify.dev/, which is an effort by Google, Meta, Microsoft, etc to standardize annotations, starting with @Nullable.

Depends- one of the hardest parts of the 11-20 upgrade for us was that cms gc was removed.

If you run a bunch of different microservices with distinct allocation profiles, all with high allocation pressure and performance constraints, and you've accomplished this w/ the help of a very fine-tuned CMS setup, migrating that over to G1/ZGC is non-trivial

The re

There might be a potential market in HFT/trading firms (market makers). They're struggling to recruit right now (industry is doing very well, so high headcount growth) and they're usually pretty small so joining w/ friends means working in closer proximity than you might get in big tech.

Their small class size and heavy new-grad hiring also means that they're usually more flexible with recruiting and some would probably welcome a new pipeline for talented new grads like this.

Is this a theoretical difference, or a difference in terms of an actual implementation? I have no knowledge of linear systems algorithms, but as far as I was aware, many w.h.p algorithms resolve to correctness with probability of 1 - (1/n)^c (with c effectively being a hyperparameter), which would seem like quite a strong result in itself.

“Of the 18 crossovers I talked to, 16 said yes.“

I’m just as surprised to see the number be this high. I can’t help but wonder if this might be due to survivorship bias: crossovers are, after all, self-selecting. Perhaps not all engineers would say the same, if forced to swap roles.

Regardless, I’m excited to hear more from these crossovers. As a (soon-to-be) recent graduate, I think there can tend to be a great difference in perception between CS students and Engineering students, particularly at institutions without rigorous CS programs. Many tend to view CS students in the same way that some CS students view bootcamp students- people motivated by an “easy path to success”. I’ve found this opinion is rarely held of engineering students, given the reputation of engineering programs. I think it’s very useful to profile the motivators, mindsets, and general attitudes between the disciplines, if only to see that perhaps the difference isn’t as large as one might assume.

How do you achieve people like this? From my limited experience (college senior joining a hft firm shortly, so I've recently been in several quant finance SWE interview loops), firms seem to vastly downplay the financial aspects of the job for software engineers. Compounded on top of that, firms don't expect or encourage financial backgrounds for engineers (at least new grads)- the expectation is that whatever limited financial background we'll need to work will be given to us when it becomes necessary.

Is this because it's easier (obviously) to teach a quant engineering than it is to teach an engineer quant finance? Or rather because it's expected now that traders will become the bridge between researcher models and implementation, and engineers will simply provide the underlying infrastructure to power these implementations?

Fantastic book, and one that's much needed in the landscape of compiler learning today. Many modern compiler books (such as Torczon & Cooper's "Engineering a Compiler") take the approach of showing low-level, linear IRs rather than actual assembly- a perfectly valid approach, to be sure, but one that leaves something to be desired. While compilers are interesting, I don't learn about them because I think I'll ever write a real one- I learn about them because I want to understand more about a tool at the core of my workflow. This book won't be the be-all end-all of understanding compilation to asm, especially on x86 machines, but it taught me much that my university compilers courses and the Dragon book could not. I was a little hesitant when I saw the book was written with Typescript in mind, but after reading an earlier draft I tend to agree with the author's assessment that it works well with the material, and isn't too hard to pick up with some limited javascript experience.

The way I've seen it calculated is this:

For regular classes, A: 4.0, B: 3.0, C: 2.0, D: 1.0 (with some variance depending on + or - grades offered). For Honors/AP classes, every grade is essentially bumped up 1.0 point.

So yes, a 3.74 is around an A- average, but that's an A- average in less rigorous classes, without competition from top students. That's more of a B-/C+ average in AP/Honors classes (obviously the calculation is far from perfect, though, because every school has it's quirks- at mine, you couldn't get above a ~4.5 overall). For reference, I graduated high school with a 3.6 with multiple Cs and hardly any As, simply by virtue of taking the maximum number of AP/Honors classes. The point being, a 3.74 is not a terrible GPA, but good students are generally over a 4.0 these days.

For probabilistic algorithms, we can look at the worst-case-w.h.p runtime: that is, a randomized quicksort, although technically still having an "absolute" worst case of O(n^2), actually is considered to have a worst case of O(nlog(n)), with probability 1 - 1 / (n^c) when bounded by Chernoff, as shown here: https://web.cs.hacettepe.edu.tr/~ozkahya/classes/bbm402/Lect...

On a local level, the FCC paved the way for chain-based ownership of local stations in 2003, despite research suggesting it was a bad idea[1]. That being said, the US media is different on a national level- NYT, WashPo and WSJ (investigative journalism dept, not editorial board) have shown in the past their ability to leak private government documents, take anti-government stances, and generally resist authority. While yes, WashPo is owned by Bezos, I view this differently than other cases of "an oligarch buying a newspaper". While I think we'll always need to be wary and cognizant of his ownership, it seems for now that he's bought the Post for the same reason that other billionaires get their names on schools and museum wings. I recently read Bad Blood (story of Theranos), and I was struck by how brazen the WSJ's investigative journalism department was at pursuing the story through legal threats, government stonewalling (eventually seeking out leakers), and the consequence of making their own editorial board look like fools. I think the US's journalistic integrity and freedom still stands yet.

[1] https://en.wikipedia.org/wiki/Media_cross-ownership_in_the_U...

The CD standard as the "Joe Average" is quickly changing. Anecdotally, as a younger person (recent college grad), people my age don't buy CDs out of necessity nearly as much anymore as they used to. We've gotten to the point where the vast majority of devices (car stereos, home systems, etc) have at the very least, an aux port. Adding on to this, the prevalence of phones as speakers and music players means that you hardly every "need" a CD. CDs are quickly going the way of records and cassettes.

We can see this pretty clearly looking at consumer reports[1], where you'll find that vinyls, compared to CDs, are actually being propped up largely by generations (18-44) that never properly experienced them. CD usage, on the other hand, is generally supported by older generations that are slower to adapt to modern streaming. Vinyl is almost vicarious nostalgia- most vinyl users I know (generally from the same age bracket) enjoy it as a deprecated technology that feels exotic. CDs aren't necessary for us anymore, and since we grew up with them, they aren't as enchanting and romanticized as vinyl.

[1] http://www.riaa.com/wp-content/uploads/2019/05/MusicWatch-Co...

I think the idea is supposed to be that you have some agency when you share your data with a friend. You can choose whether you want to entrust your data to this friend or not, and the onus is on you to properly vet them for transparency and trustworthiness. Conversely, if a stranger leaks your data, that isn't on you at all (beyond you allowing the stranger access to your data, but that's stretching the metaphor a bit). I don't find this argument particularly compelling though, because the typical Facebook user definitely didn't know what they were getting into when they signed up years ago. I find it hard to fault people for improperly vetting entities that are beyond their area of expertise, and I don't think this mistake on the user's part makes Facebook's practices any less egregious.

I would help my neighbor move some furniture for free, and I'd still do it if he offered to pay me $5. I wouldn't accept the money (because it's socially unacceptable to do so), but his offer wouldn't get in the way of me helping him. If he offered me a drink after, I wouldn't say no. It's understood that this offer is in direct response to me helping him, but I'm still motivated out of altruism. I'm simply receiving a greater reward for my altruism, and this time it's socially acceptable to take this.

The time of the people eligible for this program is worth more than $20/hr. This amount of money is never going to be a primary source of motivation for them. As the article said, "A side effect of building a company culture around OSS is that the kind of people who gravitate to work at Formidable are passionate about their open source work, and won’t stop contributing when they clock out at 5 pm." I did a bit of volunteer work in high school as part of a program, and upon graduation the program granted everyone a small, $250 "scholarship". I spent ~10 hours per week, for a year, as part of this program, thus making my "wage", if you will, about $2/hr. I can promise you, nobody participated in that program for the "scholarship". It showed that our time was appreciated, but wasn't nearly enough to incentivize the program to anyone who wasn't going to do it anyways.

I see nothing wrong with a token payment like this. It makes contributing to open source a more attractive option, but still only a viable option to those who were already motivated to contribute out of altruism. Obviously 20/hr isn't a token payment for a lot of us, but the concept itself of a token payment isn't something that necessarily invalidates altruistic intentions, in my view. I'll contribute to open source projects irregardless of whether or not they have a Bountysource, but I'll still accept a reward if it's offered. The purpose of this program is to reward people who are already motivated to contribute to open source, which in turn signals to its employees that Formidable appreciates open source contributions.