cle

77 ms·

871.
by cle 7y ago
Dynamic languages (so you can hack together stuff and quickly bypass any roadblocks), with REPLs (quick feedback and avoiding writing tests), and low cognitive overhead (so new folks can ramp up quickly). Some example languages that come to
872.
by cle 7y ago
Oh definitely there are valid use cases for these, was just sharing my experience with them for my use cases. We moved off of T2’s and back to C’s because of the unpredictable behavior under load. IIUC, T3s by default just bill you more in
873.
by cle 7y ago
It’s a lot easier and safer to scale hosts horizontally than vertically. You can predict the limits and behavior of each host, the VMs/processes on each host don’t need to deal with fundamental resources changing, etc. For services I
874.
by cle 7y ago
It is the customer’s problem, so it is jointly a problem for Android and the OEM. Google may try to abrogate responsibility here as usual, but it doesn’t make it any less their problem.
875.
by cle 7y ago
That's pretty reductive, it's more like "Click a checkbox and we'll run your code for you, take care of OS security updates, compliance requirements, autoscaling, load balancing, AZ resiliency, getting logs of your box,
876.
by cle 7y ago
The same problem exists for most advancements, it's not a new problem. You could say the same thing about cars, for example.
877.
by cle 7y ago
I haven’t had any issue with them. I certainly like them better than Java annotations, which encourage way too much black box magic and induce too much code coupling. The fact that they’re a little awkward to use is good, nobody should ha
878.
by cle 7y ago
Handling JSON is the one place where I’ve used interface{} and not felt dirty. Sometimes you really do need to model “anything” or “whatever”, especially when passing around arbitrary data without making assumptions about its schema.
879.
by cle 7y ago
Very vague article. I would say that the #1 reason to split a monolith is if your engineering team has grown too big. The main advantage in my experience of “microservices” is that they allow groups of engineers to build & deploy wit
880.
by cle 7y ago
That’s effectively the same as having an incorrect/out-of-date runbook. Except the likelihood of that happening with automation is much lower if you write tests to ensure they work when deploying. There are always some break-the-glass
881.
by cle 7y ago
The best runbook is the one that doesn’t exist. Automating operational work vastly decreases risk, and gives you mechanisms to address many of the points in this article (you can write audit logs, tests to ensure your automation works when
882.
by cle 7y ago
In practice, reading a for-loop has been less problematic for me than reading the incantations of a functional programmer who’s been reading about category theory. I know all about the virtues of functional programming patterns, and use the
883.
by cle 7y ago
How do you propose we deal with the complexity?
884.
by cle 7y ago
I don’t know what the Go designers think about this, but I can at least appreciate the tradeoffs of not having map/filter/etc. Memory allocations remain clear and explicit, errors are handled consistently, concurrency is explicit
885.
by cle 7y ago
The queue sits behind a service. If you don't do the work in the service, and do it in a queue instead, you've got more infrastructure to manage, monitor, and autoscale.
886.
by cle 7y ago
Queues introduce entire other dimensions of complexity. Now you've got to monitor your queue size (and ideally autoscale when the queue backlog grows), and have a dead letter queue for messages that failed processing and monitor that.
887.
by cle 7y ago
Or I can use a hosted queue service and not have to worry about it at all. The less I have to worry/configure/optimize, the less room for mistakes, and the more operationally solid my system will be. My point isn’t that Postgres
888.
by cle 7y ago
I’ve seen confusion over reduce happen in Java, Ruby, Groovy, JavaScript, Scala, and Python. Reduce is quite elegant for certain kinds of problems. But in most practical settings, knowing when to reach for reduce vs something else is hard
889.
by cle 7y ago
Indeed, and they are even worse than that, because Streams in Java can even be parallel streams and be processed by a thread pool. So it’s not enough to know that it’s a Stream, you have to know what kind of Stream, and if it’s a parallel
890.
by cle 7y ago
Of course, this should have been the approach from the beginning, and it boggles my mind why people pick technologies or paradigms without considering their requirements and the tradeoffs of their technical decisions. I think part of it is
891.
by cle 7y ago
I’m well aware of how to deal with the problems created by unchecked, stack-unwinding exceptions. The thing is, when I’m reading Go code, I can look at a call site and easily know if an error can occur and what happens to the error (includ
892.
by cle 7y ago
I mentioned MVCC with respect to vacuuming, not the queue.
893.
by cle 7y ago
I've seen more bugs due to the cognitive overhead of reduce than writing a for loop. And then you don't have to wonder "Hmm is this a lazy stream? Concurrent?" You just look at the code, and know. (And I almost did a
894.
by cle 7y ago
Sure it works fine until you start multithreading, where handling an exception doesn't end with unwinding the stack, because there are multiple stacks. So then have to pass it as a value to some other thread's stack, and rememb
895.
by cle 7y ago
https://www.postgresql.org/docs/current/sql-notify.html > There is a queue that holds notifications that have been sent but not yet processed by all listening sessions. If this queue becomes full, transactions
896.
by cle 7y ago
At the scale I operate at, I wouldn't consider this a viable option. What's the backpressure like on NOTIFY/LISTEN? (Docs mention a maximum backlog of 8GB on the message queue, is that configurable? Monitorable?) Tons of
897.
by cle 7y ago
Go's call-by-value semantics give you similar benefits. Just different tradeoffs (because there are downsides to immutable data structures). My understanding of Go's design aesthetic is that it prefers to be explicit about thin
898.
by cle 7y ago
Step one: don't get paid for showing non-genuine search results.
899.
by cle 7y ago
The Internet is changing because people who use it are changing it. This is what happens with tools. The Internet’s current state is a reflection of our societal values, which I think is what you’re really decrying.
900.
by cle 7y ago
The AZ for an instance is fixed. Check it at startup time, and cache it in-memory.

More ›