Promises are not neutral enough

Promises in JavaScript create problems which affect the entire ecosystem. In this blog post I’ll explain some of those problems.

The way this article starts might make you imagine that it was written by someone in a grumpy state of mind who, after several hours swearing at the computer, decided to rant about it on the internet. That’s not at all the case. I was just making my morning coffee in no hurry, when someone asked me on Twitter what is my opinion on Promises. I thought about it while sipping my coffee, then wrote a couple of tweets. Some people thought it would better presented as a blog post, so here we go!

The basic purpose of Promises is to represent a value that will be eventually available. It could become available in the next event loop or in the next minutes. There are many primitives that could accomplish this same purpose, e.g. callbacks, C# Tasks, Scala Futures, RxJS Observable, etc. JavaScript Promises are one type of primitive that solve the problem of programming with eventual values.

Even though they fulfill their purpose, JavaScript Promises are an opinionated primitive that introduce a lot of weirdness. This weirdness ends up spreading to other corners of the JavaScript language and ecosystem. Basically Promises are not neutral enough because they introduce 4 opinions:

  • Eager, not lazy
  • No cancellation
  • Never synchronous
  • then() is a mix of map() and flatMap()

https://staltz.com/promises-are-not-neutral-enough.html

Advertisements

The hidden costs of serverless

This article represents the opinions of Amiram Shachar, CEO of Spotinst.

Serverless architecture is the next step in the evolution of computing power. The reasons for taking the leap are clear:

  • You will save time: No more provisioning, managing, or thinking about how your application will scale up or down. Not only won’t you need to deal with implementation upon deployment, but all the time you spend dealing with the infrastructure afterwards will again be yours to spend on further innovation.
  • You can save money: In a Serverless world where you pay-per-trigger, you don’t need to write on/off scripts, plan reservations, or plan for spikes. You just pay for what you use.
Serverless is the next step in the evolution of computing power

Like the jump from on-premises to the cloud, the move to Serverless is more or less inevitable. Also like the jump from on-premises to the cloud — this move could come with some surprising bills.

https://read.acloud.guru/the-hidden-costs-of-serverless-6ced7844780b

What I learned in 2017 Writing Go

A little over a year ago, I joined Cloud Foundry to work on Loggregator, Cloud Foundry’s application logging component. Its core concern is best-effort log delivery without pushing back on upstream writers. Loggregator is written entirely in Go.

After spending more than a thousand hours working with Go in a non-trivial code base, I still admire the language and enjoy using it. Nonetheless, our team struggled with a number of problems, many of which seem unique to Go. What follows is a list of the most salient problems.

https://www.commandercoriander.net/blog/2017/12/31/writing-go/

I just asked 23,000 developers what they think of JavaScript. Here’s what I learned.

I recently published our results for the 2017 edition of the annual State of JavaScript survey, collected from over 23,000 developers.

The results revealed many things, from popularity trends to salary breakdowns. You’ll want to take a look for yourself if you haven’t done so already. But among all these data, here are the 10 things that stood out most to me.

Even if you’ve already seen the results, you might want to check out the new Features and Opinions sections we’ve just added.

https://medium.freecodecamp.org/i-just-asked-23-000-developers-what-they-think-of-javascript-heres-what-i-learned-9a06b61998fa

How Cargo Cult Bayesians encourage Deep Learning Alchemy

There is a struggle today for the heart and minds of Artificial Intelligence. It’s a complex “Game of Thrones” conflict that involves many houses (or tribes) (see: “The Many Tribes of AI”). The two waring factions I focus on today is on the practice Cargo Cult science in the form of Bayesian statistics and in the practice of alchemy in the form of experimental Deep Learning.

For the uninitiated, let’s talk about what Cargo Cult science means. Cargo Cult science is a phrase coined by Richard Feynman to illustrate a practice in science of not working from fundamentally sound first principles. Here is Richard Feynman’s original essay on “Cargo Cult Science”. If you’ve never read it before, it great and refreshing read. I read this in my youth while studying physics. I am unsure if its required reading for physicists, but a majority of physicists are well aware of this concept.

https://medium.com/intuitionmachine/cargo-cult-statistics-versus-deep-learning-alchemy-8d7700134c8e

The React Story: How Facebook’s Instagram Acquisition Led To The Open Sourcing of React.js

React is now one of the most popular JavaScript UI libraries in the world. It has over 70K stars on GitHub, over 1100 contributors, over 6M downloads this past month alone, and well over 4K company stacks. But when Facebook first introduced React to the world, not too many people cared.

For the latest episode of Stack Stories, we did something a bit different. We decided to focus on the origin story of the one of the most popular technologies in the software development world: React. We sat down with Pete Hunt, one of the original creators of React, now CEO at Smyte, to get the untold, in-depth story of why React was first created, how it gained adoption within Facebook due to the Instagram acquisition, and it’s eventual release to the public.

Listen to the interview in full or check out the transcript below (edited for brevity).

Check out Stack Stories’ sponsor STRV at strv.com/stackshare.

https://stackshare.io/posts/the-react-story

Learning Go by porting a medium-sized web backend from Python

Summary: To learn Go, I ported the backend of a small site I run from Python to Go, and had a fun, pain-free experience doing so.

I’ve been wanting to learn Go for a while now: I like the philosophy of a language that’s small, has a gentle learning curve, and compiles very fast (for a statically-typed language). What pushed me over the line to actually go and do it was seeing more and more fast, robust tools that are written in Go – Docker and ngrok are two I’ve used recently.

The philosophy of Go is not to everyone’s taste (no exceptions, no user-defined generics, etc), but it fit my mental model well. Simple, speedy, does things the obvious way. During the port, I was especially impressed with how robust the standard library and tooling was.

http://benhoyt.com/writings/learning-go/