> Two or three lines gives you about 80% of the value in any ORM and avoids the -20% value found in the other 100k LOC.
I have a hard time believing this when the two lines above are obviously wrong. You can't use :column to escape the name of a column in SQL. So your code has to protect it, which is not easy if you wan't to be portable. MySQL will generally use `column` but may be configured to use the standard "column".
Anyway, selectAllBy() and selectOneBy() are not enough to be confortable. I appreciate the static completion in Something.find({id: 1}).complete, the relative queries like Post.find({id: 1}).author, and many other things that help against typos, help code faster and make the code more readable.
I agree with the OP that fallthroughs are much needed, because writing custom SQL is sometimes simpler, and sometimes much more performant. Usually, its mostly about writing SomeModel.findAllBySql() which most ActiveRecord implementations provide.
> it's very difficult to identify which layout is most efficient
Don't worry. The compiler will figure it out. And this time the compiler will have AI™.
> the killer is that dead silicon tends to be a LOT of silicon for any given program
Part of the idea here is that the cost dynamic has changed. Silicon is cheap compared to power so even if you have lots of chips not being used at any given time as long as they can be fully powered off total system cost (capex+opex) is still better.
> why it would work this time
The difference is scale. If you are running millions of CPUs and adding 100k's per month then something like this could work, assuming the AI™ magic that figures out which new chips to build.
The physical technology is real and probably coming soon but it will be limited to incremental improvements to the existing CPU/GPU compute architecture from increasing bandwidth and decreasing latency until the magic compilers arrive.
If I'm understanding you right, what you're suggesting is that the individual silicon modules will be fixed, but they will be contected in a single package in lot's of different ways.
If that's correct I'd love to see the cost of making the trip between the modules. I've got to imagine the cost of that is just huge. The interconnect is also crazy - it's easy to do complex routing tasks on silicon at high performance. I don't know how you acheive that in a scalable fashion between silicon.
I can't imagine many use cases where $1.44/hr is a significant cost.
If you sell audiobooks, then a one off cost of a few dollars to convert the book to audio form is tiny compared to the authorship of the text.
If you are doing something like turn by turn navigation, clips are typically only a few seconds long, so very cheap, and again, many of your users will be needing the same clip, so no need to pay for it twice.
I've been using it for one of my projects but it just requires one-time use of the audio. As in, I use the text to speech to create audio files which I just recycle. Overall, it is more effective compared to using my own voice or hiring a voice over person to do it.
The other absurdity is the nerve of these western "human rights" organizations to believe that they should dictate morality and law for the entire world.
China's censorship is no different than censorship of hate speech in the west. They have just as much right as us to decide what acceptable speech is for their country and they have just as much right as us to demand that businesses operating in their country follow the law.
It was required to comply with US laws against exporting strong cryptography. In order to have a global standard the protocol had to be decoupled from the crypto implementation and clients had to be able to negotiate down to the (broken) crypto approved for export.
> const selectOneBy = (table, column, value) => { const res = selectBy(table, column, value); return res && res.shift() }
Two or three lines gives you about 80% of the value in any ORM and avoids the -20% value found in the other 100k LOC.