But if you get throttled in the first place that means you're going to have some kind of performance degradation since your server was using more than the baseline level. Web apps being IO bound isn't relevant here, because the only requirement for issues to arise is for your server to have consistent 20%+ cpu usage.
No way t2's are a good choice for your average webservice. You don't get the full CPU with t2's. With a t2.medium if you're using over 20% of the cpu (40% of 1 vcpu or 20% of both), you're burning CPU credits. So unless you have a webapp that uses 8gb of memory yet stays somewhere under 20% cpu utilization (maybe with some peaks), you'll eventually get throttled.
t2's are for really bursty workloads, which only makes sense for a webservice if you aren't handling much traffic in general and you have maybe 2 instances total.
Ok, but my core question still stands: why? I'm with you in thinking that noreply addresses should go away, but I don't see how this could be an effective measure to stopping them. A company isn't going to care about this, statistically speaking. Everything you're describing sounds tedious for no gain.
This is odd, what do you gain from this? Chances are this will not get seen on the sender's end, and if it does they won't care, statistically speaking. Many noreply addresses are transactional emails (ie, emails you trigger by doing an action), so it seems maintaining a whitelist would be a chore.
When "type safe" is mentioned without qualification, it almost always refers to static type safety. This is one of those times. So no, the sync.Map container is not typesafe like a regular map is.
Views are only a solution for reads, not writes. FDWs are not an elegant solution to anything related to this. Think microservices that already have an api defined.
IMO modeling your api directly off of your database tables is often an anti-pattern. One of the biggest mistakes I see people make is assuming their api's data model has to match their database's. It's common to introduce resources on the api side that may not have their own table in the database. For example, you could have a table that has a "type" flag (to model some kind of inheritance), but on the api you expose these as separate resources. Or you could have a larger resource on the api, but it's actually backed by several tables.
Graphql is also more generic and allows you to fetch from multiple data sources. These could be databases, apis, or wherever. You write code that fulfills each column and graphql assembles a single object.
I could see postgrest being ok for prototyping or simple apis, but it seems like one of those things that you'd grow out of eventually.
What about uploading files, video and voice chat, scrollable and searchable chat history, code snippet support? These are the reasons people use slack. To say IRC is a substitute means your company doesn't need to solve these problems (which is fine, they may not have them) or it means you're using a bunch of products together to solve them.
I don't get the stance that this is "hype" or a "bandwagon" at all.
I don't see how you get that. Slack does tons of things IRC doesn't. IRC is not a valid replacement for the entirety of slack. To choose IRC means deciding that you don't need or want the rest of slack's features.
That's only needed to convert old callback style code to promise-compatible code. Most libraries either return promises now or have an option to, so this isn't necessary.
Is it? I only do some moderate node work, so I could be missing the discussion on this, but I've never seen this brought up or talked about before. I read the blog posts, but is this really a sweeping rule in the js community or is it just the opinon of a few people? Because no one seems to be doing it.
Oh please. The point of the post was to illustrate the feature to those wondering "what's async/await?", error handling would be complete noise for that purpose.
You're missing the point. Saying "they raised capital" is not a good counterargument to "it will hurt adoption". Your response would be a good counter to "they will never raise capital" or "no one will use this".
You can't know how many VCs didn't fund due to the name or how many tech decision-makers at companies will pass on this product due to the name. That being said, I doubt it will be/was significant in any case.
There is absolutely 0 chance in the time you've written go that you haven't encountered a problem that would be best solved by generics. Chances are you're just implementing them in a different way. I say this as someone who uses Go.
Ironically netflix does the exact opposite. Also, you definitely don't want to have the content on the cloud - the data transfer pricing is where they make significant profit. Both AWS and GCE are ~$100/TB outgoing.
Why is it always colo vs cloud in these arguments? What about renting everything monthly from ovh, rackspace, softlayer etc? Many of them can provision dedicated servers within minutes, too.
It's far too late for that. REST as you describe it is not commonly known as REST. People refer to it as HATEOAS or "real REST" or "hypermedia REST". Just saying REST without qualification refers to resource-oriented json based apis.
How? At the end of the day you're still writing an "if" statement branching on a piece of data in the response. In a regular api it might be canEdit, here it's the http verb in an array.
It's not fair to compare these since Aurora is a traditional relational database. It does not have a horizontal scalability solution aside from read replicas.
I don't see how this would matter. The datapoint is tag frequency on weekends for a given language compared to tag frequency on weekdays for the same language. It isn't using absolute numbers nor is it comparing cross-language.
How does that matter? Anyone who uses this defines them in groups one after another. You aren't looking at the punctuation at the end of the line, you're looking at the following line to see if it's the same function name.
You must have a very particular idea of what "functional" means to include JS. What definition of functional programming does JS meet that you can't apply to nearly every language? It can't be that it just has first class functions, lambdas, or higher-order functions: many, many languages have that.
Functional languages emphasize immutability. Javascript does not do this. Clojure[script] does.