skysight-inc/HackerNews huggingface dataset:
Ah, the hallmark of 20th century pseudo-intellectualism: operationalize an ill-defined concept (e.g. "free will," "rationality," "empathy"), produce a dubiously reproducible experiment, maybe write a controversial paperback making ridiculously hyperbolic claims, let the press go apeshit, $$$.

Other flavors include:
Pluck a plausible, edgy explanation out of a vast hypothesis space (e.g. evolutionary psychology), over-reductively apply a catchy theorem to a vastly complicated domain (looking at you, game theory). Take a thin, ecologically invalid model and claim "that's how the brain works!" (both neural networks and sybolic reasoning systems).

I feel like in this century, we've realized that all of this was maybe useful as a reference point to formulate hypotheses, but become less stupid about the conclusions we're willing to draw (as a population).

The wonderful reality is that we don't really have strong opinions about free will, because we're not sure we really know what that could mean or why precisely it seemed so important a century ago.
Sort your legal definitions. Copyright infringement is not theft.
Because makes and females have different nutrition, different habits and fir example use different drugs. It may be something silly like different contents of birth control pills. It's not a secret that small changes in amount of consumed zink, calcium or iodine make big impact on body and mental abilities.
See also this contalk from 2013 by Mirabai Knight: "Plover: Thought to Text at 240 WPM"

https://www.youtube.com/watch?v=Wpv-Qb-dB6g
The suggestion is to not use foreign key constraints in the database.

The suggestion is not to eschew columns which might be JOINed on in a query.

I.e. "Don't enforce FK relationships with a constraint in the DB. Make sure the values in both tables which may be joined are consistent by using application code to enforce this."
The application code isn’t enforcing FK constraints because that is impossible for the application to do. Their database is almost 100% guaranteed to be corrupt as a result.

Application code has bugs. Application code can fail in ways that result in corruption. A primary job of the database is to keep itself from getting corrupted. Enforcing foreign key violations is only something the database can do correctly. Punting the responsibility to a higher layer will result in corruption.
> By declaring a field/variable []Thing vs []* Thing you get different for loop semantics. Way to easy to think your mutating the array item, but only mutating a local copy or vice versa.

The loop semantics are always the same, the element variable is a copy of the value at the current index. Yes that means that if the value is a pointer, the copy of that pointer can be used to modify the pointed data. This is something a good Go programmer should understand well because this behavior goes way beyond for loops. For example functions - func (t Thing) vs func (t * Thing) - with the pointer version the body of the function can modify the pointed data. Side-effects! Just like the for loop.

> gofmt feels way out of date.

I like to think of it as stable. The biggest strength of gofmt is how universal it is. Everyone uses it and all code out there looks the same. There's a growing collection of Go code out there. If gofmt would keep changing its style, then all the already published code would no longer match the standard. Thus, I think there needs to be a real strong reason to modify anything about it.
Yep, Amazon didn't do anything wrong, but when sellers catch on and want to own their actionable data and build their own operations, Amazon should let them. Locking them in further is not right.

I was one of those sellers and now I'm working on an opensource solution to help sellers migrate and not be dependent on Amazon FBA alone.
Seriously.

"As a C developer, I never check exit codes of child processes. We can just enforce it by ensuring child processes don't have bugs"
I don't understand this comment. Could you unroll it for me?

After all, AMP is despised by the tech community — but ultimately still used by publishers because Google's more-or-less holding them to ransom.

Apple's not holding App Store developers to ransom with regards to apps that use Electron; rather, the use of private APIs always has been and always will be forbidden.

That people went all-in with a technology that depends on private APIs without properly vetting the underlying stack, or rather that the core developers of this technology knowingly make use of private APIs, isn't quite the same as Google's leverage over publishers via its monopolistic grip on the world's search and advertising businesses, surely.

One is a matter of technology, possibly of security, and the other is a more political discussion.

