skysight-inc/HackerNews huggingface dataset:
More accurately: such an environment requires paying a premium to compensate for the decreased job security. (As with any market, employees expect to be compensated for their higher risk with higher returns.)

Netflix, for example, and Amazon (to some extent) have gotten away with this model but the vast majority of companies are simply unwilling to pay top of market.
It is a common misconception that more data processing in SQL puts a higher load on the database. A typical database spends 96% of its CPU time on logging, locking, latching and marshalling [1][2] rather than processing SQL. By sending less data to the middle tier and performing fewer round trips, the use of stored procedures means that the database can actually do more real work.

[1] https://dzone.com/articles/mit-prof-stonebraker-%E2%80%9C

[2] https://drive.google.com/file/d/0B7jyeB8kxFPjU0VySkF3UHhoVnM...
Where are you getting this from? None of those features have a performance cost, if used according to some simple guidelines.

In fact, multiple dispatch is essential to get good performance, abstract types have a cost if explicitly used inside struct definitions, but that's why you use parametric types, and abstract types do not have a cost in function signatures.

Macros are expanded at compile-time, and at least have no runtime cost, in fact they are often used for improved performance.

I think there's some fundamental misunderstanding going on here, but I'm not sure what it is. Or do you mean to say that if it is possible to write slow code in a language, then only a subset of that language has good performance? If that is the case, I don't know how to respond.
Did Jonas Salk make the market more efficient?
Yeah, but Python is competing with Perl and Ruby, not C.
Common mistake, trying to replace humans with machines. Typical of penny-pinching bean counters and talentless middle-management chair warmers. But I don’t think Apple has ever understood automation (as any 20-year AppleScript veteran can tell you), so I’m not surprised Cook’s crew has failed to capitalize.

Complex automation works best when placed in the hands of skilled humans, as an amplifier of human ability. Let them use the machines to accelerate all their mundane repetitive crap, while retaining the human ability to make reasoned decisions and handle corner cases and errors intelligently.

But perhaps a more logical place to start is by automating away the penny-pinching bean counters’ and talentless middle-management chair warmers’ jobs? Dog knows they’re reliably useless at it themselves.
The easiest negative emotion to cause with a post is outrage, which goes nicely with fake news.

The easiest positive emotion to cause are at the result of puppies and wholesome/faith-in-humanity-restored posts, neither are generally related to actual truthful news.
Only for the record, that is Chesterton's fence:

https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
Deploying a public facing GPT-2 project without a GPU
Smart pointers + static analysis + sanitizers is the best options I am aware of for improving the correctness of C++ programs, and I don't think Rust really had much to do with them. The picture painted that Rust made the C++ standards committee scramble to start addressing safety seems wrong; it feels more like there's been a mostly steady increase in safety over time without need for any outside influence.
Typically, something like this: you do something stupid like use an alternative primary key scheme (which the database is agnostic about) and then your teammate accidentally omits a parameter of the primary key, deploys to production, the query misses all the indexes and causes an incident with downtime. You don't see this problem quite as much when you're staring at the schema itself and writing code against it.

More problems: default scopes causing large refactor pain, modular queries leading to accidental joins and index misses, models containing all of the combinations of models-to-be-rows, models-that-may-be-up-to-date, and models-that-have-already-been-deleted. I prefer explicit lifecycles to avoid semantic ambiguity when it comes to what data to expect where and wehen. Generally, all the places you would expect treating database queries as code against domain objects with different semantics than database tables.

Or, my personal least favorite game, "spend three hours translating this performant query into horrendous, unreadable ruby that technically produces the sql you wanted all along". I've found this comes up repeatedly with aggregate queries and joins and window functions.

Hey ORMs have their place, but I don't get the point of pretending it's even equivalent to SQL when they were built with completely different intentions and constraints.
Replacing the cost of 1 conductor every 200 passengers is not nearly having the same impact. Moreover as others point out, it has actually been done and there are automated
lines. Safety advantages are probably slim - when there's a train accident it makes news, because they're RARE.

