I do that, too. But I didn't always have to, and I shouldn't have to, that's my point.
4,485 karma · joined June 1, 2012
> Efficiency in the BEAM is mainly in service of its primary goal of fault-tolerance. If one process crashes unexpectedly, the others should continue. By the same logic, if one process is CPU-intensive or IO-blocked, the others should keep making progress smoothly. And if processes are good for isolating errors and performance issues, they should be cheap enough that we can run a lot of them at once. Those assumptions are baked into how the BEAM manages processes.
If raw speed is your only goal, the BEAM probably isn't the best choice. If consistent speed and stability matter, it may be.
More on this at https://dockyard.com/blog/2018/07/18/all-for-reliability-ref...
Not many people can play bagpipes, so supply is low. But not many people will pay to hear bagpipes, so demand is low, too. Bagpiping doesn't pay well.
Nearly everyone needs food cooked, so demand is high. But nearly everyone can cook, so supply is high, too. Cooking doesn't pay well.
Not many people can do surgery, so supply is low. Many people need surgery, so demand is high. Surgery pays well.
Supply and demand explains why surgeons make more than teachers, why basketball stars make more than nurses, and why programmers make more than janitors. It isn't about how hard something is or how noble it is. It's just supply and demand.
What I want is for spammers specifically to be identifiable and blockable, or for their business to be made prohibitively expensive. I didn't get spam calls on my cell phone 15 years ago, and as you say, what has changed is largely economics. Why can't we work to adjust the economics back?
If feature X stops working because a back end developer broke the code, that's treated as a bug.
If feature X can't be used because a UX developer obscured it, that should be treated as a bug, too.
Q: What gesture should be used for answering a call on a touchscreen phone: tapping a button, or swiping?
A: I don't know, but once you've picked one and users have learned it, don't suddenly change it without explanation and make your users panic because they can't answer calls.
OTOH, `\d users` in PostgreSQL is authoritative; there cannot be a row that does not conform to the fields, types, and constraints listed there.
Yes. OTOH, with NoSQL you have no authoritative schema; your code may allow for multiple different schemas, and your records may have multiple different schemas, and they could agree or disagree to any extent.
This is well-put. I'd go further: if there's no schema, you don't have data at all. A row with labelled email and name fields is data; a string of free-form input in which the user describe him/herself is not data. You might possibly be able to extract data from it, but if you do, you'll be building a set of labelled fields.
> You can tell that your code's implicit schema exists even with an SQL database, even if your code auto-reads the SQL schemas, by asking what happens if the DBAs decide to rename a bunch of tables and a bunch of fields in those tables, maybe dropping some and adding others
Maybe a quibble, but I'd say your code has partial knowledge of the relational db's schema, not that it duplicates the schema, just as it may have knowledge of the file system structure, the domain names of various servers, etc, and depend on that knowledge being accurate, without duplicating them entirely.
> In some ways NoSQL is more honest than SQL, because it tells you straight up that it's entirely up to your code to have and maintain a schema.
With a relational db it's not entirely up to your code to have and maintain a schema. Eg, your code can assume that every "user" record has an "email" field and that it's NOT NULL and always a string and always unique, assuming the db is set up to guarantee that. The part of your code that reads records can be sure of that, even if the part of your code that writes records is lax about checking (and therefore blows up a lot). With a NoSQL database, it's possible that some records have blank emails, or numeric emails, or don't have that field at all, or have that field named something different. Those things will happen unless you're very careful to ensure in your code that they don't, and also unless you're careful to never to let anything write to the database except your code.
I think a differentiating question is "what is it that guarantees all your records of type X have the same schema?" If you use a SQL database, the answer can be "the db". With NoSQL it might be "a combination of app logic, background jobs and manual intervention for weird cases" or "nothing".
In cases where you want to store JSON blobs, an RDBMS like PostgreSQL lets you have a JSON column. This is useful (eg) for cases where you need to capture some input now, and might get around to parsing it out into real data later - eg "we got these records from the legacy system and don't yet know if / whether we can import them".
Finally, although I wouldn't advocate moving complex application logic to the database, there are some validations that can only be reliably done by the database itself or by leaning on the database. Specifically, any validation that relies on the current contents of the database, such as "don't allow duplicate user names" (unique constraint) or "don't allow creating a comment for a post that was deleted" (foreign keys) or "don't allow overlapping reservations" (PostgreSQL exclusion constraint). Application code can do a read, check, and insert, but two threads may have a race condition and insert conflicting data. Application code can ask the db to lock while it does this, but that's leaning on the db. Or the database schema itself can guarantee this in a safe and performant way. But only if the database has a real schema.
Also, crypto guarantees cut both ways. Which is more likely, that your account will be illegally taken from you, or that you'll lose your account password? In normal banking systems, the former is very unlikely and the latter is fixable. In crypto coins, the former is impossible (assuming nobody can steal your password, which is untrue) and the latter is unfixable.
Revoke how? Does the state, or anyone else besides Bob, have the authority to unilaterally modify the blockchain? If so, why don't they just use a central database, since you are forced to trust them anyway?
There would be some markup so the owning company has a profit margin, but the higher the price is, the greater the incentive for competitors to exist, which would exert downward pressure. So maybe you'd end up paying 1/20 the price of owning a car.
If you don't agree, why not?
I was nodding along at this until I read your second paragraph, then had to go back. Apparently you think this was a bad thing?
Losing touch with people is natural. Having to explicitly sever a relationship is awkward. But without a natural pruning function, it's easy to end up with a thousand shallow relationships and not enough deep ones.
You could say that Facebook is just as bad, but 1) I don't install Facebook and 2) I still trust the US Government more than the Chinese one.
Industry solutions are supposedly forthcoming - see STIR/SHAKEN standards for caller verification. T-Mobile says they're doing something with this: https://www.t-mobile.com/news/caller-verified-note9
> "We can't send mail more than 500 miles," the chairman explained.
Also, Devin Torres, author of Poolboy, wrote https://devinus.io/the-excitement-of-elixir/ and https://devinus.io/elixir-its-not-about-syntax/
Great point. Also, imagine that you control the server and you know that it was compromised. Surely you want to be able to download logs and other files from it for inspection without having your own machine compromised.
José Valim was the one who added "Add {continue, Term} and handle_continue/2 to gen_server" - https://github.com/erlang/otp/commit/69e009e3e1ad899a4609ff3...
José's contributions are at https://github.com/erlang/otp/commits?author=josevalim and Michał Muskała's at https://github.com/erlang/otp/commits?author=michalmuskala - there may be other Elixir devs in https://github.com/erlang/otp/graphs/contributors. (I even got in a tiny optimization myself once: https://github.com/erlang/otp/commit/07b0f4315b079cce7aeef7b...)
> your SQL database
They mention "a declarative query API", but as far as I can tell that's not actually SQL, right? So migrating from another relational db would require learning a new query language?
And yes, non-transparent targeting of opposite fact claims to different voting blocks is quite different from "put a TV spot on Conan because the young people like him", not least because anybody could see the spot on Conan, and because TV advertising is regulated.
On the other hand, you could easily argue that almost everything is "just business". The doctor is there to treat you, not care about you, your boss is there to extract labor from you, not care about you, your child's teacher is there to impart knowledge, not care about her.
Such black-and-white separation of concerns doesn't really fit well with being human, IMO. In most of these cases we want something less than intimacy but more than indifference.
Selling the ability to target different demographics of people with different deceptive and divisive messages to foreign government agents is also bad.
We can recognize both of these things, and perhaps even find a common root cause.
Eg, most people don't have $1 million in the bank. If all the financial advice you can read on the internet were written by millionaires, it might (eg) encourage risk-taking that isn't wise for average people. But you could get the impression that such behavior is normal and expected, since "everybody" says they do that.
Personally, I had a good friend mentor me and point me at things to learn early on, which helped a lot. A structured program would have the same benefit.
I have no connection with it, but https://lambdaschool.com/ looks very interesting in that they bet on your ability to get a job: you pay nothing unless you do (other than the opportunity cost of spending the time to learn, which could be large).
That's a rather cynical take. Imagine a politician you disagree with - be they a fascist, communist, libertarian, or whatever - tweeting something blatantly false. And imagine that they block replies by everyone who contradicts them, making their replies a chorus of agreement. Wouldn't that seem to be an impediment to civil discourse?