But if I'm missing an angle, I'm open to being let know!
> “Rebrand, they said. It’ll be great, they said,” Whitfield lamented. CEO and co-founder

Loved Logojoy and Whitfield when they launched. Should probably take more responsibility than a `they` though.
The way I've usually seen it done is that the foreign key columns still exist. The relationships are there, the database just doesn't enforce them.

The items table might have a shopping_cart_id column
and as the article states - that argument is weak
I wish this was more feasible with less collateral damage over a shorter time. The web is a trash fire of absolutely historic proportions, from the frameworks/APIs to the languages to the UI/UX. The world deserves better.
I'm not sure "you can't add checks because they might fail!" is sound reasoning...
Now you’re just being silly.
Letting anyone sell anything they want is how you get the Play Store, a monument to bad experiences. Pages upon pages of cloneware apps, asset-flip games, on and on and on, all of which of course are drowned in advertisements. In my last year of owning an Android before I got my first iPhone, the 6 Plus, I didn't even open the Play Store anymore. It was awful.

That's not to say everything on the App Store is great, of course, but it's a hell of a lot better.

Edit: Upon further thought I should really go further with this: The quality of the App Store is part of the marketing of iDevices. This is why Apple's app review process also looks for things like apps that crash too much, apps that run slowly, apps that are burning through system resources, on and on. It's why you generally won't have an app on their store that will, for example, destroy your battery, or games that show you ads every 15 seconds.

I know the attitude on HN generally prefers freedom over curation, and in many ways I'd agree, but when it comes to the walled garden Apple provides, sorry friends, I just like being here.

Edit's edit: In fact, I can even take this one step further: this is, I believe, part of the reason iOS users are far more likely to be willing to PAY for their apps: because Apple checks them at the door. And sure, quality isn't guaranteed per say, but at least you know someone is trying at it. You can be assured that this app isn't going to damage your device somehow, and you can be reasonably sure that it's going to do what it says on the tin, at least competently. And if not, Apple has your back with refunds, too.
What's wrong with CDs and DVDs? You can still buy these for cash in many places.
It's not as if the current situation, in which Boeing is currently causing all their customers lots of financial pain each day the MAX is grounded, and the CEO of the commercial division has been fired, is any better.

The Airbus order backlog is almost a decade out as it is, so American just shoving it all into A320neos that would take longer to show up wouldn't exactly be realistic either.

Boeing should've just gone with a clean-sheet design.
You do not have to have a foreign key defined to do a join across tables. Foreign keys just enforce that all the values in the given column of a table are present in another given column on a specified table (usually a second table). They prevent you from entering data that does not match up.
I agree, and I am one of the people who has some major gripes with systemd through experience. I admit it's a reality and people should learn it, but the problem is not many people have, and sometimes it really makes things that used to be much easier not necessarily more difficult (though sometimes), but rather more complicated (there is a difference). For example, I always found writing a sysvinit service pretty straight forward, but systemd units can get unweildy especially when doing anything complex, though I will admit some of the features are nice if you can figure them out, such as when in the init proc to start, vs having to do that manually in sysvinit scripts.

It also often fails to admit when it is failing, for example, nobody I know uses journald as the main or only logging system, and are still piping to local (r)syslog(ng) and then to elk/splunk, etc, because journald is simply not up to par.

In general, and I'm just being honest here, besides these mostly work-aroundable issues, it is the seeming disingenuousness of those who automatically rail against anybody who criticises systemd that makes me not like it. Call me a contrarian, but I hate being told I must like X and if I don't I'm dumb and behind the times, and my nature is to push back against that.

In that vein, I support the efforts of Devuan and similar projects if only to support a counter-balance.
oh my god, they are complaining about an acronym DDD, because it somehow sexual (not being a native english speaker, I fail to spot the innuendo). If there's anything to complain about ddd is the name clash with Data Display Debugger, a really cool debugger for linux.