It's also not going to significantly improve one's choice of transportation - you either have access to rail already, or you don't - regardless of who/what drives the train. Schedules are already tuned and if it was more profitable to put more trains, it would likely happen even with human conductors.
Whether or not you use an ORM, you ideally have your own abstraction on top of it, defining a set of known queries. This avoids the classic Rails problem where the User model has a million methods, and you don't know which of them might make a SQL query.

Also, ORM caching always finds a way to become a huge pain. It's easy to wind up with multiple objects representing the same underlying DB row, but updating one in memory won't update the others, so you update them all from DB just to be safe... You might say "find a better ORM" but I'm pretty sure they all run into this problem at some point. IMO you're better off doing it yourself and making it explicit.
Have Fun then, i have fun with my even less fiddli tech..like a normal watch, a real stereo and no pods....
Having worked as a DBA in numerous large financial institutions, and also as a SWE in a lot of node/python/MEAN-style startups. I can assure you that there are some very significant trade offs made with stored procs (or any business logic that is compiled to your database). It takes your one codebase and turns it into at least two seperate codebases. If you have a monolith, now you’ve got a distributed system. Any stored proc codebase is guranteed over time to become a maze of complexity and footguns. The more db features you use in this area, the worse it gets. If you’re using stored procs, then somebody is eventually going to create a table trigger. If a table trigger exists, then somebody will eventually write to that table not knowing it’s there.

The complexity it adds to release management alone makes it not worthwhile in a lot of situations.

It’s like doing full blown OOP design. Your codebase has to pass a certain (rather large) size before the complexity trade offs can even begin to make sense, and even then they often don’t.
My main reason to use ORM and why I recommend to others to use it (specially if they are juniors) is because it usually (depending on the language/framework) comes with great support for protecting against SQL Injection.

Of course not all ORMs will protect against SQL Injection completely and some of them will only implement partial protection. But it is a good start.

What I recommend strongly is not to mix ORM with plain SQL in the same line of code.

The code should either be full ORM or plain SQL so that it is clear where the responsibility of protecting against SQL injection should be.

Edit:

Also it is easier to add extra layers of protection after a while if using an ORM then when using plain SQL. Because with an ORM I can redefine lets say the Repo.all or Query.all method to add extra layers of protection. But with plain SQL I need to edit every single line where the SQL statement is present.
Instead of polarizing between massive native queries in ORM strings vs DB-specific imperative stored procedures I would suggest a middle ground which are table VIEWs [0]. They are trivial to design (just SELECTs), stay declarative like tables, can be materialized for efficiency [1]. Finally they can be easily handled in ORMs as both static and dynamic entities, with all read-only benefits, with no need of any non-standard mapping or native queries.

[0] https://www.postgresql.org/docs/current/sql-createview.html

[1]
https://www.postgresql.org/docs/current/rules-materializedvi...
Forcing kids back into school is insanely ridiculous; not for the kids' health, but for health and safety of everyone else around them because the kids get thrown into routine super-spreader events.

Furthermore, the new head of the Coronavirus Task Force, Dr. Scott Atlas, is an absolute nutjob (Hoover Institute disciple and ideologue, anti-masker, anti-isolation) without the necessary credentials (neuroradiologist) or skills for the job. The US (as of writing) already has 20% of the world's cases and 19% of the deaths despite having only 4% of the population. The only rational conclusion that can be drawn is that the US is falling flat on its face because of a lack of leadership.
Nowadays there are cheap alternatives on eBay/Aliexpress: https://youtu.be/daS5RHVAl2U

