MurphyA/hacker-news huggingface dataset:
by jeffbee | 2025-04-13 23:35:17+00:00
America's only current, prominent bullet train is CAHSR and the goal of that project is not to speed up passenger rail. The project has nothing whatsoever to do with making existing rail riders happier or incrementally increasing ridership. The avowed purpose of CAHSR is to enable California to grow and prosper without having to build more airports and more freeways. So it's not really worth considering it as a choice between an expensive HSR on the one hand and slightly better Amtrak San Joaquin on the other. Only one of these projects would actually be suited to purpose.
by firesteelrain | 2025-04-13 23:35:18+00:00
I think the author is on the right track just needs to refine the assumptions a bit. Not sure if the method actually tests whether we perceive the oranges as more orange with red bags. Things like too small of a sample size, lack of any statistical analysis, uncontrolled lighting conditions, not controlling for phone camera, and simplistic color analysis (human eye is much more complex). Also lack of applicability to color science principles
by jltsiren | 2025-04-13 23:35:29+00:00
I've never understood the fetishization of long working hours. If there is a job where you can meaningfully work 80+ hours a week, the same (and often better) results can be achieved with more employees working fewer hours. If the work can't be split like that, it's probably demanding enough that you can't sustain more than 20-30 productive hours a week in the long term.

It's possible to mix reasonable hours of demanding work with additional hours of meetings, routine work, and procrastination. Maybe it's cheaper for the employer than managing the work better and hiring additional people for the routine parts. Maybe there are some social and organizational benefits to the employer when the employees have no life outside work. But long hours like that don't lead to superior outputs.
by aposm | 2025-04-13 23:37:34+00:00
There is no secret lost knowledge that enabled a steam-powered train to go from New York to Chicago in 16 hours in the 1930s. We simply do not care to run fast passenger trains anymore since they have largely been replaced by domestic air travel. The current NYC to Chicago train takes 20 hours and is routinely several hours delayed... all we have to do is invest in infrastructure and rebuild our rail system, but that won't happen unless it's "sexy" and can compete with air travel, and the best way to do that is with HSR. So while our passenger rail system _could_ be a lot faster (without true HSR) if it was run well, I don't think that's going to happen until we get the marketability/"sexiness" of HSR.
by codingmoh | 2025-04-13 23:37:45+00:00
I think you’re right to point out the inertia in the labor market and the structural energy required for paradigm shifts.

What worries me most, though, is that because of exactly the reasons you’ve described — and now, with the rise of GenAI that makes generating boilerplate imperative code even easier — we might be permanently missing the opportunity to invent a better, more elegant solution.

Instead of challenging the underlying paradigm, we’re accelerating its replication — just with fewer keystrokes. GenAI is helping us pave cow paths, not design highways.

My fear is that the convenience of generating "good enough" code at scale will solidify suboptimal workflows, and the space for reimagining them might quietly close forever.
by yshklarov | 2025-04-13 23:37:56+00:00
Apparently, this is a game that two can play. Niklaus Wirth, the creator of Pascal, had this to say in turn:

"From the point of view of software engineering, the rapid spread of C represented a great leap backward. It revealed that the community at large had hardly grasped the true meaning of the term “high-level language” which became an ill-understood buzzword."

