Looks like a preset list of extensions. I'd assume custom extensions would be very difficult to support in managed postgres.

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.

[1] https://gitlab.com/jeffreyrogers27/AtomicWrite/blob/master/A...

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?

I’ve used it and it works great (much better than glide, gb et al) but I don’t see it in the wild too often.

[1] https://github.com/golang/dep

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.

    _("ls -la") | _(lambda x: x.split()[-1]) | _(lambda x: os.path.splitext(x)[1])

[1] https://gist.github.com/pnegahdar/726cf2c65fc561db7831

[1] https://en.wikipedia.org/wiki/Tysons,_Virginia

> 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.

[1]http://www.vldb.org/pvldb/vol8/p1816-teller.pdf

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".

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.

Congrats to the Go team and their amazing work!

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.

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.

Comments URL: https://news.ycombinator.com/item?id=15116257

Points: 2

# Comments: 0

Means they're the same to them regardless of whether its readable or not (they aren't even opining here).