Although presumably they don't do audio...
Well, and here I thought that discipline doesn't scale because it is not a universal concept. Having "discipline" in C will not transfer to better discipline in other languages because each language has a different feature to abuse. C might have malloc/free with catastrophic consequences but C++ has templates which lend themselves to a different type of abuse i.e. excess complexity.
But it's not really a "me too" system - if you take geopolitics into account, it's very much critical infrastructure. Beyond securing uninterrupted access to GNSS for Europe and taking away US's leverage, it also grants EU a seat at the table for some decisions the US would rather take unilaterally. With a working GPS alternative, the next time US wants to invade someone, they won't be able to cut off their GNSS capacity unless they get the EU (and, I guess, Russia) to cooperate.

That said, I'm yet to hear of a large contractor that cares, no matter how critical a project. Private market to me feels, in general, like the school system: with standardized testing and modern curricula, we get consistent but mediocre results, but we achieve that by filtering out anyone who cares about anything other than gaming the system.
My preference is currently ORM + drop back to SQL when you need something that is complicated or inefficient using the ORM. I have been writing SQL for 20 years.

I currently use dotNet Core and Entity Framework + Dapper.

It has these benefits:
- Strong types!
- My schema+migrations are part of the source code and I never have to worry about if my schema is in sync - with migrations it just is
- Simple, straightforward tasks as super easy (insert, update, delete, simple select)
- I can fall back to Dapper (straight SQL) when I need to do something that doesnt fit well with Entity Framework.

I recently worked on a project where EF was not allowed - and we spent so much time doing all the simple stuff, especially when the data model was still not completely locked down.
Webrender is broken for me in 82 - I get a blank bar across the top of every page.
It blows my mind (as a 3rd worlder). Here almost all stores have security, and they're not just going to stand by and let you walk out.

Other stores have checkpoints at the exits and they'll verify your purchases.

Others will only let in certain amounts of people etc.

If the people's behaviour changes then you need to adapt accordingly.
I have also seen Matlab code match Julia for simple loops. If you write your code properly vectorized and with loops that use only calls to 'built-in' operators and C-functions, then it can match C/Julia.

But that's just extremely restrictive. The jit does not work on arbitrary user code.
Well as someone with 25 years SQL experience, I generally will still use LINQ for 90% of db access code in business style applications, for very important reasons beyond those mentioned, like

- They may realise value in having a compiler provide guarantees, as a bonus immediately in a tight feedback look while editing code as well as on compilation

- They have favour expressive languages with robust error handling, integrated IDE and VC etc

- They may want to reduce the number of moving parts

These are all along the themes of a) delivering results faster, and b) improving the maintenance lifecycle of systems - unlike those parts of the industry that don't really plan to maintain their systems and instead just wanna do rewrites in the latest hotness which is usually a hot mess from a long term maintainability perspective.
You would have to go to some obscure website to download some payload and read build instructions to see how to beat integrate it with your new cppenv program instead. That's the problem to solve, C++ is old and most of it written before those solutions existed, and most of it doesn't use the same set of tools.

Like I said, I don't think this isn't a problem or that a solution wouldn't be nice. It's just not functionally different from the myriad of existing solutions.
I have no problem with that, but don't pretend that someone is abusing your license when you didn't stipulate.

If fact someone should come up with a well written licence that adds conditions when the licensee revenue is over a certain (large) amount, like say royalties. Everyone should be happy with that.
You're completely right.

People are complaining about the side effects of capitalism and then blaming progressives.
Agreed. Enterprise 802.1X NAC policies are not compatible with BYOD users.
That's not Hibernate, that's Spring Data or some such, which is indeed cursed. This bit of Spring was absolutely designed by and for people with no critical thinking ability.

Meanwhile, JPA, the standard which Hibernate implements, has a textual query language [1] which is basically SQL but a little more objecty. For example, you can express joins through properties concisely:

SELECT c.capital.name FROM Country AS c WHERE c.name = :name

And use constructor expressions [2] to map results into Java objects:

SELECT NEW example.CountryAndCapital(c.name, c.capital.name)
FROM Country AS c