Source: Niklaus Wirth, A Brief History of Software Engineering, 2008 (https://people.inf.ethz.ch/wirth/Miscellaneous/IEEE-Annals.p...)
by blindriver | 2025-04-13 23:38:01+00:00
Those equity percentages in this document are EXTREMELY FOUNDER FRIENDLY and I believe this entire document was written to anchor new employees with lowered expectations on equity. I think this entire document is a disingenuous scam to make new startup employees think that those percentages are okay.

I’ve been in Silicon Valley a long time, since the dotcom boom. My first company, the executive assistant got so rich from the pre-dotcom IPO she quit and bought a vineyard. That’s how things used to be. And we aren’t talking about some crazy ipo, it was before those times.

Fast forward to these days, the startup I worked for got acquired. I was engineer < 15. The founders got low 9 figures, I got 5 figures. Almost everyone got fucked for years of loyalty.

But that’s what YC and other accelerators teach founders. Be cheap with equity. And this document just perpetuates that.

Founders can easily make life changing money but the people that do the actual work get fucked unless it becomes a >100B company like a Facebook. That’s not realistic and they know that. Employees need a bigger piece of the pie when things go great for the company and not just when it becomes a Facebook, Uber, etc.

If you want to know how to evaluate equity, pick a total valuation of the company at exit and then multiply by your stake. If the company needs to exit at > 10B for you to make a life changing amount of money, then ask for much much more equity or don’t take the offer.
by simonw | 2025-04-13 23:38:10+00:00
"Tables (apps) are never really split up. Even in the perfect world, two apps developed by the same company will need to talk to each other"

I don't understand why this sentence appears to treat "tables" and "apps" as the same concept. Is this a use of the term "app" that I'm not familiar with?

---

TLDR of this post is that it's promoting a new open source (AGPL) horizontal sharding solution for PostgreSQL called PgDog: https://github.com/pgdogdev/pgdog

Looks like the trick this one uses is to parse your SQL queries inside a custom router/load-balancer and redirect them based on introspecting the WHERE clause of a SELECT/UPDATE/DELETE or the VALUES clause of an INSERT to identify sharding keys: https://docs.pgdog.dev/features/sharding/query-routing/
by NBJack | 2025-04-13 23:38:33+00:00
I have to trace structure and data handoffs across multiple projects sometimes that span multiple teams. I'm used to rather easily being able to find all instances of something using a thing, where something is originally defined, etc. I can't do that easily in Go due to the structural typing at times without either a very powerful IDE (JetBrains is the only one I know of that does Go well via Goland) or intimate knowledge of the project. It's surprisingly painful, and our tooling while not Jetbrains level is suppose to be some of the best out there. And Yahweh help me if I actually have to refactor.

I really doubt this comes up in smaller, one-team repos. But in the coding jungle I often deal with, I spend much more time tracing code because of this issue than I'drefactoring. Make no mistake: I like Go, but this irks me.
by dang | 2025-04-13 23:40:11+00:00
You can't post these as submissions to HN, but we have monthly "Who Is Hiring" threads that are free to everyone. They appear on the first weekday of each month and can be found at https://news.ycombinator.com/submitted?id=whoishiring afterward. You post your job as a comment in the latest thread. Please read the instructions at the top of the thread (above the actual job posts) and take a look at some of the other posts to get an idea of the conventions. These threads become closed to new comments after two weeks.

One important point is that you have to personally be part of the hiring company in order to post. Third-party recruiters and job boards aren't allowed.
by pyfon | 2025-04-13 23:41:30+00:00
Oh that is bad! It is a 20k/y pay cut you weren't expecting.

If they were keen to make amends they should just bump your pay that much. Unless they are struggling.

By the way I have a similar RSU amount and schedule. So gar so good but cognizant that in the contract they can stop it at any time. I took the risk as I can also quit at any time!
by SideQuark | 2025-04-13 23:41:38+00:00
> But should you learn integration before differentiation? I’d never considered this approach until I read David M. Bressoud’s fantastic book Calculus Reordered,

Ha, I learned calculus integration first from Ivan Niven's "CALCULUS An Introductory Approach," copyright 1961, that as a kid I found in the attic in my dads undergrad engineering books. When I got to high school and took calc, I was able to do all the stuff they were teaching, but in weird orders and methods compared to more modern books.

Now, 40+ years later, I still have that book on my bookshelf in the calculus section :)

Till now, it's it only book I've seen that teaches it this way.
by est31 | 2025-04-13 23:42:07+00:00
> without risking/gambling your own capital by exercising them.

Many companies offer early exercise, so you can reduce the amount you gamble by a lot.

Also, you already "pay" in terms of opportunity costs by being at that startup vs something more established where you get RSUs of a public company. So using some of the money from the startup in order to exercise the shares is really useful. If the startup's cash compensation is just enough to pay your bills, then of course it's different.
by jtolds | 2025-04-13 23:42:32+00:00
I replied to your comment on my website, but for posterity here, yes, I do think you did a good job for the part about exiting when bestScore > 100. There's nitpicks, but this is fine! It makes sense, and nice use of a select over a send.