I wonder about the callous ignorance of Sarah Mei, who purports to be a feminist but ignores such an important program written by another woman.
A foreign key is a hard-constraint that must be enforced.

There's no stopping you from storing item IDs in a theoretical shopping cart table without FK constraints though. It's just that the onus is on your application to provide the guarantee that the item exists.

This becomes a little clearer if your item IDs are not simply auto-incrementing IDs (which have their own challenges in a large distributed system), but instead are SKUs, or things which have actual meaning.
The Dimensions of City Blocks
Look around on the Google Play store and you'll see that no, the market does not filter out crap. Crap is most of what you can find on Google's store. Just try to find a proper mail client or file manager, there is so much junk in there.
An example would be DBPedia, a service that extracts data fro m Wikipedia and makes it machine readable via SPARQL (language similar to SQL).

For instance, here is what Wikipedia has to say about Triplestore:

https://en.wikipedia.org/wiki/Triplestore

And here is DBPedia representation of it:

http://dbpedia.org/page/Triplestore

And here's how you'd get the data from DBPedia programmatically using SPARQL -

select * where {
<http://dbpedia.org/resource/Triplestore> ?p ?o.
}

Try it here - http://dbpedia.org/sparql/
In this case, they use "foreign keys" in the sense that there are keys which correspond to keys in other tables.

There are no foreign key constraints, the keyword is never used.
I don't understand these articles that are coming out recently, and I don't want to seem like I'm attacking the people who use these tools...

But, its starting to feel like the people who want to use tools that allow them to build apps and programs that are cross-platform (NodeJS, Electronc, etc) are trying to use their weight as "the most popular programming language" to get platforms to conform to whatever they want.

Why should Chromium be allowed to use private APIs that native developers already knew "should NOT be allowed" especially those coming from iOS where its known using those would simply have your app rejected.

I don't have as much of an issue with Electron apps as most people do, but at some point you have to realize the short comings of cross-platform dev tools and work around them instead of trying to force everyone to just accept them.
With the speed of sound and its characteristic attenuation in the sea water and marine mammals' general stealthiness this is just not possible.

Not possible, period.
> And yet it still feels like a language out of the 60s or 70s.

I started programming in the 80s, and Go feels modern even compared to the mainstream languages of this era (mainly BASIC, Pascal and C).

It also feels modern compared to the first versions of Java in the 90s.

You don't like Go and I respect that, but Go definitely reflects its time, the 2000s, with its syntax, automatic type deduction, GC, gofmt, interfaces, goroutines, closures, built-in HTTP, built-in testing framework, etc.
Regardless of the reason, if Electron was using private APIs, and Apple doesn't allow Apps that use private APIs in the Mac App Store, I'm glad Electron isn't being given a free pass just because it's popular.

If this was iOS, where sideloading is basically impossible, I'd be much more sympathetic to the author's view. But we're talking about the Mac. Apple's quality control is the reason for users to choose the Mac App Store. Any users who don't want that control can easily go elsewhere.
"Slow, but javascript renders incredibly mega fast on my i7 MacBook Pro!- And electron works great on that same laptop with 32GiB of ram!" /s
This is hyperbole based on the recent issues with Electron and little else. I'm not a fan-boy, but the fact is Apple has, in its own apple-ish way, been at the forefront of web technology for a decade and is continuing to do so. Safari is continually updated with the latest specs and JavaScriptCore continues to compete with V8. Yes, they make random security/business/tech decisions which can be frustrating, but even Apple knows they can't dismiss web tech, and they're not.

A great example is the beta of Apple Music - it pushes the state of the web forward by embracing Web Components, ES6, modules and more. It's probably one of the most modern websites out there at the moment. And Apple Music is serious business to Apple's whole ecosystem. If they were trying to kill the web, they would have just remade the old iTunes client.
Just my two cents...