[1] https://www.objectdb.com/java/jpa/query/jpql/structure

[2] https://www.objectdb.com/java/jpa/query/jpql/select#Result_C...
Yes, I love Nix. The only caveat is that it does not work on Windows...
'SOP = Same-origin policy': https://codeberg.org/nobody/LocalCDN/wiki#user-content-7-a-w...
Yes, but it’s much more politically convenient for the incompetents in charge to blame the dumb machines than themselves for their multi-million $$$$ project collapsing on its arse.

Steve Jobs would’ve flayed the lot of them till he got exactly what he wanted. Cook’s mediocrity simply shrugs and rolls on, with nothing learned at all. #PerfectlyOiledCuckooClock
You don't, if your application code is not OOP.
The title suggests that you would be better with no ORM, just SQL. I have not been coding for years - but still remember why ORMs came into being - before them there was lots and lots of repetitive code with the query preparation and execution with long ugly constant strings and string manipulation. With ORMs (and query builders) it all became much more compact (and looking better without the uppercase SQL). As every programming abstraction it is not perfect and you still probably need to learn SQL if you use ORM - so you need to learn both.
Why article writers always assume everyone knows all their abbreviations?
Although I think learning C opens up your accessible domains of programming widely. I mean, if you know C it doesnt even take a weekend to learn (the basics of) CUDA. Or you can just buy an simple embedded system and do data aquisition easily. Also there is a reason C is often under the hood of other programming languages like Python, Tcl, and (I read on the internet) Julia, Ruby and Perl.

I dont mean you can then write these languages, but you can look under the hood and read the source code (also if you want to write extensions it is useful).
> Right, I've been telling you it's not relevant for the past three comments now.

but it is ! the only reason why ODR is UB in C++ is because the C++ language authors can't force the system linkers (again, whether at link time, load time or runtime, I'm not only referring to dlopen) to perform LTO which trivially makes ODR violations a diagnosticable error.

But as far as I know, neither can the Rust language authors do so - so either the behaviour in Rust is as defined as in C++, or Rust does not support creating standard platform object files that are linked by ld, gold, or whatever (such as D, ADA, Fortran etc all support) which would make a fair amount of use cases impossible - it's pretty common in some HPC circles to link C++ and Fortran directly in the same executable for instance. And then, of course it's easier to define behaviour when you use a reduced set of constraints, but it definitely does not makes something worth bragging about.
> But perhaps a more logical place to start is by automating away the penny-pinching bean counters’ and talentless middle-management chair warmers’ jobs?

I readed this on HN and your comment made me remember it.
https://marshallbrain.com/manna1
We removed support for non-JSC engines immediately after the Blink form.
Everything is big and old, so there are multiple ways to do it and making them work with the old ways is sometimes trouble. If you wait a couple of years Rust will be like that too.

cppreference.com is good and hast almost everything you need.
I've seen this post and similar ones many times. ORMs don't fit all scenarios, but most of the time it's a question of when you fall back to something more flexible/powerful. In Rails, writing the crud part of your app with SQL is pointless. Trying to get AR to do dashboard gymnastics is equally pointless. Pick the best tool for the job.
An interesting upcoming graph database is oxigraph. It's written in Rust and might be able to cope well in 2GB.

https://github.com/oxigraph/oxigraph/
I think the real problem with the tremendous fear people have of shark attacks is that so many people do survive to tell the tale precisely because they don't particularly care for what me and my sons classify as "land food."

Great White sharks are eating machines, not killing machines. Of course, things tend to die in the process of being eaten, but they aren't looking to murder humans. They are looking to feed.

And it just so happens that they have a giant mouth full of a zillion teeth, so when they go to taste you and see if you are anything tasty, they rip off a leg.

And we know they don't really want to eat you in part because of the relatively high percentage of stories that end with "And then my leg washed up on shore three days later."

