skysight-inc/HackerNews huggingface dataset:
This, btw, is why I have separate twitter accounts for my silos of interest: my fellow programmers don't care about the non-tech podcasts, I follow, my politics, my religion, my hobbies, and especially my views on Star Wars -- I have separate accounts and separate social circles for each of these topics. I'm surprised so many people use just one account for everything because any two people, selected at random, can find a reason not to like each other. I prefer to keep a tight focus.
Unless you're working with immutable primary keys (i.e. the values can neither be updated nor deleted), it is actually not possible to reliably enforce a foreign key constraint outside the database.
You seem to be confusing the idea of entitlement with simply having the ability to do something. It's perfectly possible to download copyrighted content while also not feeling entitled to that content. If I look for a torrent for some movie, and I can't find a torrent, I don't throw a fit, because I don't feel entitled to that movie. If I do find the torrent and download it, cool, that still doesn't mean that I feel entitled to it. People seem to label any actions they don't like as being an indicator of "entitlement," when that word actually has a pretty clear specific meaning.

And yes, you're completely correct about the reason you can listen to a concert from outside, and that is also true of online copyright infringement. Remember the whole "suing grandmothers because their grandkids used Napster" thing? It wasn't even remotely proportionate, and it didn't go over well.
Bitcoin to Form New Economic Class: Adamant Research Report
That was my first question, too.

I linked another company doing the same thing and they claimed it could withstand 0.5 tons of force before breaking. I’m not sure how that applies to dropping it, necessarily if there are other parameters that would cause a weakness that way.
How to Do Business in China Without Going to Prison
I’m pretty confident that GitHub doesn’t use foreign keys because it was built as a Rails app. And the “Rails Way” is to create these constraints in the model. Foreign key constraints weren’t a first-class member in Rails until v4 (if memory serves correctly).

I was once a full-time Rails dev and really loved the framework (I don’t write as many user facing applications these days). Most of the Omakase trade offs didn’t bother me. But I never understood the disdain for foreign keys. For 99.99% of web apps, you want them (dare I say, need them).

Even in Rails 3 I would add them by hand in the migration files. Very few applications will ever actually care about sharding. We were pulling in millions at the last Rails company I worked for and were just fine with a master and a single replica.

If you get to a point where sharding is best for your company you hopefully have enough revenue coming in to fund a data transition. Your goal should be to outgrow what MySQL (or Postgres) can do for you in master/replica mode. If you do, you’ll likely be independently wealthy...

If data integrity matters at all, model-based checks (or periodic queries for orphaned data) will not suffice. Just put a foreign key in the table where it belongs and let your DB do what it does best. ACID is an amazing thing...
Application-level checks are prone to race conditions, especially at the default transaction isolation levels of many popular SQL databases.

For example: transaction X deletes a parent row and its child rows while a concurrent transaction Y inserts a new child node. Without a FK, this can leave an orphaned child row.

For similar reasons, SELECT before INSERT is generally not a safe replacement for a UNIQUE constraint.

You don't even need that high a user volume to see these errors in practice.

It's a shame that ORMs don't tend to encourage the use of database-level constraints, but even if I just want to build something quickly in e.g. Rails, I still add the constraints as an extra check because I'd rather get the occasional 500 than an inconsistent database.
Seems like you couldn’t go wrong with using the Java Virtual Machine or the Common Language Runtime(.Net).

Both have a wide variety of libraries and a reliable VM.

Plus, if you want more productivity, or to use other programming paradigms, you can use C# or F# for the CLR, and Groovy, Kotlin, Scala, or Clojure for the JVM. I believe all of them have full access to all C# or Java libraries.
Both Google and Apple have monopoly power.

Pure monopoly means single supplier, but companies having monopoly power where they have the ability to increasingly behave independently of competitive pressures is more common.
https://en.wikipedia.org/wiki/Lerner_index

Apple should be forced to stop these anticompetitive practices.
An item should never be deleted from a catalog. That would break a lot more than carts.

If you need to track the inventory status/availability of an item, then you store that in the database. The specific implementation (field, list of current items, etc) depends on your needs.
Show HN: A simple CRM for commercial real estate
To be fair, iTunes and Amazon do/did offer DRM-free for some music selections.

I think blaming the distributors is misplacing the blame. The problem is that the distributors don't have the legal right to do that without contractual buy-in from content owners who fear that their golden goose will dry up if content is offered without DRM or if digital content can be kept and used in perpetuity by consumers.
Why are you presenting a straw man and making people seem entitled based on that straw man? That's not at all the issue and has never been. In the channel subscription days, people wanted to be able to select certain channels, like let's say Discovery Channel and History Channel, without having to pay $X base + $Y for the package that has both of those channels. In that case, you're also paying for channels you'll never watch, whereas you want to pay for select channels only. But cable companies never offered that option because they're using bundles to subsidize less popular channels.

