> ..., not to mention wasting enormous amounts of hardware and electricity.
I wonder how legitimate this concern is from an environmental angle. On one hand a lot of code in the world probably has much worse performance ratios than than the one described in the article -- using python is sufficient to cause an order of performance loss. On the other hand data centers are using more renewable energy sources and reducing their carbon output.
Is this only a wasted money problem? How worth while is it to write "green code"? Back of the envelope calculations on how much developer comfort costs would be interesting.
I usually don't defend Windows, but, rename not overwriting (without an argument) seems safer as a low level API, no? Given it takes a 2 line helper to achieve the same thing in C++ [1], doesn't seem that bad.
> I think encouraging a culture of distributing software in such a fashion is an incredibly bad idea
It isn't obvious to me how that is dramatically different from traditional package managers as far as the update process goes. Upgrading decencies seems like a generally active and involved process as far as most package managers I've seen go.
pip/apt/npm/go-get/glide/yum/nixos etc all require you to actively discover and upgrade your dependencies and I've never been prompted to upgrade a package from any of the programs (a few do ask if you actively engage special subcommands on CLI e.g apt list --upgrade). Unattended-upgrades might be close but you can really only enable that on security releases and most package managers don't have the resources to setup special distros (and fewer backport security fixes).
So is the pain really just not having a quick upgrade cli and is that dramatically different from going to a github page and getting the new URL for a new binary? Would something as simple as writing a script to list and download versions of binaries from github releases make this a non issue?
By building a phenomenal chat app and gradually (deliberately) building features around it to create a complete WeChat-like ecosystem, Telegram will probably improve people's uptake of chat-centric utilities in the markets they're targeting.
I think the fundamental component to their success is just how snappy and 'live' their chat conversations feel. Everything including their backend perf, chat bubble animations, etc seems to be finely tuned to make conversations feel alive and active.
I wonder if there's a complete version of something like this out there. You can probably get pretty far staying in Python-land, plus, everything else is free (data types, standard library, adoption, etc).
Northern Virgina has quite a few areas including Tysons that would 'fit' (it is HQ to "Intelsat, Gannett, Hilton Worldwide, Freddie Mac, Capital One and Booz Allen Hamilton") [1]. Montgomery County, on the other hand, is definitely a weird choice.
Foremost, it was written by a human and unintended language contradictions are common. With that said, what you're suggesting isn't necessarily true -- the language can also indicate potential false positives, again because of the nuances of language.
I can easily think of a few good reasons (it is actually a pretty good database for the right use-cases). Can you actually not find a good reason or are you just continuing the exaggerating echo chamber around mongodb's earlier failures for 'points'? Plus this has very little to do with the article which is a very very well done technical analysis of different solutions with very little opining.
This reads like a case study in one of Nassim Taleb's books.
> stress, competition, and choice involved in trading financial instruments naturally give rise to illusions of control
> I’d never really experienced the extreme tail of a probability distribution firsthand. And that experience disabused me of more than one illusion.
> But what’s the alternative to estimating probabilities?
The implied inevitability of another crisis over the new-ish stress tests is very saddening. I wonder what can be done.
> The danger is that the financial system and its regulators are moving to a narrow risk-model gene pool that is highly vulnerable to the next financial virus,” he wrote. “By discouraging innovation in risk models, we risk sowing the seeds of our next systemic crisis.
What sort of compression do the blocks undergo? E.g. does periodicity of the timeseries help reduce the the space of the 64/128bit timestamp? Gorilla[1] style compression would be great, although it'd likely make sub block level range queries tough.
> requiring you to have a strong JS frontend background in the first place
Is that a high bar for a JS frontend framework? Serious question, as it doesn't seem that way to me. This seems analogous to saying "Django docs require you to know python" or "Postgres docs require you to understand how databases work".
> Russ discovered—that's the right word—that the generality of Go's methods meant that a function could have methods, leading to the http.HandlerFunc idea...more general ideas too, like the the io.Reader and io.Writer interfaces, which informed the structure of all the I/O libraries.
Big testament to great interfaces being hugely impactful. For me, the IO and HTTP interfaces are a big part of why Go is so nice to use; the libraries (including std) that emerged around those interfaces and their subsequent interoperability makes everything so coherent.
> Just do some small spot checks to make sure they aren't taking credit for the work of others.
Agreed, asking tough technical questions on this front gives a really solid indicator of a 'bullshitter'. For example, I often ask people to diagram a prior project architecture they worked on, and then ask them very fine details of how things work and try to challenge them with alternative approaches to see how they react. I get to experience working with them during the interview through which I learn if they're smart and capable.
> 5 minutes of resume discussion
> 45 minutes of coding
As anyone else found that a good resume discussion is often much better than the coding component? I've concluded that implementation difficulties, decisions made (tradeoffs, technologies, etc.) and the collaborative environment around projects, are much better signals than the code part of my interviews.
If you've dealt with a broad range of tech and can ask the right questions, it's relatively easy to get a strong signal from a candidate by having a deep discussion on their work on prior projects. Both are needed and very useful.
They include a video of a parking garage being opened after just a few iterations. The code used in commercial applications could often be lower bits given criminal prosecution is a larger deterrent than code security. Although, OP may have set a specific range for that demo.
Looks like a preset list of extensions. I'd assume custom extensions would be very difficult to support in managed postgres.