I did expect that this exercise would come after the first one though, and doing this on top of a solution to the first exercise is a bit harder. That said, I also don't mean to claim either are impossible. It's just tough to reason about.
by marcusb | 2025-04-13 23:42:38+00:00
All of the RSU offers I ever got stipulated the grant was "subject to the approval of the board", i.e., not guaranteed. That said, I'd be absolutely livid if something like this happened, and would be expecting my manager to either make it right, or I'd look for a new job at the first available opportunity.

You can't do good business with bad people.
by Vedor | 2025-04-13 23:42:53+00:00
I think that LunarML [1] could fit this niche quite well. It's a StandardML compiler that targets Lua. I can't tell much more as I've only played with it a little and don't have much experience with ML languages in general, but it looks promising.

[1] https://github.com/minoki/LunarML
by add-sub-mul-div | 2025-04-13 23:43:54+00:00
There's a lot you can do with jq to transform complex json into an intermediate format designed to be input for simpler Python processing.

My experience with Dagster has made me appreciative of plain, simple Python code and highly skeptical of frameworks.

The longer you stick with Python the more elegant you'll find your code. It takes time and trial and error to go from being annoyed with your code to being more comfortable with it and not looking for a tool or framework to be the silver bullet.
by fuzztester | 2025-04-13 23:44:53+00:00
>Does not make sense in this context, as it mainly applies to Lisp-like languages that uses parentheses heavily.

I had read, some years back, that someone did an actual calculation / demonstration that showed that the number of symbol / punctuation characters in Lisp is actually less than in C-based languages, for a block of code with equal functionality in both languages.

I don't have the reference handy. Someone here may know of it, and post it.
by donpablo | 2025-04-13 23:45:27+00:00
I'm looking for a developer to join our venture.

About Us: - We operate in the GTM Marketing and Sales space - We're an AI-first company where artificial intelligence is deeply embedded into our systems - We replace traditional business logic with predictive power to deliver flexible, amazing products

Who You Are:

Technical Chops: - Full stack dev with expertise in: - AI agents and workflow orchestration - Advanced workflow systems (trigger.dev, temporal.io) - Relational database architecture & vector DB implementation - Web scraping mastery (both with and without LLM extraction) - Message sequencing across LinkedIn & email

Mindset: - You breathe, eat, and drink AI in your daily life - You're the type who stays up until 3 AM because "Holy shit there's a new SOTA model release I HAVE to try this out" - You actively use productivity multipliers like cursor, roo, and v0 - You're a problem-solving machine who "figures it out" no matter what obstacles appear

Philosophy: - The game has completely changed and we're all apprentices in this new world. No matter how experienced you are, you recognize that some 15-year-old kid without the baggage of "best practices" could be vibecoding your entire project right now. Their lack of constraints lets them discover solutions you'd never imagine. You have the wisdom to spot brilliance where others see only inexperience.

- Forget "thinking outside the box" or "thinking big" - that's kindergarten stuff now. You've graduated to "thinking infinite" because you command an army of AI assistants ready to execute your vision.

- You've mastered the art of learning how to learn, so diving into some half-documented framework that launched last month doesn't scare you one bit - you've conquered that mountain before.