Now we're back to the same issue. Previously, Netflix and maybe Hulu were the options. Still sorta bundling, but at least if you like X show and Y show, they might both be on Netflix and you can stay in one subscription. Now with every company making their own subscription, and forcing shows to be exclusive, you're having to subscribe to multiple services just to watch X and Y shows. Same problem as before.

Don't make it seem like people are entitled just because they want simplicity and choice.
Kinda weird how many people seem to think that it is good when Apple boycotts modern web technologies.

I mean, we all know that electron has its downsides (large downloads, old versions, etc.). But PWAs are the technology to overcome those problems and instead of supporting PWAs, Apple doesn't seem to care to bring crucial features like web push notifications to PWAs on iOS (it is not about pushing ads message, but about being able to efficiently send a message to a phone while the app is in the background, e.g. for chats).

So I can definitely follow the argument of the author.
Hi, I'm Matt. I built this tool last week and wanted to get feedback on it right away.

Direct investment in commercial real estate is difficult. Finding good deals is a big part of the job. Among other things, this takes industry contacts. These contacts are good at certain things. Take brokers for example. Some know office buildings. Others only sell apartments. Each has a geographic focus.

Brokerage is difficult for a similar reason. You need contacts who own buildings. You also need contacts who buy buildings. (Both are investors.) By definition, brokers need to match these groups. But each investor is good at certain things.

Because of this, it's important to be able to reach the right people for each deal. This requires organization and context, which take effort. Successful investors and brokers don't have much free time or patience. So, this product tries to optimize context vs effort. More context than your phone's contacts app. Less effort than a full CRM. It does this by using investment criteria ("targets") to connect people. Then it maintains a contact list based on those connections. You can share targets via link.

I'd be grateful for any feedback, even if you aren't familiar with commercial real estate. Thank you!
Because solutions to those issues never seem to come up in pro nuclear posts, only that the new reactors are safer and more efficient, while ignoring the issues of waste storage, expensive proprietary fuel and liability concerns.
I think this also applies to many kinds of low-grade chronic suffering. Changing your response to the sensation might be easier than stopping the sensation.
> Maybe shitty toy database systems like MySQL

While appropiate to define in few words some of MySQL's colossal mistakes, this isn't the kind of language that will sway heads that have been comfortably using MySQL because those defects are just "what DB's do".
Sure.

As @diminoten mentions, legality is questionable here, so I do not recommend. If you do dabble, restrict access, and encrypt everything so that if you lose your keys, they only option is to destroy the stack and start over.

Cloud provider of your choice

Plex media server running on a high-throughput instance, with cloud storage mounted locally for reading. (Redundantly created in multiple regions depending on where the service is being accessed from)

A separate master instance responsible for downloading content from a private torrent site, with cloud storage mounted locally for writing.

Multiple on-demand background workers that are spun up when new content is available to be reformatted in various resolutions. They pull the original video from cloud storage, create various versions, and re-upload it to the cloud storage.

The largest cost is in data usage, and storage.

@diminoten Not sure what I did to "oversell" it. I used off-the-shelf tech components, and some cloud-enginuity from experience, to build a proof-of-concept competitor. I didn't build the entire interface from scratch, or write my own OS, if that's what it sounded like.
Theranos founder Elizabeth Holmes wins courtroom skirmish
> I do want to reinforce that all applications need to confirm data integrity, you either confirm it when saving the data, when extracting the data, or have to very carefully balance various consistency concerns and either enforce consistency before saving data or enforce consistency after saving (but before extracting) data.

There are two kinds of error handling. The “happy error” and the “fuck you asshole” error handing. Good systems have both.

Yes, the application should check it isn’t about to violate a FK constraint. Just like it usually checks that it isn’t about to violate a unique constraint. That way the application can fail in happy, controlled way. But if the application doesnt do the right thing than the DB server still should puke all over the transaction with a “fuck you, don’t feed me bullshit” error.

Just like data entry over the web. The javascript can return all kinds of nice happy messages to the user about missing fields and stuff. But the backend should always validate and enforce correctness even if it’s mode of failure is some ugly “piss off, don’t feed me crap” message.

Just like you should never trust user provided data coming from an HTTP post, a database should never trust the INSERT or UPDATE is valid and won’t corrupt the database. Both backend systems can return mean old ugly errors when shit is bad and let the front end do pre-validation that can do happy nice errors. The backend always has to enforce its own data integrity. Period.
Hm, that is 'good thought fodder'.

My feeling on it though is that it just shifts all the faith to your test data being true to not only does but conceivably could happen in prod.