So the Great White isn't a murderous killing machine. It is a callous, heartless Cthuloid Horror that doesn't give a damn about you at all and often doesn't so much as deign to swallow the arm or leg they ripped off while wondering if you were a seal.

This is why we fixate on them and make horror movies about them and so forth. If they were actually killing machines who liked eating people, we just wouldn't go in the water at beaches because the incidence of shark attacks is actually so remarkably low precisely because we aren't what they really want to eat. If they really liked feeding on "land food," the incidence of shark attacks on humans would be so high that people just wouldn't go in the water -- because it is shockingly common for there to be sharks nearby in the waters of a crowded beach and they just aren't chomping on people.
I do not think that memory is the biggest problem here, with RAII it "only" requires medium discipline, but UB is the dragon in the closet here. Avoiding UB requires a huge amount of discipline (or luck)
You've got it backwards. The creators of React have clarified this many times as well. The vdom is an implementation detail, components and declarative render are the motivation.

The vdom is interesting, but the right history isn't starting there. The premise was the ability to build bigger, better, more reliable, easier to understand/maintain/refactor apps. Components with declarative render + top down data flow enable that, vdom is just the only way to make it work without being too slow.
Well, discipline is indeed difficult to scale; however:

* There is no automation for writing good code and for good design - and that too requires discipline.

* In many cases, harnesses which relax discipline requirements have costs: dependencies, larger surface area for compromising security, performance...

* Very often, the mass of undisciplined coders rely on libraries and other core pieces of code written with a lot more discipline.
I have come to the same conclusion as the author.

In go I use rql: https://github.com/a8m/rql

Which I ported to c# for use in .NET: https://github.com/Ashtonian/RQL.NET
That fear may be true for candidates without experience and/or university degree. But why is it still present for candidates with lots of experience and education? In other words, if other technical/engineering disciplines can manage without this absurd hiring process, then why can't IT field (leaving aside the candidates without experience/higher education)?
Editing stored procedures and deploying them on a database is the same as editing code deploying it on a server. There is no difficulty in versioning it
I’m interested in this because I have the opposite experience. Not saying any choice is wrong, but in my experience, moving that logic into the database has made all our codebases easier to reason about. The API’s don’t have to botch error handling due to “open transaction need to be ROLLBACKed”, I don’t have to worry about bad devs doing stuff non-atomically and putting the db in a bad state, and the code is easier to read because it’s just a single query that does “what it’s supposed to do”. The API usually ends up just being a small adapter for DB functions. It also makes sense to me because the “database API” (e.g. the database schema with some methods in it - the tables themselves are usually not in the same schema) describes the valid operations of the data, and can make sure the data is consistent. It also makes adding new APIs easier.
There is a middle-ground... helpers.

Things like search interfaces might offer filters over multiple columns... your choices here:

1. Use an ORM

2. Write SQL for each permutation of filter

3. Write a helper that will compose the SQL based on the filters needed

And that 3rd one is the only time I stray from plain SQL towards something that looks like a lightweight abstraction over the SQL.

Similarly... stored procs, I avoid these but there are times when they are necessary. If you need the boundary of a transaction to span multiple SQL calls then it is safer to do so within a stored proc. Yes you can use a transaction and rollback, but from a maintainance perspective I've seen refactors break transactions that were not fully encapsulated in a single Go (insert other language) function .

Yes keep things simple with SQL and do everything in the application... but also break those rules rather than do something daft or with side effects.
I'd also add that if it's a community-based open source project, there can be great benefit in more safely supporting a bigger set of database engines (e.g. sqlite for the simple entry-level, postgres et al for the more serious) at the cost of some performance overhead.

If it's a performance-critical in-house service where you have full control of the deployment and can tailor it to your use-case, it's a completely different story.
Even cars are being glued nowadays. Glases, aluminum roofs, etc. There are dozens YouTube video about car body repair and glue can be found in surprising places. No solid metal screws or welding points.