- Your entrepreneurial spirit and business instincts are sharp (or you're hungry to develop them).

- Experimentation isn't just something you do - it's hardwired into your DNA. You don't question the status quo because it's cool; you do it because THERE IS NOT OTHER WAY.

What You're Actually After: - You're not chasing some cushy tech job with monthly massages or free kombucha on tap. You want to code because that's what you love, and you expect to make a shitload of money while doing what you're passionate about.

If this sounds like you, let's talk. Pablo@revenueformula.io
Ask HN: How do you prevent documentation from becoming tribal knowledge?
by sky2224 | 2025-04-13 23:46:31+00:00
I've run into this situation before where I join a team and person X begins helping me with something, then person Y comes along and says, "Oh yeah we have a documentation page for this, it's buried here."

Or a different, but similar scenario: I'll begin trying to solve a problem. I'll search the team's documentation and find nothing, but then I'll be pointed to documentation that is exactly what I was looking for. Ugh.

So it's kind of funny, I'll be on a team with a wealth of information documenting everything, but it's borderline useless since I can't find what I need when I need it, and only Joe who has been here for 15 years knows exactly how everything is laid out and knows where to point me. How do I prevent this? How can I structure my documentation so it's easy to navigate and easy to stumble upon what you need. I can't be the only one that's had this issue, right?

I guess at a higher level I'm realizing that this question really is, "What's the best way to structure documentation"?

Additionally, any tips on how to do this in Confluence? I feel like at least 20% of the problem is due to how awful it is to create anything remotely navigable in that tool.
by 0xbadcafebee | 2025-04-13 23:46:42+00:00
Or, y'know, just build a bullet train.

USA. Biggest economy on earth. Most powerful nation. Third largest nation by population. Could maybe build one bullet train, like the 20 other nations that already have them in service, and the 13 other nations that have them in development.

Or just settle for mediocrity. Whatever.
by atombender | 2025-04-13 23:46:50+00:00
Minor point, but in most cases the title was made up by the editor, not Dick.

For example, Do Androids Dream of Electric Sheep? had several terrible tentative titles originally, including "The Electric Toad", "Do Androids Dream?", "The Electric Sheep", and, most improbably, "The Killers Are Among Us! Cried Rick Deckard to the Special Man".

Dick's editor at Doubleday came up with the current title. Dick didn't like it and thought it was too long and unwieldy.

Some more:

* The Divine Invasion: "VALIS Regained"

* The Transmigration of Timothy Archer: "Bishop Timothy Archer

* Ubik: "Death of an Anti-Watcher"

* Martian Time-Slip: "Goodmember Arnie Kott of Mars" (also serialized as "All We Marsmen" before getting its current title)

* We Can Build You: "The First in Your Family"

* A Maze of Death: "The Hour of the TENCH"

* Counterclock World: "The Dead Grow Young"

My main source here is Lawrence Sutin's excellent "Divine Invasions: A Life of Philip K. Dick".
by smitty1e | 2025-04-13 23:48:33+00:00
> There's a wealth of evidence that a society that provides guarantees around those basic needs

I'm totally in agreement, in the abstract. It would take a sick mind to enjoy observing poverty/starvation.

The details of how a sustainable economy that affords all the opportunity to thrive is provided is still non-trivial.

The Five Year Plans of the Soviet Union, to drop a specific example, were full of great ideas, but the society was corrupt and everyone lied about the reality, until the lies collapsed at the three-quarter-century mark.
by arghwhat | 2025-04-13 23:49:15+00:00
Same tier EVs are always more powerful than gasoline cars as they are generally just battery limited, not motor limited.

EVs are just a better tech in that regard, and buyers are not buying a Dolphin or golf based on torque or max HP. They're compacts in the same space. Someone looking at a dolphin would more likely be looking at the lighter eco motors.

This is true in other tiers too, e.g. a performance tier gasoline car might be 250-350 HP, while the same tier EV might start at 450-550hp just because they can.

The difference within a tier, simply based on the fact you're replacing at best a lightweight 100kg engine with 400-500kg worth of battery, can't be as small as you suggest.

With larger EVs, the battery weight is much greater, increasing the impact. Rocket equation and all.
by pyfon | 2025-04-13 23:49:36+00:00
Someone made a good argument on Reddit when discussing Australia which is also has a slowish rail network.

It is a 3hr drive Sydney to Canberra and 4hr on train. Mainly because the train track was originally for freight so has more curves than needed for passenger.

They said rather than aim for a super fast train just improve the tracks we have and get the time down to 3hr to compete with the car.

This is a good point because then you get more revenues and usage (the trains are full right now but infrequent - maybe they can run them every 15 minutes)

Then you can go make the case for an even faster train for 2050.

The Japanese Shinkansen is something else. Doing my first decent trip on one this week and can't wait!
by int_19h | 2025-04-13 23:49:56+00:00
The intersection of nil and interfaces is basically one giant counter-intuitive footgun.

Or how append() sometimes returns a new slice and sometimes it doesn't (so if you forget to assign the result, sometimes it works and sometimes it doesn't). Which is understandable if you think about it in terms of low-level primitives, but in Go this somehow became the standard way of managing a high-level list of items.