All very well testing with a bunch of constraints, but if it turns out one actually isn't exercised and then happens in production?

It also means you can't use them for validation or whatever. Which, I don't know, maybe you shouldn't anyway, but if you turn them off in prod you can't.
I feel like you're saying this sarcastically, but you should be saying it earnestly.
This approach is quite scary to me and I would have argued very vocally against their rejections of FKs. There are ways to rely on replication for read serving, periodic disabling of FKs during batch inserts, FK integrity checks on replications, ... these can all address the performance issues inherent in FKs, it's also (generally) quite possible to attempt to architecturally disentangle too large networks of interdependent data in an effort to reduce how large any single data store you are relying on will get. But disabling FKs in production is... eh.

I'd much rather see the opposite, declare the FKs on a testing environment NOT VALID, run application code, VALIDATE CONSTRAINT those you'd marked and see if anything is in violation - ensuring that application code won't (in the normal course of operation) generally hit FK constraints can greatly reduce your performance hit from having them... then in prod you can turn them on and be confident in your comparably lighter performance loss to data integrity.
Google hand-crafted a language with the intention to make the production of code for their most important use cases cheaper. It was never their intention to build the general-purpose PL of the future. But then, you cannot put it this way in your marketing brochure.
Given that the rostral (head) end of the neural tube literally bends inward (cephalic flexure) as it grows into the enclosed space of the head to later become the brain, and that the tip is also attached to a clump of cells that will become the heart (cardiac anlage) which is also migrating downwards with the tip of the neural tube and to the left side of the chest, it is altogether unsurprising that the brain should be slightly pulled to the left.
Ahah, newyorker.com doesn't allow visitors to use private browsing without being logged-in or subscribed. The clearweb is a scary place.
And you believe that letting the though ones win doesn't also end in pain for everyone else? Life needs balance, the strong ones, by definition, grab their own end and swing it.
> Purely functional algorithms and data structures are typically slower.

Functional persistent data structures bring many advantages, even to imperative programmers. For example, if your text editor used a persistent data structure, it probably wouldn't need to lock you out during a save and would support better undo.
Mutation is efficient, but comes with many drawbacks, especially when state is shared or provenance is required. This is why functional data structures and ideas are appearing outside of functional programming, for example ZFS, git, Blockchain, Spark, Kafka etc etc

> Imperative code is also more concise than equivalent functional code.

This couldn't be further from the truth. Just as Fortran liberated arithmetic expressions from the verbosity of imperative programming, FP allows us to move beyond non-compositional word-at-time sequences of mutation commands and build much higher-level abstractions. Modern imperative languages have borrowed many ideas from FP, but are still no way near as expressive as e.g. Haskell. Of course, imperative programming is still very useful and that's why Haskell has good support for it.
Doesn't this confirm the parent's point? You like the ecosystem, so Apple makes sure it's the only one with such an ecosystem - part of which is making cross-platform apps more difficult.
I'll jump in here as well in case someone is considering throwing out foreign keys due to this. I would argue, never make compromises like this unless you have a scaling problem that is so bad, that there is no other way around it. Don't get me wrong, there are places where this is the case, but 99% of software does not have this issue. Use foreign keys and save yourself the headache in the future. Also bear in mind, that if you ever hit that scaling problem, you are making so much money, that it's a nice problem to have.
I fixed one too many data corruptions to do away with FKs. If we are large enough that FKs are causing performance issues, then we are large enough to invest in and deploy another performance boosting solution while still protecting the integrity of our database from contractors/employees running around with direct SQL access (another nightmare unto itself, but one that I as a developer have less control over than if there are FKs or not).
This morning, my roommate and I were saying "Ok Boomer" and and forth to each other, then the Google assistant said "I don't know what you mean by Ok Boomer, Ok Boomer." It was kind of surreal, like Google couldn't figure out how to play.
In my experience, no one is irreplaceable once the company has a few hundred people. Sometimes people you think are irreplaceable leave without a suitable replacement and things will work out. It might delay a few projects here and there but as long as the company isn’t still trying to find an product market fit it’ll be just fine.
> we might wanna stop it if there is even the tiniest chance it is our own fault,

We might want to stop it even if it's not our fault!
The need for all four engines being operable isn't changed by the viability of 3-engine flight. Once the plane lands its grounded for revenue service, and even three engine ferry flights are a huge affair to pull off.

So, de facto, each engine is strictly required, and having twice as many as a twin, quad jets are half as reliable as a twin, all other things being equal.

(me: licensed dispatcher who worked with the BAE-146 for a time. Incidentally, "BAe" stands for "Bring Another Engine" <grin>.)
If the author is thinking of that kind of situation, he's right that ON DELETE CASCADE would be inappropriate, but he's also incredibly wrong to not want a foreign key enforcing that relationship. Deleting a user associated with invoices that should not be deleted is a big no-no too. A foreign key would not let the user be deleted until after the associated invoices are deleted.