The banning of Electron apps for using a non-public API just means it's consistent with any other application submitted to the app store... they cain't use them sweet private APIs neither. Users can totally still go and download a notarized application though and have no problems. It's something that'll very likely be remedied by the Electron team in its entirety if it hasn't already been...

As far as not giving a shit about Safari's ability to do WebRTC and PWAs properly; I don't really see that as Apple trying to kill web technology as much as them just not profiting off it. Apple doesn't make any money from the "web," they make it from their platforms which aren't HTML/JS/CSS. As a developer, that lack of focus does piss me off sometimes, but... as an end user I don't really notice. Safari is still the best mobile browser available, even if it is lagging behind the rest in terms of standards adoption.

...

And tangentially, in my opinion, the Electron apps being booted is a good thing, if even only temporary, as I really hate downloading an app from the Mac App Store only to find its a full blow fucking Chrome instance for something that would be literally be two NSViewControllers and a handful of "slightly" customized views. Like "Yo, player, your system tray app to show this red or green icon is using 400mb of ram and occasionally locks my CPU. WHY!?!"
You can, and I think you should, place your data and stored procedures in separate schemas. This way, migrations are only required for the data, and stored procedures can be deployed and version-controlled just like any other code.
I was recently doing some language evaluation for rewriting an existing system in Go to improve its cross-platform compatibility. One of the things I realized in this exercise was that "compiles to C" was a powerful feature - not because of C itself, since C often gets in the way of the source language's intent - but because it means that the result fits into and leverages all the C-based tooling, facilitating the desired level of platform independence.

And for a lot of projects today, "the bottom" ends with C for precisely this reason - while the fact that C is the chosen language for this task is completely arbitrary, as arbitrary as the status quo hardware paradigm of "x86 on desktops, ARM on mobile". I could imagine a universe where it was an extended form of Basic or Pascal that ruled the world instead.

Likewise, I was also looking into extending Lua with a small DSL interpreter that could accelerate certain byte-level tasks: copy around blocks of bytes, run some common algorithms quickly, define spaces for variables, apply some parameters. At first I thought of this language as a "VLIW" assembly language with a particular focus on having a big bag of tricks, but when I compared my semantics with actual hardware assemblers, I found that having no registers or stack manipulation and focusing only on direct memory addresses changed the character of it so much as to make it a different beast, one more like the "autocoders" of the 1950's: not quite ALGOL, and yet clearly headed in that direction.

All of which is to say - the more you are comfortable with compilers, the more the bottom just becomes the thing you happen to be leveraging to ship product. It isn't "the real stuff" until it becomes the specification language. Some things, like how numeric types are defined in hardware, force the terms of specification way up the stack so that the hardware may be used at its capacity. But that in itself is an "essential complexity" in computing, where the physical realities coincide with the desired programming model. When it's software defining the spec, as in our libc-and-Javascript-driven universe, that's more akin to social complexity, but it produces the same kinds of effects.
The ones going ballistic over this are content creators who think that their artistic vision is being compromised. Everyone else either likes the feature or doesn't care.
Wow. Thanks for sharing these links.
That's interesting. I'm pretty much done developing for the Apple platform. If I need to create an app, it will be a web app. I'm sick of xcode, sick of swift, and sick of "professional" grade mac hardware. All this technology to make pretty UIs on top of API calls.
There is no difference when not having foreign key constraints.

In both cases you can't delete items from your catalog or you'd break old carts. So you just don't do it.

Another way is to copy the product from the product table to the cart table. This saves you from making references to versions of products.
I thought foreign keys were necessary for the consistency part of ACID compliance. Once you remove the integrity constraint, the database cannot guarantee consistency, even with isolation and atomicity.