Or that whole iota thing.
by parpfish | 2025-04-13 23:50:06+00:00
My take on stochastic parrots is the similar to the authors concluding section.

This debate isn’t about the computations underlying cognition, it’s about wanting to feel special.

The contention that “it’s a stochastic parrot” usually implied “it’s merely a stochastic parrot, and we know that we must be so much more than that, so obviously this thing falls short”.

But… there never was any compelling proof that we’re anything more than stochastic parrots. Moreover, those folks would say that any explanation of cognition falls short because they can always move the goal posts to make sure that humans are special.
by jijijijij | 2025-04-13 23:51:41+00:00
> You can restrict immigration in a humane and respectful way

But this won't change anything, if their demand is not reasonable, or founded in truth to begin with. As I said, the AfD is most popular where there are no migrants at all. Lots of them feel their narrative validated when they see a brown person existing, see "Turkish" people living here for generations. The goalpost will always shift. You will never satisfy them, if their demands aren't anchored in reality. Again, this isn't fueled by exposure, but guided media outrage. There is a lot of conspiracy narratives mixed in as well. Talk to them, poke deeper than the concern trolling surface. You will encounter actual loony talk quite soon.

Apart from that, the biggest problems with these ideas are factors outside of Germany's control. E.g. if the origin country won't accept those immigrants back, you can't just air drop them there. Constitution, European law, human rights, Schengen... it's not really possible/worth it to do anything significant. It's all ever going to be for show.
by StopDisinfo910 | 2025-04-13 23:51:42+00:00
Le Grand Paris is the loop and the prolongation of all the inner lines deserving it. It very much involves Paris as its name implies.

> Besides, what your say about the speed limit is false, the mayor didn't wait for the State's answer and decided unilaterally. The State and the region didn't agree with her: https://www.lemonde.fr/politique/article/2024/09/09/anne-hid...

The article you quote says the opposite of what you pretend. I invite you to read the paragraph "Une décision sous le contrôle de l’Etat, rappelle le ministère". It explains in details than the mayor could do nothing without the state agreeing to it.

> You can consider as much as you want, it is not unified.

It is unified. The city and its suburb are one economic unit. Where do you think all the service workers live? You have to be an extremely narrow minded inner city dweller to fail to see this.

> creating a system where Parisians can't own one, but have to bear their neighbor's who use them to get into the city.

I kindly invite you to check the average salary of Paris inhabitants vs the one in the suburbs then take a minute to think about what you just wrote.
by GoRocks12 | 2025-04-13 23:51:45+00:00
Amusing, like the Blub paradox but backwards. Programmers with no experience in Go think they can critique it before they've understood it.

If you don't understand how to use channels, you should learn first. I agree that you might have to learn by experimenting yourself, and that

a) there is a small design flaw in Go channels, but one that is easily fixed; and

b) the standard documentation does not teach good practices for using channels.

First, the design flaw: close(channel) should be idempotent. It is not. Is this a fatal flaw? Hardly. The work around is trivial. Create a wrapper struct with a mutex that allows you to call Close() on the struct, and that effects an idempotent close of the member channel. Yes this is a bit of work, but you do it once, put it in a re-usable library, and never bother to think much about it again.

b) poor recommended practices (range over channel). The original article makes this mistake, and it is what causes his problem: you can never use range over a channel in production code. You must always do any select on a channel alongside a shutdown (bailout) channel, so there will always be at least two channels being select-ed on.

So yes. The docs could be better. It was immediately obvious to me when I learned Go 12 years ago that nobody at Google ever shuts down their services deliberately. Fortunately I was learning Test Driven Development at the time. So I was forced to figure out the above two rules pretty quickly.

Once those two trivial fixes are in place, Go sails. There are Go libraries on github that do this for you. You don't even have to think. But you should.

Handling errors is only as verbose as you want it to be. You do realize you can call a function instead of writing if err != nil so much, right? Sheesh.

Go _is_ something of a sharp tool. Maybe we need to put a warning on it: for mature audiences only.