Forem: Vladimir Gordeev 🇷🇺

Why your docker builds are slow?

Vladimir Gordeev 🇷🇺 — Wed, 24 Oct 2018 09:25:19 +0000

The important thing when working with docker is to write Dockerfile instructions in the right order. It may speed up the build significantly.

Every instruction in Dockerfile is similar to a commit in git branch. If you change something in the middle, everything that follows after should be executed again (rebased in git terms). Everything that was before change can be reused.

All files that you add using COPY or ADD are considered as dependencies for everything that runs after.

Hence two rules to speedup your image builds:

what changes rarely should be executed first
avoid using 'ADD .' it makes everything depend on everything

Add Gemfile, rebar.config, mix.exs or any other file where your dependencies specified. Install dependencies, compile them. And only after that add your app source code.

A bit about programming languages

Vladimir Gordeev 🇷🇺 — Wed, 24 Oct 2018 09:06:44 +0000

It feels like there are two distinct programming languages that PL designers habitually mix into one.

Calculating language. It's code lives inside box with explicitly specified inputs and outputs. There is no IO, nor time inside the box.
Program might be executed lazily or eagerly. Instructions might be executed sequentially, or may remind some kind of graph, in which exact path of execution is not clear. The main thing is that there are inputs and expected outputs. Reminds code in Prolog or Haskell.
Managing language. It's code runs inside loop-ring, instructions always executed eagerly and sequentially. Unlike boxes, there is a time inside ring, and it flows into one direction.
Programs written in this language do all IO: receive data, process it using boxes from the first language, save state, send data outside. This language also describes components of the system and their dependencies.

Reminds Erlang with it's receive-after-end and send. Reminds supervisor config, kubernetes service config.

If we split these languages yet use them together, it may lead to something interesting. It may produce more powerful abstractions specific for tasks of each language. It may lead to something more convenient, more effective in terms of computer-human interface.

Things to consider before creating a new programming language

Vladimir Gordeev 🇷🇺 — Wed, 24 Oct 2018 08:19:01 +0000

If you are thinking about creating a new programming language, consider the following:

Code in this language is going to be ugly. People gonna abuse all wonderful features in a way you could never imagine.
People would have to work with lots of old, incomprehensible code that breaks all the time. Meanwhile the author of the code would already run away for easy money in blockchain startups.
People wouldn't have any time to do the refactoring. If the code is inconvenient to test -- it won't be tested at all.

If you consider all of these things and still decide to create a new PL, you may make a real breakthrough.

Unlike those pesky languages with monoids in the category of endofunctors.