Sure, removing the constraint will get you a huge burst in performance, but now you are in charge of guaranteeing consistency outside of transactions in a distributed system involving at least one client and one server. That's a tall order.
As Runar Bjarnson put it: "Constraints liberate, liberties constrain,"[1]. If you give something the freedom to be inconsistent at any extreme scale, Murphy's law requires that anything that can go wrong, will go wrong.
It is hubris to think that the average developer who hasn't spent years becoming a consistency expert is going to be able to guarantee that data won't become corrupted better than the engineers that build and maintain and acacademics that study rdbms systems full-time.Even experts get this wrong all the time [2]. To all junior devs out there, until you know you need to abandon a guarantee available to you in a given system, exhaust every other possible option.

1. https://youtu.be/GqmsQeSzMdw
2. https://aphyr.com/posts/282-jepsen-postgres
TL;DR Title is misleading hyperbole, it's talking about Apple not allowing Electron-based apps that access undocumented APIs into their App Store.
Every time I have seen a database use foreign keys there has been data corruption, because everyone thought foreign keys were declarative and not procedural. Just because you have a foreign key doesn't mean it was always there or that it applied on every transaction. You can turn them off at the connection level and you in fact must turn them off for almost any kind of bulk data load.

You should read shlomi's post he gives good reasons. Specifically this is a github issue on his tool gh-ost which is for online schema migration, and FK's pose lots of problems for online schema migrations.
Exactly this. And Robert Martin has made similar sentiments clear in prior discussions with her.
Purely functional algorithms and data structures are typically slower. Imperative code is also more concise than equivalent functional code.

The only real benefit of functional programming is that it makes code much easier to reason about. But this difference is so great, that in most cases I am ready to pay the price.

P.S. Just to clarify my position to the commenters who want to convert me: I write code in functional languages most of the time for the living, so I know well enough how ST monad works, about "O(log n) == O(1)" meme, and so on. But I also have some background in HPC, where I used imperative languages. So I have plenty of experience in both paradigms, and I know exactly what are their weak and strong parts.
If a worker fails or gets pre-empted, how does it retry anything? It's gone at that point, no?

Sounds like you'd end up with a bunch of dangling shards orphaned in WORKING state. And now you need timeouts and health checks and something to coordinate all that.
FK’s don’t just maintain “stronger” data integrity, they are the only way to maintain relational data integrity. Application code cannot maintain that relational integrity, period.

Any developer who thinks application code can enforce relational integrity is naive and does not understand relational database systems. It is impossible for any layer above the database itself to keep things from getting corrupt.
The author's main points are that:

1. Apple has started rejecting Electron apps from their app store.

2. Apple's "Hotel Cupertino" - you can bring any browser you want, but you can never leave Safari. (That is, the iOS versions of Chrome, Edge, Firefox are merely glorified Safari skins; Apple doesn't allow independent browsers on their platform.)

3. Apple ignores, or is slowest to implement, open web standards like RTC, progressive web apps, push, and more.

As someone involved in the progressive web app (PWA) standards space, I unfortunately must concur with the author's observations: Apple is soft-suppressing web standards, especially in the PWA space.
https://torrentfreak.com/images/piracy-is-not-theft.png
Came here to say something like this, though you said it more eloquently. Also a couple replies to you below add great context.
- postgres doesn't maintain a queue for notify/listen, it's purely pubsub. I'm not quite sure how the backpressure could make it to the database

- A lot of use cases involve not dropping messages after they are processed (like CI jobs, in this example), so you don't have to vacuum the rows

- If you're comfortable with SQS there's no really big reason to switch, but it makes it so that your project can only run on amazon cloud servers, which is annoying.
Population growth is already slowing due to decrease in fertility, increase in education, etc. Is the absolute value of the population the issue or is resources used/carbon output, per capita, a more significant problem?

Between 2019 and 2050, populations are projected to decrease by one per cent or more in 55 countries or areas, of which 26 may see a reduction of at least ten per cent. In China, for example, the population is projected to decrease by 31.4 million, or around 2.2 per cent, between 2019 and 2050.[1]

[1] - https://www.un.org/development/desa/en/news/population/world...
First we got Communicators... now Isolinear Chips... I can't wait for Transporters!