Ask HN: How to learn to write a compiler and interpreter? - <AUTHOR> Greetings,
I am in my late 30s without a formal CS education. I write software for a living and have this itch to learn to write a compiler / interpreter.
DO I have to take any courses (e.g. Discrete Maths, Automata Theory) in order to do it?
Do I have to take any courses? If so, do you have recommendations for those as online courses?
I really want to do this in 2019 but the thought that I have to study Maths, then Automata, maybe OS, then Compilers sounds like a long path.
Is there who has learned to write compiler / interpreter without CS background? How did you do it? <comment><USER2> I would highly recommend you start with this book first [https://interpreterbook.com](https://interpreterbook.com) and then feel free to read Nystrom's online book as ablerman suggested.

The you can read more formal CS book for the sake of covering the necessary theory.

Another suggestion would be to check the source code of various SQL databases, such as SQLite3 and PostgreSQL.

Also, I would suggest to read lots of lots of source code from github.

Here is a short list of suggestions:

      * https://github.com/lemon-lang/lemon
      * https://github.com/d5/tengo
      * https://github.com/wren-lang/wren (by Robert Nystrom)
      * https://github.com/tj/luna (by TJ Holowaychuk, creator of Express.js)

</comment><comment><USER3> I cannot recommend Thorsten Ball's books highly enough. They're really fantastic, step-by-step tutorials, and you certainly don't need a CS degree to understand what he's doing.

 __Writing An Interpreter In Go __[https://amzn.to/2FYwwiQ](https://amzn.to/2FYwwiQ)

 __Writing A Compiler In Go __[https://amzn.to/2sLilph](https://amzn.to/2sLilph)

</comment><comment><USER4> Robert Nystrom has been putting an online book together. I've found it really clear so far.

[http://craftinginterpreters.com/](http://craftinginterpreters.com/)

<comment><AUTHOR> Does it require any background in CS?

<comment><USER5> You can probably pick the CS and math up as you go. I haven't gone through that resource but it looks interesting and useful.

</comment></comment></comment><comment><USER6> Graydon Hoare's "One-Day Compilers" presentation: [http://www.venge.net/graydon/talks/mkc/html/mgp00001.html](http://www.venge.net/graydon/talks/mkc/html/mgp00001.html)

      > goal: translate subset of makefile syntax into native executables

      result: pipeline to compile subset of makefile syntax into native executables, in less than 400 lines of code

      > including
      > * lexing and parsing
      > * variable binding
      > * type checking
      > * error reporting
      > * native code generation

      - use custom camlp4 pre processor
      - define Ocaml types and functions to model things found in input makefile (variable, rules, dependencies). leverage Ocaml semantics
      - parse input simple makefile language
      - map parsed input into AST for Ocaml functions defined earlier
      - use ocaml's quotation machinery to define ocaml AST values from standard ocaml syntax, without building AST values by hand
      - bundle everything into an ocaml program
      - ocaml program produces single ocaml value that models the input program described by makefile

      - translate ocaml value into C code:
      - generate C code from templated quotations, again using ocaml quotation support, but for C language, not ocaml
      - compile generated C code with gcc

      - glue everything together into one pipeline

</comment><comment><USER7> If you're familiar with recursion and basic data structures, that's probably a sufficient background. Toy compilers aren't that difficult when you break them down into parts. (Real world languages end up with warts and special cases).

You have a text file. You break it up into tokens (numbers, strings, keywords, operators, etc) . You assemble the tokens into a structured tree (statements, expressions, etc). Then you walk the tree and generate code (for a compiler) or execute it (for an interpreter). That's it. Really.

Every other week, somebody posts a tutorial to HN about writing a lisp interpreter in javascript. or go. or python. or rust. or lisp. If you can't wait, Let's Build a Compiler by Jack Crenshaw is an oldie but a goodie.

[https://compilers.iecc.com/crenshaw/](https://compilers.iecc.com/crenshaw/)

<comment><USER6> i also heartily recommend Crenshaw's "let's build a compiler" if you want some guidance and motivation to help you just roll up your sleeves and start building a bare-bones but functional compiler.

> Maths, then Automata, maybe OS,

i don't think any of these are a requirement for building a simple compiler.

after reading Crenshaw some years ago, i was motivated to just knuckle down and start building a compiler for brainfuck (yes, a toy compiler, entirely pointless). this was probably one of the most enjoyable periods of programming i can remember.

i think my descent into fun with compilers went something like:

* "let's implement a compiler for a simple language (brainfuck) to something low level (assembler) in a high-level language i am familiar with (python)"

* ok, that was easy, now what?

* "self-hosting compilers are cool. can i write a brainfuck compiler in brainfuck?"

* "this is horrifying"

* "OK, what if i defined a simple language that is much easier to do useful work, but could be readily compiled to brainfuck? i could build a compiler from that new language to brainfuck"

If you have a bit of spare time i heartily recommend (i) learning to implement a basic compiler, and (ii) building the compiler in or for a language that has a radically different concept to languages you are more familiar with.

[https://github.com/fcostin/abfc](https://github.com/fcostin/abfc)

</comment></comment><comment><USER8> I designed a programming language and wrote an interpreter for it [1] for fun without a formal CS education. I started a series of articles [2] to teach people everything they need to do the same. Give it a try :).

[1] [https://github.com/ftchirou/blink](https://github.com/ftchirou/blink)

[2] [https://hackernoon.com/lets-build-a-programming- language-261...](https://hackernoon.com/lets-build-a-programming- language-2612349105c6)

(P.S. Feel free to reach out to me [github_username] at gmail.com)

</comment><comment><USER9> You may be interested in this [https://beautifulracket.com/stacker/intro.html](https://beautifulracket.com/stacker/intro.html). At the end you have a small interpreter that can handle math. There are further tutorials on [https://beautifulracket.com](https://beautifulracket.com) to expand it. This is probably the most approachable option.

</comment><comment><USER10> You can get started on the compiler/interpreter specific learning as long as you already know a programming language and basic data structures. You do not need any math skills.

1) Lexical Analysis (Tokeniser)

The first step of your compiler takes in free form text and turns it into a set of tokens that make the rest of the process much easier. To understand this you should learn about Regular Expressions and Finite State Machines.

2) Syntax Analysis (Parsing)

Processing the above tokens and ensuring the input has the valid syntax of a program is your next step. You need to learn about Context Free Grammers, Backus Naur Form and Abstract Syntax Trees.

3) Semantic Analysis

Just because the input has valid syntax does not mean it makes actual sense. Here you need to learn about Symbol Tables and Type Checking. The specifics are very dependant on the actual language you are dealing with.

4) Code Generation

A compiler will be generating code but an interpreter will perform actual execution of the Abstract Syntax Tree operations. Again, the specifics are very dependant on the actual language you are dealing with and the target. Start by looking into Code Generation, Code Optimizations and Assembly Code.

I recommend an online, free course, like the following from Stanford that is self-paced and results in a compiler that generates assembly level instructions for test running in an emulator.

[https://lagunita.stanford.edu/courses/Engineering/Compilers/...](https://lagunita.stanford.edu/courses/Engineering/Compilers/Fall2014/about)

</comment><comment><USER11> @stephen82 has great references. In particular wren, and luna are references I used when I created my language como-lang-ng: [https://github.com/rmccullagh/como-lang- ng](https://github.com/rmccullagh/como-lang-ng) You do not need Dicrete Math, or Automata Theory to learn how to write a compiler and interpreter.

I would recommened first, figuring out what you want your language to look like (the syntax). Then, you can define a grammar for your language, and research parsers. From parsing, you will be leade to Abstract Syntax Trees (the most modern way to get from text file to bytecode). After that you'll need to compile the abstract syntax tree (which you would have built from the parser). Compiling the AST is typically done targetting your own simplified instruction set.

For an example instruction set, check out Python's header file at [https://github.com/python/cpython/blob/master/Include/opcode...](https://github.com/python/cpython/blob/master/Include/opcode.h)

</comment><comment><USER12> Some books on compilers go into the automata theory for the following reason: they teach about the workings of _tools that generate_ lexical analyzers and parsers. A compiler writer is usually just a consumer of those tools. The skills that come into play is being good in program design: structuring code and data.

How much CS comes into play depends on how advanced you make the compiler and what design choices you make. E.g. if you make a stack-based VM, or one with unlimited registers, instead of targeting a real machine with a fixed number of registers, you don't have to study the algorithms for register allocation.

Some languages avoid the complexities of parsing, such as those in the Forth family, and to a large extent Lisp family. To make a language, you don't even need to be a consumer of scanner and parser generating tools, let alone understand how they work.

</comment><comment><USER13> I think this book suits your situation and I've been into that!

Compiler Construction Using Java, JavaCC, and Yacc, IEEE/Wiley, 2012

Get this book. Please. __ _I promise_ __. You'll be able to grok compilers after reading and answering the exercises from this book.

We can talk further by sending me an email (see my profile).

Here's my previous comment somewhere in HN:

I bet this is what you are looking for: [https://www.amazon.com/Compiler- Construction-Using-Java-Java...](https://www.amazon.com/Compiler-Construction- Using-Java-Java..).

This book taught me how to write a compiler and build a programming language of my own.

To answer you question "where and how did you start?": This is where I started learning about compilers and programming language implementation.

Here is its description from its website:

* Comprehensive treatment of compiler construction.

* JavaCC and Yacc coverage optional.

* Entire book is Java oriented.

* Powerful software package available to students that tests and evaluates their compilers.

* Fully defines many projects so students can learn how to put the theory into practice.

* Includes supplements on theory so that the book can be used in a course that combines compiler construction with formal languages, automata theory, and computability theory.

What I promise you with this book: You'll learn how to write your own programing language. Not only how compilers and about the language but also about computer architecture. This book is very easy to read and understand. It starts with very basic topics then slowly building from it until you'll grok implementing the language given the specification. You'll have the chance to build a compiler from scratch or by using JavaCC and Yacc.

</comment><comment><USER14> If you don't want to read up front, don't; start with a calculator. If you know regular expressions (and even if you don't), getting something that handles

       a=3
       b=4
       a=a+b
       print a

shouldn't be too hard. In iteration 1, forget about expressions with more than one operator such as

       a=3*b+c

If you think it's easier, also forget about multi-character identifiers (a…z should be enough for everybody) types (all variables can be int or, if desired, float)

Also, initially forget about making a product that doesn't crash on invalid input. If a…z is enough for everybody, your toy language may crash on

      A=3

or

      aa=0

Then, add features as you see fit. You will run into problems, such as questioning whether

      print=3
      print print

should be a valid program, or whether it's a good idea if

      a=2+3*4
      print a

prints '20', but that's part of the fun (if you have a puzzling mind, figuring out how to do that 'properly' without reading about it isn't out of reach). And those features you add shouldn't be large. For example, looping:

      a=1
      @again
      print a
      a=a+1
      >again

add simple if statements:

      a=1
      @again
      print a
      a=a+1
      if a<20 >again

The end result will likely be buggy in places. For example, if you decide to support

       a=3;b=4

and parse by splitting each line on semicolons, adding strings

       a="strings may have semicolons, too;"

may result in an interpreter/compiler that is broken for a while. Who cares? You aren't building a compiler or interpreter, you're learning.

Also: start with an interpreter. A compiler isn't that much harder, but requires you to know about your system's assembly, object code format, etc.

</comment><comment><USER15> I found tutorials like this [0] one to be pretty useful, since they show how to actually use frameworks like LLVM, and lex/yacc/etc. practically. Note that this one is from 2009, and uses an outdated version of LLVM. Actually following along requires some debugging and digging through documentation, which is also helpful in its own way.

[0] [https://gnuu.org/2009/09/18/writing-your-own-toy- compiler/](https://gnuu.org/2009/09/18/writing-your-own-toy-compiler/)

</comment><comment><USER16> Practical steps:

1\. Create a grammar for your language. Start with Lex/Yacc and model your grammar with Lex/Yacc. Use them to generate lexer/parser.

2\. Create sample code in your new language. Parse the generated parser on said language file into a list of Syntax trees.

3\. With said Syntax trees, generate target code - Compiler (or) evaluate the tree and print results - Interpreter.

Iterate and repeat steps until your language is complete.

</comment><comment><USER17> Well, the way you ask your question in abstract sort of biases it towards a CS-heavy approach, doesn't it?

What's your goal?

I've written non-trivial macros that could be understood to be a tiny compiler, but wasn't ever interested in compiler design and I can't claim to know much about it.

<comment><AUTHOR> It is just that I have a job and a family to support. So I want to create something in whatever time I have. The prospect of engaging myself in myriad of courses sounds dull.

Maybe it's a folly but I am just intrigued by how they work and want to be able to develop them without committing to taking lot of courses.

<comment><USER18> maybe you could look into LLVM's Kaleidoscope tutorial..

</comment></comment></comment><comment><USER19> Read the Dragon Book[0]

[0] [https://en.wikipedia.org/wiki/Compilers:_Principles,_Techniq...](https://en.wikipedia.org/wiki/Compilers:_Principles,_Techniques,_and_Tools)</comment>


How I killed Pluto and why it had it coming - <AUTHOR> http://www.theatlantic.com/technology/archive/2010/12/how-i-killed-pluto-and-why-it-had-it-coming/67242/

<comment><USER2> I grew up knowing that Pluto didn't "fit" the pattern, thanks to my youthful obsession with outer space. I think the trouble arises when the only thing children really remember about planets is "My Very Eager Mother …" or whatever mnemonic regular kids use to learn the order. If you actually _knew_ anything about Pluto, you'd know about its irregular, overly elliptical off-plane orbit; its large moon, almost a binary planet; its pathetic size; its pattern- breaking proximity to the sun; and the fact it was an outer planet that wasn't a gas giant.

So scientists breaking your mnemonic are stealing the only thing you ever _knew_ about the planets.

<comment><USER3> In German the mnemonic was nicely self-referencing: Mein Vater erklärt mir jeden Sonntag unsere neun Planeten. (Translated: Every Sunday my father tells me of the nine planets.)

</comment></comment><comment><USER4> A friend of mine who's a planetologist points out that the IAU's definition is really not a good one from a planetologist's point of view. It's centered around how the planet moves (which is what an astronomer can see) instead of around how it's composed (for which we need to send a probe).

It's not even that good from the astronomy point of view. A planet has to have cleared its orbit of other bodies—so what about Jupiter's Trojan asteroids? Are they just handwaved out of the way, or is Jupiter no longer a planet?

<comment><AUTHOR> _It's centered around how the planet moves (which is what an astronomer can see) instead of around how it's composed (for which we need to send a probe)._

What does its composition matter? That won't help you distinguish anything. Indeed, to first approximation there are only three types of stuff in the solar system: "gas" (meaning hydrogen+helium), "ice" (meaning water, methane and ammonia) and "rock" (meaning... well, rock and metals). And there's planets made out of each; Jupiter and Saturn are gas, Neptune and Uranus are ice, and the inner planets are rock.

As for the "cleared the orbit" bit, check out wikipedia's article on "Dwarf planet"; talk of clearing the orbit is just shorthand for a genuine mathematically-defined criterion which Jupiter fits and Pluto doesn't.

<comment><USER4> > _What does its composition matter?_

I said she was a planetologist. To planetologists, composition is everything. Composition is what the planet is, not where it is.

> _Indeed, to first approximation there are only three types of stuff in the > solar system:_

Yeah, but planetologists don't stop at the first approximation.

> _As for the "cleared the orbit" bit, check out wikipedia's article on "Dwarf > planet";_

Let's see...ah. OK, here's the clause that I didn't know about: "and there are no other bodies of comparable size other than its own satellites _or those otherwise under its gravitational influence_ " (emphasis added). The Trojans are clearly under the gravitational influence of Jupiter.

Thanks.

</comment></comment></comment><comment><USER5> While being the guy who discovered Xena would certainly be worth some notoriety, isn't being the guy who killed Pluto also notable?

<comment><USER6> It is, but thanks to his portrayal in certain sci-fi shows I generally associate Neil deGrasse Tyson with the death of Pluto. I wasn't aware Mike Brown even existed until I read this article.

</comment></comment><comment><USER7> Sounds like bike-shedding to me.

<comment><USER8> The argument is very much inflicted with the bike-shed disease, largely because memorizing the planets is a common school activity so everyone feels they have a stake regardless of their scientific understanding of the subject.

The basic problem is that the definition of a planet has transitioned over time, a lot of time, from a colloquial definition to a scientific one. For the longest time "planet" was just a name for any large, permanent part of the solar system that was worth memorizing. Initially even the Sun and Earth's moon were planets, but the heliocentric revolution placed the Sun in a different category and inadvertently relegated the moon to a minor body along with all the other moons (notable only due to its proximity to human civilization). For a few decades the first 4 discivered asteroids were planets, but the discovery of hundreds and then thousands of similar asteroids brought the realization that these 4 bodies were not quite as notable as once thought. Pluto lasted much longer as the only known KBO for the better part of a century and thus snuck into planet hood.

When Pluto was alone it was much easier to ignore its differences and just chalk it up as the quirkiest member of the planets despite its tiny size, eccentric orbit tilted to the ecliptic, etc.

As we've discovered more planets in other systems and as we've discovered more objects in our outer solar sytem a firmer definition of planet has become more necessary. The new criteria for planet hood are straightforward and useful in understanding the nature and evolution of planetary systems. However, Pluto doesn't satisfy them. In scientific terms this isn't a big deal, but for the public and for the colloquial definition of planet there is still a lot of resistance to change.

<comment><USER9> OT but can anyone explain to me why the planets all have the same orbit plane? I've never read a succesful explanation.

<comment><USER8> Take a proto-stellar nebula, it's a big mass of gas and dust thousands of AU in diameter. Each particular bit will generally be moving very slowly in a random direction relative to the whole but the whole thing has some particular _net_ angular momentum. As the nebula collapses to form a star this angular momentum gets concentrated (insert standard ice-skater pulling in their arms description here), which is why stars tend to have some particular spin. The same mechanism of concentration works to help form a protoplanetary disc. Objects in eccentric orbits or orbits tilted to the average plane of the forming disc will be more prone to collisions, causing them to be absorbed or captured by larger bodies or to form a debris cloud of generally lower eccentricity and lower inclination.

Over time these effects add up to cause most of the mass in the inner Solar System to be concentrated in a small number of planets in circular orbits within a narrow range of inclinations.

Note that in the far outer Solar System of the kuiper belt and oort cloud these effects are much diminished (orbital periods are much longer, distances are much larger, overall volumetric mass densities are lower, etc.) so objects are more likely to have eccentric and inclined orbits relative to the inner solar system consensus.

<comment><USER9> I get most of that, just not how it ends up in a flat disc. as opposed to an array of discs or something similar.

Is the idea that if you took the nebula, and measured across in 1 deg increments, the plane that had the largest percentage of largest objects is the highest probability of becoming the eventual plane?

This seems like the sort of concept that could do with a nicely done animation to explain.

</comment></comment></comment></comment></comment><comment><USER10> We, the pluto activist, do not take kindly on actions like this. We demand that pluto regains planetary status if your demands don't get met we will take agressiv action. :)

</comment><comment><USER11> The "Save Pluto" crowd do a disservice to science in general, instead of using this as a way to highlight the scientific method and the importance of always reassessing ideas based on new data. I applaud Pluto's death as a contrast to inflexible memorization of facts and demonstrating that facts are only valid as far as they are backed by observation and nothing is sacrosanct. While it may be difficult for some, I can't think of a better example of the impartiality of science - Technology may someday remove a planet, but for now it's only science.

<comment><AUTHOR> Yes and no. The classification of Pluto really isn't a matter of science, it's just a matter of words. We _could_ , if we felt like it, declare that Pluto is a planet. We could arbitrarily decide that anything more than 100km in radius is a planet. Or we could declare that nothing smaller than Uranus is a planet (goodbye, planet Earth!)

While the discovery of a bunch of dwarf planets filling in the size gap between Pluto and the smallest asteroids is certainly suggestive that the definition of "planet" needs to be revised, we could quite easily have gone with another definition. From a scientist's point of view I don't care much one way or another, but from a layman's point of view I can see how it'd be nicer to live in a richer solar system with twelve official "planets" rather than our new impoverished solar system with just eight.

<comment><USER11> Except that it would end up as 40+ planets, most of which are clearly asteroids, in order to pretend that science is constant.

<comment><USER12> The labels for things have nothing to do with the state of nature, but rather with the way people work. The fact that we call Earth and Jupiter the same thing but consider the sun and Pluto to be different kinds of things is simply a choice that is meant to aid human understanding, not a statement about nature. There is no such thing as "chair" or "star" or "supermarket" in the laws of physics, those are just words we use to make sense of the world. We could say that the solar systems are made up of "gassies", and "rockies", and "icies", and "firies", and "clumpies" if we wanted instead of Gas Giants, Rocky Planets, Comets, Stars, and Asteroids, and it wouldn't make a damned bit of difference to the way nature actually works (if you get your descriptions of those kinds of things accurate enough, then you could still model the behavior of the solar system just as well as if you were using "planet" in your descriptions instead!), but, of course, it makes a difference to how people think about these things, which might help or hinder our analysis of them. (Note: as an example, if we were using "clumpies" for asteroids, then we might be arguing about whether Ceres is a "clumpy" or a "rocky", since it's much more regularly shaped than things like 216 Kleopatra... And speaking of classifying things, are dinosaurs lizards or birds? :p)

<comment><USER13> Of course, those labels aren't purely artificial. Once you define some measurement of similarity, you can identify clusters in a data set, if there are clusters to be found. Those clusters are reasonable things to lump together with labels.</comment></comment></comment></comment></comment>


Show HN: "AMD processors sold per year -intel" = snack food - <AUTHOR> https://www.google.com/search?hl=en&ei=uBjbXK7rJ-2Igge2_rDQDA&q=amd+processors+sold+per+year+-intel <comment><AUTHOR> Take a look at the 2nd result and all below.

Try removing any of the words in the search query and it performs as you would expect.

</comment><comment><USER2> Google seems to assume that AMD means "and." If you put AMD in quotes, the results relate to AMD, at least for me.</comment>


Serverless security implications from infra to OWASP - <AUTHOR> https://snyk.io/blog/serverless-security-implications-from-infra-to-owasp/ <comment><USER2> I'm not sure, in practice, how much of a win for serverless reduced patching is, compared to say a containerized environment.

You're still likely to be deploying all the exposed components yourself (i.e. the web application and it's attendant libraries), so the attack surface and possiblity for exploitable vulnerabilities is similar.

There's a win if you're comparing to a setup where you have a load of exposed services that aren't directly related to the application (so management services like SSH) but these days I see a lot fewer of those exposed directly to the Internet from the web server hosts.

What is likely a win is lack of persistence. Attackers need to pull off attacks with limited opportunity for storing something on disk and calling it after the initial compromise, when compared to longer running services.

The thing that becomes totally critical in a serverless architecture is access control and credential management for the underlying cloud platform. Where a load of, for example AWS services are used an attacker who can get access to the console via stolen credentials can do a lot of damage, if IAM profiles haven't been managed properly.

<comment><USER3> Right. You have to authorize to some sort of management layer _somewhere_. In this case at the cloud API level. It's nice that it's not directly "in band" with the rest of your application code in the same physical address space, like say SSH, but you have no idea of the actual hardware isolation involved, unless you were an engineer building said cloud.

I guess what I'm trying to say is serverless just seems like a way of shifting management layers around, giving the appearance or feeling of less management. I'm not saying thats not valuable - I haven't tried it. This is just my view from the outside.

</comment></comment><comment><USER4> I gave a talk about this at CCC this year!

[https://media.ccc.de/v/33c3-7865-gone_in_60_milliseconds](https://media.ccc.de/v/33c3-7865-gone_in_60_milliseconds)

I'm sitting on a toolkit for this, just need to spend a Sunday polishing it to release quality:

[https://github.com/Miserlou/Mackenzie](https://github.com/Miserlou/Mackenzie)

<comment><USER5> Great talk mate. Very interesting :)

</comment></comment><comment><USER6> Also a big one that the author forgot to mention; because server-less back- ends are shared by many companies, there is a stronger incentive for hackers to try to hack the provider.

<comment><USER7> I'm really quite astounded that there haven't been more huge cloud hacks. I guess hypervisor authors and cloud providers have taken security seriously enough.

<comment><USER8> The existence of hypervisor rootkits and the vast scale of cloud provider operations argue for caution.

For example, a state-level actor can afford to train and place operatives into an AWS-scale organization with enough access to infiltrate and undermine the system.

<comment><USER7> We use bare metal hosts for the ZeroTier CAs. This is one reason, though cost/CPU is another. These machines are CPU-bound, spending most of their time signing network configs. CPU is way cheaper at OVH (bare metal) than anywhere else.

</comment></comment></comment></comment><comment><USER9> Another key aspect is new security approaches to consider during development and integration. Currently an API can be secured as desired, and everything else can be hidden behind the firewall. With the serverless approach more thought has to be given to ensure there isn't "round-a-bout" ways to bypass application security and data validation.

Edit: I don't mean to sound negative, I think serverless structure is finally the realization of what "cloud" has promised and not quite delivered for so many years.

<comment><USER10> I don't know what you are trying to say. Any complex API will have to have some custom validation code.

What we have been doing is using typescript interfaces[1] to validate our API input data. This really makes the data validation painless for us.

 _EDIT_ : Thinking about this a little more, this really only ensures that the provided data is the right "shape", there may still need to me more validation performed.

[1] [https://github.com/ysangkok/typescript-interface-to- jsonsche...](https://github.com/ysangkok/typescript-interface-to-jsonschema)

</comment></comment><comment><USER11> > 8\. Greater flexibility leads to greater attack surface

I think this is critical. The fact that there aren't many battle-tested frameworks out there writing your own functions can introduce security bugs. But from my experience, most of the use of Serverless code are very backend, cronjob type of code, and aren't necessarily tied to any real applications. Remote execution is still possible though. I am not sure how many people out there run their website in API Gateway. I've read about one or two stories, but that's it.

Another thing is not security-related, but more with reliability. Serverless development poses challenge for performance monitoring.

</comment><comment><USER12> Also, for penetration testers it's usually not legal or in breach of contract to try to compromise services running on cloud/serverless infrastructure because they would impact 3rd parties, starting from the cloud provider itself.</comment>


Ask HN: Math behind Algorithms - <AUTHOR>

I'm planning to spend the next few weeks beefing up on algorithms - starting with Algorithms in a Nutshell, followed by Algorithm Design Manual and Algorithms by Dasgupta.<p>Before I start these books, I wanted a primer on the math behind algorithms. A friend suggested I look at Velleman's "How to Prove It". Anyone have any other recommendations? <comment><USER2> The math section of Cormen, Leiserson, Rivest "An Introduction to Algorithms" is a good introductory math text for CS people (the remainder of the book is also excellent).

<comment><AUTHOR> The appendices at the end? Added it to my list. Thanks!

<comment><USER2> I was thinking of the first few chapters (Part I of the book). But your question was rather generic, actually there are mathematical techniques sprinkled through the whole book.

</comment></comment></comment><comment><USER3> [http://www.catonmat.net/blog/mit-introduction-to- algorithms-...](http://www.catonmat.net/blog/mit-introduction-to-algorithms- part-one/) is a very good site, with videos of MIT lectures.

<http://www.cs.sunysb.edu/~algorith/video-lectures/> is another great source for video lectures.

<http://en.wikipedia.org/wiki/List_of_algorithms> has a veritable zoo of algorithms. Best part: contribute to the pages and you'll learn it better than just reading. For a true zoo of algorithms to start off a search, <http://www.itl.nist.gov/div897/sqg/dads/> is perhaps the best.

Stack Overflow's got many good threads on Big O and comparative complexities, for instance [http://stackoverflow.com/questions/133008/what-is-big-o- nota...](http://stackoverflow.com/questions/133008/what-is-big-o-notation-do- you-use-it)

</comment><comment><USER4> You should probably add Knuth's Volume 1 ( Fundamental Algorithms) to your list: [http://www.amazon.com/Art-Computer-Programming- Fundamental-A...](http://www.amazon.com/Art-Computer-Programming-Fundamental- Algorithms/dp/0201896834/ref=sr_1_3?ie=UTF8&s=books&qid=1242733059&sr=1-3)

The first few sections cover some mathematical background.

</comment><comment><USER5> "Concrete Math" by Graham, Knuth, and Patashnik.

<comment><USER6> Beware, Concrete Math, from what I've heard, is great but _very_ hardcore (but in a subtle, sneaky way). The reader is expected to have a very solid grasp of many areas of math before reading it, such as being an upper level math undergrad student. If this doesn't describe you, I'd also suggest starting with CLRS first.

<comment><USER7> But it's written so well that it's a pleasure to repeatedly bang ones head against :) So go for it but expect to have to take it slowly... oh, and do the exercises otherwise it won't make sense.

</comment></comment></comment><comment><USER8> Intro to Algorithms by CLR is the best first book on the subject I know of. MIT has a complete set of lecture videos:

[http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and- Compute...](http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer- Science/6-046JFall-2005/CourseHome/)

But based on my own (admittedly weird) experience, Algorithms _per se_ might not be the best place to start. You might do better starting off with graph theory instead because:

1\. It's an equally fundamental entree to the same theoretical CS material. Graphs abstract data structures like algorithms abstract programs.

1a. You wind up learning a lot of the same material.

2\. The "core" of Algorithmic analysis is solving counting problems with recurrence relations, sort of like the way "canceling terms" is the core of high school algebra. It's easy to explain the concept in a few words, so it's easy to think you understand it, but you have to practice it in a lot of different contexts to really master the skill. There's also a lot of deep theory hiding below the surface. Graph theory, on the other hand, starts out with definitions that you can blow through in a day, and then builds progressively more complicated structures for you to analyze.

3\. Most of the proofs in graph theory actually involve writing programs to construct an existence proof or verify a property. Obviously this is also true of algorithms, but the correspondence between proofs and programs is harder to see there.

4\. Graph theory touches higher math in more accessible places than algorithmic analysis. You can analyze graphs with matrices, mess around with their eigenvalues (although I think the preferred term is "spectrum"), do some group theory -- "advanced undergraduate" stuff. The only place in higher math where algorithms really come into play is number theory, which requires a lot of theoretical machinery to make its sausages.

</comment><comment><USER9> I recommend Skiena's "The Algorithm Design Manual (2nd ed)": [http://www.amazon.com/Algorithm-Design-Manual-Steven- Skiena/...](http://www.amazon.com/Algorithm-Design-Manual-Steven- Skiena/dp/1848000693/freesciencand-20)

</comment><comment><USER10> get yourself a discrete math textbook (I can't remember what I used). A sprinkling of things that will come up: set theory, probability (Bayesian), Big-O notation and associated meanings, worst/best/avg case analysis, amortized cost, induction, some algebra, ect

if you don't _really_ understand all the math surrounding some fancy algorithm it probably isn't all that important. and everyone's favorite line in a CS proof is of course "without loss of generality".

<comment><USER11> A book i used and liked: Mathematical Thinking, by West and D'Angelo.

It's more than a discrete text (it covers construction of the reals, limits, etc), but it covered a lot.

</comment></comment><comment><USER12> Try Algorithms by Dasgupta, Papadimitriou, and Vazirani. It's quite a short read and you can get it for free here: <http://www.e-booksdirectory.com/details.php?ebook=1050>

</comment><comment><USER13> at this case i prefer you follow a university lessons, may be it'll be better. (I just think so)

</comment><comment><USER14> Look for any book on Finite Mathematics.</comment>


Twitter should Not allow me to follow more than a thousand people - <AUTHOR> https://medium.com/@gmrlbiz/twitter-should-not-allow-me-to-follow-more-than-a-thousand-people-b54d8bee9d4e <comment><USER2> What? No. If you don't want to follow more than 600 people, then ... don't. But your workflow isn't mine and there's no reason that I should be inhibited by your ideas of how Twitter should work.</comment>


Deprecating the RC4 cipher - <AUTHOR> https://blog.mozilla.org/security/2015/09/11/deprecating-the-rc4-cipher/ <comment><USER2> I like what Chrome did with SHA-1, showing the TLS lock with a yellow warning ahead of the breaking change. Is Firefox doing or planning on doing something similar?</comment>


Habits of the World's Smartest People (Infographic) - <AUTHOR> http://www.entrepreneur.com/article/228313

<comment><USER2> This is complete trash -- a mixture of the most deplorable kind of pop psychology, unsupported claims, even misspelled words. It represents pseudoscientific social psychology at its worst.</comment>


Migrating Dropbox from Nginx to Envoy - <AUTHOR> https://dropbox.tech/infrastructure/how-we-migrated-dropbox-from-nginx-to-envoy <comment><USER2> _Also note that we'll cover the open source version of the Nginx, not its commercial version with additional features._

It always kills me when very successful companies don't buy software from other companies.

I remember being at a lunch with a prospective client that really loved our technology. About 1/2 way through, he said he really would love to purchase our software, but the CEO doesn't allow them to use anything but OSS. What they make? Non-OSS software.

Just blows my mind.

<comment><USER3> This also rubbed me the wrong way. As an individual I think that shows selfish and opportunistic behaviour and it raises a red flag about that organisation in my mind.

However, for profit companies are not here to do what's "correct" they're here to make money for its investors. If I had decision making abilities at Nginx I'd be conducting a comprehensive review of the free OSS offering and redacting the features and overall value with extreme prejudice.

Dropbox never paid because it COULD not pay. If you have an enterprise, paid version of your OSS product it has to be impossible for an enterprise to use it for free.

<comment><USER4> > If you have an enterprise, paid version of your OSS product it has to be > impossible for an enterprise to use it for free.

Why? Most enterprises, especially ones that aren't tech firms, are going to shell out for enterprise support even if there are no additional features. Crippling the community version doesn't necessarily help enterprise sales, it can reduce overall mindshare reducing enterprise traction or, worse yet, mean that a third-party downstream edition with richer open-source features becomes dominant and it's creator gets "your" enterprise support contracts.

<comment><USER5> > shell out for enterprise support even if there are no additional features.

i don't feel this to be true.

Also, an enterprise that's large would want some features that are irrelevant to a small shop. For example, single-sign-on integration with various providers.

<comment><USER6> I do though ... Imagine a manager being dependent on a system he ~~bought~~ _installed for free_ , which he didn't buy support for, and is now malfunctioning. It's his fault. And this is what I've seen in practice as well.

Just think about the commercial success of SUSE Linux?

</comment></comment></comment></comment></comment><comment><USER7> I feel so old now. There was a time, when I used to discuss with senior engineers @ Yahoo! to use NginX over Apache. Nginx was the hot thing, popularizing C10k [1]. Now in my current team, I have junior devs in my team pushing for Envoy over HAProxy/Nginx setup.

Is this trend happening primarily because devs are pushing for GRPC over REST? What benefits does Envoy offer over Nginx, if you're still a REST based service. I am not fully convinced of operational overhead that NGINX brings.

[1] [https://en.wikipedia.org/wiki/C10k_problem](https://en.wikipedia.org/wiki/C10k_problem)

<comment><USER8> The sibling comments point towards the difference in configuration if you take the "out of the box" product. But there is also a vast difference in how code is organized, in case you ever have to touch it.

From my point of view Nginx feels "old". It's a C codebase without a great amount of abstractions and interfaces, and instead having a bunch of #ifdefs here and there. Unit-tests and comments are not to be found. Build via autotools.

Envoy looks as modern as it gets for a C++ codebase - apart from maybe the lack of using coroutines which could be interesting for that use-case. It uses C++14, seems to be extremely structured and documented, has unit-tests, uses Bazel for builds, etc.

So I think the experience for anyone being interested in working on the code will be very different, and people that prefer the style of project A will have a very hard time with the style of project B and the other way around.

<comment><USER9> > uses Bazel for builds

Is this unanimously good? I've heard both praise and horror, never used it myself.

<comment><AUTHOR> One of the senior engineers once said to me that "Bazel is like a sewer: you get back what you put in."

Bazel requires __a lot __of upfront effort but the power of (a programmatically accessible /modifiable) dependency graph and a common build/test system across all the languages is very hard to underestimate.

<comment><USER9> > very hard to underestimate

Are you sure?

</comment></comment></comment></comment></comment><comment><USER10> Really great post. I'm glad the post in particular mentioned community, because I think in the end this is the huge advantage Envoy has over NGINX. NGINX, could, in theory, resolve all technical issues raised in the post. But the fundamental tension between the open source and commercial versions cannot be resolved.

(Disclosure: We use Envoy as part of Ambassador, and so of course we're big fans!)

</comment><comment><USER11> I know some people might find it a little controversial, but I'm super excited about our load balancing future and that we probably have the biggest Envoy deployment in the world now. When we moved most of Dropbox traffic to Envoy, we had to seamlessly migrate a system that already handles tens of millions of open connections, millions of requests per second, and terabits of bandwidth. This effectively made us into one of the biggest Envoy users.

<comment><USER12> Well, a single server doesn't really need to do more than 10Gbps or 100k connections. Going above is a "simple" matter of managing horizontal scaling.

What I wonder about is how do you distribute the traffic on the higher level? I imagine there are separate clusters of envoys to serve different configurations/applications/locations? How many datacenters does dropbox have?

I was running a comparable setup in a large company, all based on HAProxy, there was a significant amount of complexity in routing requests to applications that might ultimately be in any of 30 datacenters.

<comment><AUTHOR> We had a large rundown of our Traffic Infrastructure some time ago[1]. TL;DR is:

* First level of loadbalancing is DNS[2]. here we try to map user to a closest PoP based on metrics from our clients.

* User to a PoP path after that mostly depends on our BGP peering with other ISPs (we have an open peering policy[3], please peer with us!)

* Within the PoP we use BGP ECMP and a set of L4 loadbalancers (previously IPVS, now Katran[4]) that encapsulate traffic and DSR it to L7 balancers (previously nginx, now mostly Envoy.)

Overall, we have ~25 PoPs and 4 datacenters.

[1] [https://dropbox.tech/infrastructure/dropbox-traffic- infrastr...](https://dropbox.tech/infrastructure/dropbox-traffic- infrastructure-edge-network) [2] [https://dropbox.tech/infrastructure/intelligent-dns-based- lo...](https://dropbox.tech/infrastructure/intelligent-dns-based-load- balancing-at-dropbox)

[3] [https://www.dropbox.com/peering](https://www.dropbox.com/peering) [4] [https://github.com/facebookincubator/katran](https://github.com/facebookincubator/katran)

<comment><USER13> Katran - nice! Any issues with it at all? Do you use it with xdp capable hardware or just normal driver offload?

<comment><AUTHOR> It works beautifully. We use driver offload (i40e on the Edge.)

</comment></comment></comment></comment></comment><comment><USER14> It's interesting almost no web server provides an easy way to deal with multi- tenant multi-domain architectures in a good way that includes automatic SSL.

Caddy is the closest, but still not near enough.

There is this small segment of the market that we operate in that requires thousands of TLS connected domains to be hosted behind a dynamic backend. It's services like Tumblr, Wordpress.com, or any other hosting service where you can get a "custom domain" to point to your own blog or site.

NGINX - No.

Apache - Nope.

Caddy - Can do (but need lots of workarounds)

Envoy - Nope.

Everyone focuses on a few hand-coded domains and no automatic TLS. Maybe this part of the market is too small anyway. Sigh.

<comment><USER15> Several companies use Caddy for exactly this purpose. Fathom Analytics for example uses it for their custom domains feature. Caddy can even reactively provision certs during TLS handshakes. It's a native feature. Why does it require lots of workarounds?

<comment><USER16> Is there any mature integration to achieve this with Kubernetes?

<comment><USER15> WIP: [https://github.com/caddyserver/ingress/](https://github.com/caddyserver/ingress/)

</comment></comment></comment></comment><comment><USER17> One of my friends brought me up this post in the morning. The post is awesome and inspirational (caused a discussion in our chant group), though I can't agree with some trivial points.

> Nginx performance without stats collections is on part with Envoy, but our > Lua stats collection slowed Nginx on the high-RPS test by a factor of 3. > This was expected given our reliance on lua_shared_dict, which is > synchronized across workers with a mutex.

The `a factor of 3` is quite large to me. Maybe you put all your stats in lua_shared_dict? You don't need to synchronize the stats every time. Since the collection regularly happens in per-minute frequency, you can put the stats as Lua table, and synchronize them once per 5/10 seconds.

It look like that the compared Nginx is configured with a system which has been survived for years and not up-to-date. The company I worked with used a single virtual server to hold all traffic and routed them with Lua code dynamically. And the upstream is chosen by Lua code too. There is no need to reload Nginx when a new route/upstream is added. We even implemented 'Access Log Service' like feature so that each user can have her favorite access log (by modifying the Nginx core, of course).

However, I don't think this post is incorrect. What Envoy surpasses Nginx is that it has a more thriving developer community. There are more features added into Envoy than Nginx in the recent years. Not only that, opening discussion of Nginx development is rare.

Nginx is an old, slow giant.

<comment> rolls-reus > The `a factor of 3` is quite large to me. Maybe you put all your stats in > lua_shared_dict? You don't need to synchronize the stats every time. Since > the collection regularly happens in per-minute frequency, you can put the > stats as Lua table, and synchronize them once per 5/10 seconds.

Any pointers on how to achieve this for someone just starting out with lua and openresty? I have the exact same thing (lua_shared_dict) for stats collection, would love to learn a better way.

<comment><USER17> You can look at [https://github.com/knyar/nginx-lua- prometheus/pull/75](https://github.com/knyar/nginx-lua-prometheus/pull/75) for inspiration.

</comment></comment></comment><comment><USER18> > C++14 is not much different from using Golang or, with a stretch, one may > even say Python.

That's... definitely a stretch.

</comment><comment><USER19> If anyone was wondering, this is solely for proxying, not for oldschool web server functionalities, eg. static file serving.

<comment><AUTHOR> We've actually started experimenting with converting our static file serving to "proxying to S3 + caching." This is simpler from deployment and development perspectives (for companies that do not have a distributed filesystem, like Google with its GFS):

* for deployment we do not need to maintain a pool of stateful boxes with files on them and keep these files in sync.

* for development, engineers now have a programatic interface for managing your static assets.

</comment></comment><comment><USER20> I'm positively surprised that Dropbox (at least from what I understood from the post) didn't require lots of changes or patches on top of the upstream codebase of Envoy to migrate their traffic!

<comment><AUTHOR> We did require some of them[1]. Esp. painful were Transfer-Encoding quirks, and some dances around old HTTP/1.0 backends and request buffering.

Compared to NGINX though, it was relatively easy to push these fixes upstream. Community is very welcoming to outside contributions.

[1] [https://dropbox.tech/infrastructure/how-we-migrated- dropbox-...](https://dropbox.tech/infrastructure/how-we-migrated-dropbox-from- nginx-to-envoy#-issues-we-encountered-)

<comment><USER21> We do have some local patches as well (mostly for integration with out own infrastructure - stats collection, some RPC specific stuff). As SaveTheRbtz mentioned we encountered some issues with non-RFC clients, corner cases which were not exposed when envoy is used in "trusted" environment, etc., but all our fixes are now in upstream, so next migrations will be way easier both for us and for other envoy users.

</comment></comment></comment><comment><USER22> I did not quite get how they configure envoy? Did they write their own control plane? Use ambassador/Istio/Gloo?

<comment><USER21> We have a mix of static and dynamic configuration. We started with almost everything defined in the configuration and implemented our control plane only for endpoint discovery service. Over the time we implemented more and more features there (certificates, tls tickets, route and vhost configuration, etc). We decided to write own implementation on control plane - actually the core part is pretty simple and easily expandable.

</comment></comment><comment><USER23> Did you consider using commercial nginx? If so, what made you decide against it?

<comment><USER24> The price is really insane for Nginx commercial.

<comment><USER23> As an Enterprise software vendor myself, I can assure you: everything is negotiable at Dropbox's scale including very deep discounts.

</comment></comment></comment><comment><USER25> How does Envoy compare to Caddy 2 ? [https://caddyserver.com](https://caddyserver.com)

<comment><AUTHOR> To tell you the truth, we didn't consider it. From what I can get from the architecture docs[1], it can be a decent platform for apps, but might not be the best choice for a general purpose ingress/egress proxy (at least for now.)

[1] [https://caddyserver.com/docs/architecture](https://caddyserver.com/docs/architecture)

<comment><USER15> It is a great choice for a general purpose proxy. (That's kind of the point.)

<comment><USER26> But they mentioned that they wanted to use C++ instead of go to get even that extra performance out.

I use Caddy a lot and it's perfectly fine for my scale, but at dropbox's scale, maybe go wouldn't be enough for the ingress part?

<comment><USER15> I just lament the increasing deployments of programs written in memory-unsafe languages to the edge, in general.

I am more curious what makes the author think Caddy "might not be the best choice for a general purpose ingress/egress proxy" (there were no other qualifications to that statement, but no evidence to support it either).

<comment><USER23> Yeah, to its credit, the article brought it up but then kinda hand waved away "envoy had many more security issues than nginx". Having a huge load of C library dependencies in a user-facing service seems like a bug these days.

Part of reducing dependencies in my own software was a conscious decision to minimize future CVE exposure.

</comment></comment></comment></comment></comment></comment><comment><USER27> Sensing a bit of a trend here. Didn't another major player recently make the same switch?

<comment><USER28> It's a drop in the water compared to Nginx usage.

<comment><AUTHOR> That is indeed true. But, I remember the time when we were rolling out nginx back in 2000's and exactly the same thing was said about Apache.

</comment></comment></comment><comment><USER29> [https://h2o.examp1e.net/](https://h2o.examp1e.net/)

This is also good web server.Configuration is done in yaml. Also,it claims to be very fast.

</comment><comment><USER12> A shame they picked nginx in the first place, it has all the stats and critical features behind the paid edition. HAProxy is always a better choice for load balancing.

Besides that, it looks like the move was significantly driven by GRPC and profobuf. No surprise here, GRPC really doesn't work well over HTTP. Once a company start using the google stack, they have to move to more of the google stack to make it usable.

<comment><AUTHOR> Our technology stack is very gRPC friendly, so developer experience is actually better with it, than without (though this is very subjective.)

As for the middleboxes, using gRPC-WEB[1] allowed us to switch Desktop Client App to gRPC even behind firewalls/IDSes that do not speak HTTP/2 yet.

As for the HAProxy, Dropbox used to use (circa 2013) it specifically for loadbalancing, but we eventually replaced it with our Golang proxy. That said, recent HAProxy improvements (v2.0+) make it quite an awesome dataplane and an excellent loadbalancer!

[1] [https://github.com/grpc/grpc-web](https://github.com/grpc/grpc-web)

</comment></comment><comment><USER30> Thank you for the thorough comparison. Could anyone chip in whether a recent haprozy version would be a better choice than nginx and /or envoy in a similar case?

</comment><comment><USER31> Can somebody speak to why dynamic upstreams included in a file paired with `sudo service nginx reload` for prod deploys stopped scaling?

<comment><AUTHOR> It is easy enough for simple cases (and we used it for quite a while, until we moved to using Lua for that.) For more complex scenarios you will have new `server` blocks, certificates, tls tickets, log files / syslog endpoints, so the automation will end up interacting not with just a single dynamic upstream file but with rather large amount of system interfaces. Control-plane ends up being distributed between config generation, filesystem state, service configuration (e.g. syslog.)

On a more practical note, each nginx `reload` will double the number of workers, almost doubling memory consumption and significantly increasing CPU usage (need to re-establish all TCP connections, re-do TLS handshake, etc.) So there is only that many reloads that you can do in an hour.

<comment><USER32> nginx is not well suited for constantly reconfiguring your infrastructure on very hot servers. This is a problem when you expose such infrastructure configurations to users (think cloudflare), but otherwise you can just mitigate this problem by having a sane deployment strategy.

</comment></comment></comment><comment><USER33> One thing nice about OpenResty (nginx) and their Lua support is that it plugs in at TLS negotiation. Does Envoy?

<comment><AUTHOR> Can you describe your use-case?

If you are talking about the ability to select a certificate on the fly via `ssl_certificate_by_lua_block`[1] we are not aware of such functionality. If you are missing something, I would highly encourage you discuss it with the community on a github!

From Oleg Guba, Traffic Team TL, co-author, and person driving the deployment:

* ListenerFilters + NetworkFilters are flexible enough, that some of the custom logic could be just moved to the config.

From Ruslan Nigmatullin, our head Envoy developer:

If you are talking more about a custom verification code there is already couple of ways to do that:

* Client TLS auth Network Filter: [https://www.envoyproxy.io/docs/envoy/latest/configuration/li...](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/network_filters/client_ssl_auth_filter#config-network-filters-client-ssl-auth)

* Alternatively, if you are writing C++ extension you can use Network::ReadFilter, Network::ConnectionCallbacks.

[1] [https://github.com/openresty/lua-nginx- module#ssl_certificat...](https://github.com/openresty/lua-nginx- module#ssl_certificate_by_lua_block) [2] [https://github.com/openresty/lua- resty-core/blob/master/lib/...](https://github.com/openresty/lua-resty- core/blob/master/lib/ngx/ssl.md)

<comment><USER33> Wordpress and others use this to load certain on the fly. When you are a multidomain host this matters a lot.

You don't just load up a million cents as files and restart the server (though I do know a company that does something like this, but man, quite brittle).

</comment></comment></comment><comment><USER34> Is Condoleezza Rice still working for Dropbox?

<comment><USER35> She's on the board of directors: [https://www.dropbox.com/about](https://www.dropbox.com/about).

</comment></comment><comment><USER36> And finally we got nginx as legacy now, lul.

</comment><comment><USER32> Seems like they could have switched to openresty instead and saved quite a lot of effort in their migration, but oh well, they probably just couldn't handle the 1-indexing /s

<comment><USER37> Seems like they were already using openresty. Having used openresty professionally, I appreciate that it provides ways to write code to solve a lot of the problems outlined in TFA, but solving the problems out of the box is significantly better.

</comment></comment><comment><USER38> Who does Dropbox compete with these days? They have pretty much the highest prices for the least amount of value. The only reason I see them mentioned here frequently is their connection with Y Combinator.

<comment><USER39> I've admired Drew and the early Dropbox team for getting things done and shipped even when compiled python GUIs was edgy as the initial Rails version of Twitter was. But they shipped and validated the market. Now adding all those fancy and cool tech mentioned in the blog post will increase the complexity by a lot but it's not clear what are the real benefits. Does a decreased number of machines running really justify the migration and addition of complexity? Maybe they have some new products in the pipeline that built upon the new stack. Or they waste their time. We will see.

<comment><USER40> > Does a decreased number of machines running really justify the migration and > addition of complexity?

Of course it does. I am not sure why you think it doesn't.

<comment><USER39> servers are a commodity and cheap compared to runtime complexity

<comment><USER40> Yes, but it's a lot of servers.

<comment><USER39> How many? 5000 servers? As a public company it should not really matter at that size. Developers are way more expensive.</comment></comment></comment></comment></comment></comment>


Chaos: Classical and Quantum [pdf] - <AUTHOR> http://chaosbook.org/chapters/ChaosBook.pdf <comment><USER2> I accept chaos. I am not sure that it accepts me.

         —Bob Dylan, Bringing It All Back Home</comment>


Kenyan startup BRCK launches SupaBRCK device to solve Africa's internet equation - <AUTHOR> https://techcrunch.com/2017/03/08/kenyan-startup-brck-launches-supabrck-device-to-solve-africas-internet-equation/ <comment><USER2> How is this different from a regular modem?</comment>


Yitang Zhang Genius Fellow Twin Prime Conjecture - <AUTHOR> http://www.businessinsider.com/yitang-zhang-genius-fellow-twin-prime-conjecture-2014-9

<comment><USER2> That must be an obnoxious proof.</comment>


Visualizing Battle Data from the War of the Five Kings - <AUTHOR> http://popily.com/explore/notebook/battles-in-the-game-of-thrones/ <comment><AUTHOR> You can explore the whole dataset here: [http://popily.com/explore/source/game-of-thrones- battles/](http://popily.com/explore/source/game-of-thrones-battles/)

And visit its GitHub page here: [https://github.com/chrisalbon/war_of_the_five_kings_dataset](https://github.com/chrisalbon/war_of_the_five_kings_dataset)</comment>


It's Stephen Hawking's Birthday, but he's two unwell to deliver a speech. - <AUTHOR> http://www.telegraph.co.uk/science/science-news/9001187/Prof-Stephen-Hawking-too-unwell-to-deliver-own-70th-birthday-speech.html

<comment><AUTHOR> Happy birthday to one of the greatest thinkers of our time!

</comment><comment><USER2> check your spelling, it's "too" not "two"</comment>


Sequence.js - The responsive slider with advanced CSS3 transitions - <AUTHOR> http://www.sequencejs.com/

<comment><USER2> Fantastic plugin, shall be using this in my next project</comment>


Remote Work Report - <AUTHOR> https://about.gitlab.com/remote-work-report/ <comment><USER2> Remote work will never been an absolute thing. It depends on context, personal habits/preferences and most importantly: experience doing it over time.

I personally cannot work from home. COVID has made it worse as kids are home BUT even if I had the whole house to myself, I just cannot work from home. I NEED a dedicated office outside my house (yes I already have an office room in my house). Reason is simple. I don't have the discipline to work from home. I get distracted too easily. So I m not a good candidate for WFH. Do I want the flexibility when needed ? Of course. But do I WANT to work from home all the time ? Hell no.

I would say the future of work is not just remote. The future of work is "employers allowing more flexibility in work location" but as an employer myself, I am personally not in favor of 100% remote. That's me I know but sorry, not everyone is cut out for remote work.

<comment><USER3> Nobody minds if that's what works for you. We object when you force it on employees because it's what works for you, regardless of what works for them.

<comment><USER4> I imagine the GP also objects when remote work die-hards force remote work on people like them. According to the article, almost half of remote workers want to work for a company where _all_ workers are remote, leaving people like GP commenter out in the cold.

It seems large groups from both sides are unwilling to meet in the middle.

And that's for good reason, really. The reality is that in-office workers have an inherent advantage when it comes to activities that require interaction between people, such as promotions or work assignments. People who want to work remotely are going to want _everyone_ to work remote so that they aren't disadvantaged when it comes to those things, but then we are left with the problem of one group forcing their way of working on the other group.

<comment><USER5> > The reality is that in-office workers have an inherent advantage when it > comes to activities that require interaction between people, such as > promotions or work assignments.

I don't think those two things are an _inherent_ advantage, rather, it's the reality of managers that don't understand how to remote work.

If "work assignments" require in-person communication, it seems like something is severely broken with your work assignment system and/or process. For software development, to me, that is basically tickets, kanban/scrum/whatever, and the regular communication that takes place to discuss. This communication doesn't need to be "in-person" to work, which brings me to the next point: meetings.

Having remote people exposes many problems with meetings. One is having too many meetings, ad-hoc meetings, or agenda-less meetings. These are problems in-person too, but they're not as directly noticeable.

The other meeting problem comes more from how the meetings take place. The most remote-friendly orgs have a rule like "one person remote, everyone remote" which basically means everyone does the meeting with a webcam and headset, even if they're in the office. At a minimum, meeting rooms need good audio/video (as in: no PSTN speakerphones, and no laptop mics or webcams allowed), and all meeting invites are always sent with an online meeting URL, at a minimum the day before.

There _can_ be inherit advantage in being in-person both for ad-hoc technical discussions and building personal relationships, but if those are job _advantages_ I think it's also a management failure. Ad-hoc technical discussions should quickly be moved online and inclusive of remote people, and that's something a manager should be constantly encouraging/enforcing. It should also without saying that a manager that favors employees for promotions with whom they have better personal relationships isn't doing their job properly (and note this isn't directly a "remote worker" problem).

</comment></comment></comment></comment><comment><USER6> I've worked remotely for nearly 2 years now. The majority of that time I was the only remote engineer in a company of ~80 engineers. We went fully remote just over a month ago and it has been a huge quality of life boost for me. Before everyone went remote the communication was pretty lopsided where I had to make sure I was over communicating and inserting myself strategically. Now that everyone is remote it is a lot more natural with everyone on the same playing field

<comment><USER7> Yeah, same experience. For the first time I'm on equal footing with the rest of the company. I knew what I was getting into from the start, and I can get along just fine being the only remote person, but I won't deny this has me thinking about going with a fully remote company when this is all over.

</comment></comment><comment><USER8> Be careful of the companies that advertise remote as a "benefit" of the job.

They're usually looking to discount your salary by 30-50% by some arbitrary cost of living factor.

You bring the same value - whether that's delivered from New York City or Des Moines Iowa.

<comment><USER9> Let's not beat around the bush, specifically, Gitlab does this, IIRC.

<comment><USER10> Explained here: [https://about.gitlab.com/handbook/total- rewards/compensation...](https://about.gitlab.com/handbook/total- rewards/compensation/#paying-local-rates)

<comment><USER11> Great explanation of a bad practice. A company should pay for the value they get, which is independent of the location. These calculations never seem to take into effect all the cost savings of having a remote person (office building/parking/food/working space/etc). Instead, they almost always mark the employee as a second tier of worker

<comment><USER9> My company tends to do something similar for starting salaries, but that's because we're a consultancy, and our rates per-market are different.

However: In the long term if employees stay with the company long term, salaries tend to get bumped up to approximately the same. So you might get started lower, but your yearly pay bump will be higher.

</comment></comment></comment></comment></comment><comment><USER12> Very interesting study, thank you Gitlab. It would be great if the results were true and the trend could prevail in the long term. I'm one of these 16% "working remotely all the time" since six years (working frequently remote for ten years before already). I have more than enough interesting work, but I regularly had to deal with companies that were not interested in cooperation because I was not willing to work at least 50% on site. I am curious to see if Corona will change this attitude. I live in german speaking Europe, and perhaps the culture here is simply not yet ready for it.

<comment><USER13> Just curious: the companies you work with, where are they located? And how did you get in contact with them?

I'm also in Germany and working remote full time since ~1 year, I'm interested in your experience if you're willing to share.

<comment><USER12> I'm located in Switzerland, do my own acquisition and I have long-standing, stable cooperations with companies where I am known and trusted. I also regularly receive requests from recruiters where I am in the database; this usually happens the same way; their clients (in Switzerland and Germany) are very interested until the moment they realize that I am not interested in working physically on site with them (in addition I appear too expensive for most German clients). This is not a problem for me because I am established and can afford it. But for the younger ones, who have to build their business relationships first, the aforementioned mentality of the clients makes it very difficult to work in this way. The argument that you work three to ten times as efficiently as any local employee in an open-plan office and that this makes the project cheaper, even though the hourly rate is higher (just to name a few advantages), is something that hardly anyone who doesn't know you wants to hear.

</comment></comment></comment><comment><USER14> I've made this point before but the future of remote work has and will continue to have no dependence on what workers like nor will it on how "productive" workers are. Office's have perpetually been getting worse for workers(offices -> cubicles -> open office). So it's very clear companies have never chosen one office solution to another because it is the preference of the worker.

As for the argument of changes to "productivity". For starters very few of us work in roles where productivity is a directly measurable thing. Sure you can argue about commits, lines of code, ship times, but those are all nowhere near as measurable as "widgets-per-hour". On top of this we all know that a huge portion of roles out there are arguably not productive at all (and if they are it's very hard to measure). And again, when in the history of work has declining worker productivity been solved by improving conditions for the worker? If you company goes remote and you don't work as well that way, do you think your boss is going to go "oh! I'd better talk to leadership about getting those offices again!"?

The entire reason offices still exist is because of culture. For years every SV startup I knew said they needed an office in SF because the "VCs like to see that". There has been a lot of inertia towards offices.

Now that Covid19 has broken that assumption for a bit, I think we'll see a rapid shift to remote teams because it quickly becomes clear that offices are a liability. Anecdotally I already know one start up that can no longer afford their office and so are breaking their lease with no sense of what they'll do next (so remote is the default), and a well established, very traditional office culture firm that is already stating that everyone being in the office full time will not be the norm coming out of this.

<comment><USER15> Also I think COVID has forced companies into trying it when there might have been fear or apprehension before. It takes time/resources/commitment to even try out a work from home policy - but now everyone has been forced into it.

<comment><USER16> Unfortunately, this means that their first experience with "all remote" will come from a rushed implementation instead of a well-planned one. I fear some managers will draw the wrong conclusion about remote work in general.

<comment><USER17> > will draw the wrong conclusion

A risk. But it doesn't take much to get people on the right path.

1) trust your staff, give them autonomy and agency.

2) asynchronous transparent communication for discussions and decisions.

3) remove friction: few small tools for communication and collaboration, good audio, forum, wiki, git, etc. Services: shopping, childcare, etc.

And a bunch of smaller tricks. But trust, transparency, asynchronous coordination are the major points.

I've helped "rush" groups to full remote with less than 10h "training" during the last few months now that it suddenly became important to a lot of people. More time would have been great, but even a small bit can help a lot.

If you have experience of remote / distributed work, help out and teach others now that they really need it.

<comment><USER18> #1 is a non-starter for many managers in companies of all sizes. Unfortunately the personality-type that lends itself to accumulating power is not one that thrives off trust.

</comment></comment></comment></comment></comment><comment><USER19> Working fully remotely? In IT it's no-brainer, why would I spend time on everyday commuting, spend time in office where I can't feel fully comfortable, especially when company come up with open space idea and waste my productivity? I want to get shit done, receive money and live my life. Reimbursements? Employer should just pay more in salary, what's the difference if I rent a office or convert part of my home into office?

<comment><USER4> >Employer should just pay more in salary, what's the difference if I rent a office or convert part of my home into office?

I wish. My experience is that companies advertise "Remote work possible" as some sort of job perk, and use it as justification to actually pay you a _lower_ salary.

</comment></comment><comment><USER20> Typically I work remote 3-5 days a week.

There is a lot of talk about remote work and COVID-19 and for me remote work in the age of COVID-19 ... it has been terrible. Mostly because I have kids, and my wife and I are both trying to work remote, and attend to the kids schooling ... it's a terrible combination for getting anything done on a 'regular' schedule.

I suspect people's remote work during COVID-19 experiences are pretty wide ranging.

<comment><USER21> You aren't alone. It's easy to conflate "remote" with what's happening right now, but it's not the same. Crisis-induced work-from-home while doubling as a homeschool teacher is not the same as properly organized remote work.

Less to do with home and more to do with everything outside of work impacting work.

More here: [https://twitter.com/shanselman/status/1252040170783641600?s=...](https://twitter.com/shanselman/status/1252040170783641600?s=12)

<comment><USER22> Well said! Early into COVID I thought it'd bring a surge in remote work because we'd see how much work really can be done from anywhere.

But COVID-remote work has been way different. I've been a full remote worker for 3 years usually working out of coffee shops, and I'm much less productive now because a) I have to work from home, and b) it's generally harder to stay focused during a global pandemic. And I'm not even a parent.

I do hope those who are working remote for the first time don't associate remote work with a bad work life now.

</comment></comment></comment><comment><USER23> "All-remote is the purest form of remote work, with each team member on a level playing field. 43% of remote workers feel that it is important to work for a company where all employees are remote."

This is interesting as it runs counter to the opinion you hear a lot that is in the vein of live and let live/give people a choice/different people have different preferences. I do think there's some truth to it. While I don't really have trouble under normal circumstances as someone who is mostly remote with a bunch of people in a conference room on a call, it is a little nicer with everyone individually on the video call. [ADDED: But the company is about 50% remote so there are often people from a variety of locations on a call even if some are in a conference room.]

I think it's certainly true, if only a few people are remote, that can be challenging.

<comment><USER24> I have worked remotely for a company that was otherwise very much a traditional non-remote environment; I have experience partly distributed teams and now managing a fully remote one.

I think partly remote will always, without an exception, create a significant information asymmetry that will result in non-remote workers becoming the leaders in the company. (plug, sorry:) I have written a small post about migrating to remote: [https://blog.patientsknowbest.com/2020/04/01/51-basic- rules-...](https://blog.patientsknowbest.com/2020/04/01/51-basic-rules-of- managing-distributed-teams) \- even in _theory_ you could fully embrace remote workers if some others see each other in person regularly, the latter group won't, can't and likely, shouldn't stop exchanging information in ways that 1) are more efficient 2) excludes remote workers.

<comment><USER25> +1 for the information asymmetry. I'm currently working remotely 4 days a week and there are 2 other devs working remotely between 80% and 100% of the time.

One of the main issues is "oral tradition". Information is shared from dev to dev during coffee breaks, and everyone is supposed to somehow know it. The solution is to work as if everyone is working remotely, and in that case that means putting information into writing, either by communicating through archived and searchable channels (ie Slack) or writing docs.

</comment></comment></comment><comment><USER26> I really don't know what to expect for remote work in the future. The current trap is to think that we are currently doing remove work. We are not, we're doing remote work in a very unusual setup. Kids and partners are at home with us, we can't really leave our house, etc. This is _not_ real WFH.

Additionally, a lot of companies were pushed into that almost over night without preparing for it. No experience with it, no tooling in place, no processes, etc. Maybe a lot of them experienced some loss in productivity due to that and will just conclude that remove work really isn't for them, it sucks.

The 2 things I really hope for: * people experiencing a personal boost in productivity and better quality of life (mostly due to not having to commute) will be vocal about not going back to the "old ways" * companies claiming that "proper work/collaboration can only happen in the office" will finally change their tune and end the hypocrisy. When forced to do it, they somehow found a way. Maybe it's time to final end this charade. Especially in tech, the work that can only happen in an office is so marginal.

</comment><comment><USER27> > 43% of remote workers feel it is important to work for a company where ALL > employees are remote…

As a full time remote worker, I've also felt that having everyone else is great. In every case I've work with a colocated team, they end up snubbing you in weird ways.

This snubbing is just a cultural thing. There's no technical reason remote workers should feel left out if working with another team.

I've found that most colocated team members rarely write well, and often do not track, or even follow up on complex team decisions. When everyone is remote, it often forces some better communication. Frequently, the teams have to "double up" on the media used to communicate, which almost always requires some written communication.

Now that everyone's remote in quarantine, I've heard complaints from the colocators about "having to overcommunicate". But really, it's just learning to communicate well.

This metric of "how many all-remote workers want everyone else to be remote", really seems like a great test for "how well does your company communicate?"

<comment><USER28> In my case it's the higher ups snubbing the remote workers and deliberately excluding them. I think they're trying to "encourage" non remote work but are actually being shitty.

</comment></comment><comment><USER29> It's difficult for me to give a true assessment of what remote work would be like in normal times. Since I live alone and social events are cancelled I feel like I'm craving social contact and definitely missing that aspect of work. I also don't have any space in my apartment to work from so I'm set up on the kitchen table.

I do wonder if the exceptional circumstances of the current sudden shift to remote (lack of other human contact, unplanned setups at home) will cause a backlash __against __remote work.

<comment><USER30> There may be some backlash, given how painful the transition has been for a lot of people. I think a lot of people are conflating "remote work" with "social distancing". The later is the cause of a lot of your feelings of loneliness. The former can significantly increase your flexibility to maintain quality relationships. As someone who works 100% remotely, this has been an especially lonely period for me as well.

Right now, many people are still getting used to working from home, and many I suspect consider this to be a temporary measure, which has prevented them from getting settled. In a real switch to remote work, you would be properly invested in setting up a long-term productive environment. The beauty of remote work is you would have the agency to experiment and find what habits and schedules makes you the most productive, without the added constraints of the office. This process would probably take several months, and for a while you would miss the structure of the office, but I think it has the possibility to increase your productivity and quality of life.

For me, remote work does not mean that I work alone, it just means I work with a group of other remote workers that I consider to be close friends. I think it has the potential to _increase_ quality social interactions while working, not decrease. In a society where more people are working remotely, I think the ability to forge relationships outside of work will only increase.

</comment></comment><comment><USER31> Why was the title of this submission changed to the more uninteresting "Remote Work Report" from the original "The Remote Work Report by GitLab: The Future of Work is Remote"?

<comment><USER23> Someone probably thought the title was too provocative and therefore more likely to touch off the usual back and forth between

\-- those who feel they have to evangelize remote work so that there will be more/better paid remote positions for them and

\-- those who really hate the current situation (who doesn't) and are worried that not coming into the office will be normalized and many of their co- workers will stop coming in as a result

<comment><USER32> > those who really hate the current situation (who doesn't)

<raises hand>, in the context of this report. 100% WFH fine with me. Not being able to go just buy local stuff when I want I'm not so keen on, but that's not what this is about.

<comment><USER23> In my case, I'm almost fully remote but I also usually travel about a third of the time--so I'm a bit stir-crazy. I just meant that it's overall a stressful situation for a lot of people which makes remote tougher overall.

</comment></comment></comment></comment><comment><USER33> I'm totally for remote work when the context and company is adequate. I just wish salary wasn't as low, these days when a company says 'remote possible' it almost always means you're gonna get paid less.

[edit spelling]

</comment><comment><USER34> Remote work should be an absolute thing, mandated by law, or at least strong incentives, to reduce our carbon footprint. Unless you truly need to go to a central location (laboratory, healthcare, etc.), you should work remotely.

I saw a study that said 40% of SF Bay Area jobs could be remote. If all major metros went remote, this would put a dent in our CO2 output.

Advantages of offices, face-to-face interaction, etc. just doesn't matter. Climate change is an _existential threat_ according to the experts, so we should actually take it seriously and modify our society accordingly.

</comment><comment><USER35> I'm pro remote work, but it's questionable as to why GitLab pushes their remote work ideas so much? Is it to become some sort of remote work consultant? Is it an angle of marketing?

<comment><USER36> Because it cost them less, and they magically "present" that it's a good thing. They pay different (lower/higher) salaries depending where you are located.

</comment></comment><comment><USER37> Even with reports like these, I think it will be tough to convince managers that are set in their ways to open up to allowing their employees to work remotely.

While anecdotal, most companies seem to have approached the current state of affairs as a mild inconvenience that will be gone soon, and aren't looking to keep remote work an option going forward, even though it's working out well, which is a shame.

</comment><comment><USER38> How do people handle async communications when in differing time zones? The team was forced to work remotely as opposed to an office as a result of SARS- CoV-2. I'm a core developer back in Sydney, with the rest of the company in San Francisco (I'm essentially -7 hours). A lot of team members don't like me not being able to reply when they send a message because they don't like having to context switch from tasks that they're blocked on, meanwhile I have no problems with this aspect as I tend to like to work on things simultaneously and can context switch quickly (could it be my ADHD being a super power here?). How do remote teams deal with this effectively?

We currently have org/dev planning meetings every other day (Monday, Wednesday, Friday 10:30am PDT, which is 3:30am my time until sometimes 6am) which I'm up for, but I can't maintain that every day as it gets too much (I wake up around midday Sydney time).

<comment><USER39> You have three meetings a week that can sometimes last two and a half hours in the middle of the night and no one on your team sees that as an issue?!

The key to making big timezone differences work is to make communication as asynchronous as possible and where that can't be done make it as humane as possible. Clearly these meetings can be scheduled in times where both sides should naturally be awake. I work from Iceland with people on the East and West Coast so about the same time difference and I'm mostly in meetings in the early evening although nothing so epicly long. Your colleagues could be doing the same. We also alternate so some are early morning for them and afternoon for me.

For people getting blocked it really depends on what it is but for the most part I do as you do and park what I'm working on and get on with something else. If it's something simple that can be fixed with a bit of back and forth I'd try pre-empting these issues (e.g. are you just being used as a really expensive form of live documentation).

</comment></comment><comment><USER40> As we've learned from building for remote teams [1], is that it's really about _how_ you set a process for async communication, and not just about the tools. This is why we've been heads down since the outbreak helping work-from-home teams set the right processes of communication using us and other tools.

It's really around building a healthy culture of working from home, and not encouraging multiple disruptions during the day, and actively doing so, thinking that it unites teams. We wrote a basic guideline [2].

[1] [https://standups.io](https://standups.io)

[2] [https://standups.io/blog/a-basic-guideline-for-async- communi...](https://standups.io/blog/a-basic-guideline-for-async- communication/)

</comment><comment><USER41> It's interesting that 87% of people say they are satisfied with current tools and processes that enable remote team communication, yet 35% list collaborating with colleagues and clients as a top challenge. There seems to be a disconnect between those two sections of the report.

<comment><USER42> What that says to me is, the tools and processes are fine. Getting people to use them is the challenge.

<comment><USER21> That's essentially how we interpreted it as well. Tools are still important, and useful in the right context, but we're in a period now where tools are not hindering remote proliferation.

</comment></comment></comment><comment><USER43> Remote work is great and all... because that's our only option.

In the long term, I suspect there may be a greater inclination towards remote work, not as much as this report suggests, but overall work at office is here to stay.

I need to go outside and have a physical seperation between work and home.

<comment><USER44> Imagine if it were the norm though. You could move out of the Bay Area and afford a home with a dedicated office space. I worked remotely for 17 years and I found ways to create a separation. Sadly, I fear you are right though - there may be a slightly larger WFH push, but inertia of management by proximity will still be the norm.

<comment><USER45> Well, not a GitLab you couldn't because they'll cut your salary tremendously (40% if I moved to my second home in Oregon). Oregon is a whole lot cheaper than the Bay area, but it's not 40% cheaper.

</comment></comment></comment><comment><USER46> Great report!

I've been working remotely for a few years now so a bit biased. But I would say that the COVID situation with regards to remote work has shown how many benefits there would be for the wider society if more people worked from home more often:

* Less traffic

* Less noise pollution

* Less air pollution

* Less stress

* More energy for things outside of work

All these would increase the quality of life for a large part of the population, decrease the number of avoidable lifestyle diseases and deaths, and would help cut the global carbon emissions too.

COVID is not an ideal situation to start your work from home experience but I do hope that some people will find it valuable enough to make more lasting changes after the crisis is behind us.

</comment><comment><USER47> Labeling work remote or non-remote (on-site?) becomes increasingly irrelevant. Need for physical presence in a given geographical location is mitigated by good planing and quality of tools allowing to share information effectively. Why dont we stop calling things remote or not, but focus more on improving the tool sets needed to better plan and share thing between humans.

All of these tools are needed wether the team is physically on the same geo location or spread out. What changed now is that its much harder to justify not having them anymore.

</comment><comment><USER48> I do enjoy being in the office sometimes but not every day. After this is all over I imagine many companies will go "remote work" for at least part of the time. There we're many naysayer companies that were forced into doing it and now realize work still gets done.

Longer term this whole experience will likely be a step-change in what "office work" looks like moving forward and that probably means a lot less commercial office space needed.

<comment><USER49> Kinda agree. I could do 3 out of 5 days in the office without any negative impact, in fact it would be positive in terms of productivity and I would generally be happier (which would further up my productivity).

I wouldn't want to work 100% from home either.

Hardest part is client interaction, video conferencing not the same as face to face but its clear now that not all client meetings need to be face to face once people are proficient with the technology and the technology gets better which it will.

Curious on what people think about home working and VR... Will the tech help? Anyone experimenting with VR in this context?

</comment></comment><comment><USER50> The report appears to be limited to those residing in the USA, UK, Canada and Australia. This is stated nowhere in the survey methodology.

<comment><USER21> The 'Residence Country' is listed on Page 7. Fair point on reiterating in the 'Methodology' section on Page 3. Thanks!

</comment></comment><comment><USER51> This is a great read. I am especially happy that they are not asking for an email to download the report. I understand why some companies are doing this, but I went from web page to reading with no friction.

</comment><comment><USER52> >>> The Future of Work Is Remote Yes, in the sub-segment of economy where Gitlab is applicable it's true. It's been true for a long time, even before the Covid-19 virus. But for a large segment of the economy it isn't. I need a hair cut, but all barber shops are closed. Can Gitlab help? I want to go out for a dinner, I'm tired of take-outs. Can Gitlab help? A telecommuting hostess, followed by a telecommuting waitress, followed by a ... I've been working remotely for the last several years, but it has it's place. It won't fundamentally change what was already happening, except perhaps accelerating the trend.

<comment> jon-wood This feels like a strawman argument. Of course Gitlab aren't suggesting that chefs, barbers, and car mechanics are going to start working entirely remotely and transmitting the product of their work via the internet. Its pretty clear from the article that they're talking in the context of knowledge work.

<comment><USER53> Indeed. I'd further say that remote work can benefit those occupations that cannot work remotely!

If we imagine that a large percentage of the population doing work that can be done from home is doing so, there will be less traffic on the roads, more time for people to go down to their local coffee shop or restaurant to grab a bite, more real estate for non-WFH companies to rent (possibly with lower costs), or even office buildings that could be converted into habitation (and thus allowing the people whose work has physical components to live closer and lessen their commutes).

Not to mention pollution, quality of life, and a healthier society. Sure, it's not a monumental impact at a global level, but I'd count it as a positive change for the most part.</comment></comment></comment>