There are plenty of other situations where ON DELETE CASCADE is the best option.
Go's stdlib has spoiled me. It was the first language that I used in any serious capacity, and I just assumed that all languages had stdlibs that were more-or-less equivalent in terms of breadth and design. Sadly that is not the case. I find it hard to get excited about any new languages these days if it doesn't have a good stdlib. I think Go has really shifted people's expectations in that regard.
>> spin up a bunch of worker processes as EC2 spot instances that check for the next PENDING task

Does that mean workers poll the database?
Sad, yes, but unsurprising. In the heyday of cable, consumers in aggregate proved that they are more than willing to stomach complexity and fragmentation to have access to a wide range of video content.

Sure, many people complain about it, and nearly everyone wants the same thing for less money. But it's been proven that despite the complaints and cost, people are willing to pay.
Thanks! I didn't know how to get by this paywall until now.
An instance, but in no way covering the entire picture.

One of the reasons why Google Chrome enjoys its monopoly is because Apple does a terrible job with its browser Safari. Terrible. I mean it's a train-wreck! Since iOS 10 or probably little later they have done nothing but destroy how the web apis are supposed to function, abusing every single accessibility guideline into something that is at best a line of defense to promote their app store.

I hesitantly moved away from iPhone X to Android Pixel last month.
Solar thermal is 2-2.5 times the cost of nuclear: https://www.energy.gov/sites/prod/files/2015/08/f25/LCOE.pdf

We could wait for solar thermal to get cheaper than nuclear (and assume that the cost of nuclear also remains static). Or we could just build nuclear power. The latter has the advantage of having consistent generation regardless of weather and time of year, and consuming a fraction of the amount of land.

Wind power has consistent output over long periods of time. But we still need to make the power grid resilient to fluctuations, which would require immense amounts of energy storage. To put it in perspective how infeasible energy storage is, take a look at California's latest energy projects. The current largest storage plant has 183MWh of capacity, and a planned one has a predicted 300Mwh of capacity[1]. By comparison, the Diablo Canyon plant generats 2,2000MWh of energy every hour [2]. These two energy storage plants can only store 5 minutes and 9 minutes worth of power generated by the Diablo Canyon plant respectively.

1. https://www.weforum.org/agenda/2018/11/california-will-repla...

2. https://en.wikipedia.org/wiki/Diablo_Canyon_Power_Plant
Who is hiring entry-level software engineers?
Who is hiring entry software engineers? Since most postings seem to be for seniors...
I don't personally develop anything using Electron. But given it's popularity as a way to build desktop apps, it seems reasonable that people are concerned even though they haven't also blocked QT or React
> Rust does good use of high-order functions, but gets nothing near the modularity of Haskell code.

This has not been my experience.

After years of doing pure functional programming (in Elm) professionally, I was surprised how much Rust felt like writing in an ML family language.

I still prefer referential transparency (though I don't think it would have been the right design for Rust), but "nothing near" does not fit my experience. I'd say the ergonomics of borrow checking versus a GC (which you don't have to think about) is the bigger gap.

John Hughes is a big believer in the value of laziness. There are many of us who believe laziness turned out to be a dead end; it makes some code nicer/more elegant, makes performance optimization much harder, and brings space leaks into your life. Are those costs worth the benefits? Not even close to worth it, if you ask me. I'll gladly take the referential transparency and pass on the laziness.

Almost all the researchers who started working on Haskell specifically because they wanted to explore the power of laziness...ended up pivoting to research type theory instead. I don't think that's a coincidence.
Looking back at the number of stupid mistakes, missteps, and general clumsiness which have come out of Apple's App Store review process, it's far more likely this is just another boneheaded gaff somewhere on Apple's review team.

This is quite clearly one of those cases where people are attributing malice where incompetence of one sort or another is almost certainly the cause.

Most likely either:
—This should have been nipped in the bud years ago when they added the private APIs to electron.
—They are taking a ham-fisted approach to cleaning up some App Store abuses.
—They've updated the tools they use to review App Store submissions.

Or maybe a little of all of the above. The big problem is Apple is again stumbling around with little or no communications to the developer community, fucking up a lot of developer's lives. This isn't some conscious malicious scheme... just frustrating corporate blindness.
It's deeper than that. Rejection of POSIX is the reason SystemD is Linux only; Pottering rejects POSIX compatibility and gives the finger to anything other than Linux. But in this case SystemD failed to even adhere to the [non]spec of "what Linux supports."
I do also believe that a comprehensive intellectual property is necessary (not necessarily abolishing it), so I sleep soundly.