Terraform 0.12 language looks bad

I was hoping that smart guys vs bad situation will have another outcome but Terraform language for version 0.12 looks bad… as languages of Puppet and Ansible.

I’m not saying that people that made Puppet and Ansible are not smart. It’s that we could learn from the mistakes they made… unless we don’t consider those being mistakes.

Puppet and Ansible went through very similar difficult situation. They have limited themselves to a declarative format and then they tried to accommodate the real life. Terraform has this situation right now.

The situation is:

  • Declarative format being used
  • People need something more powerful, like a programming language because … real life where conditionals, loops and data transformations make much more sense than working around declarative languages limitations.

Interestingly enough, they all did not switch to a proper programming language. Maybe because that would be at least partially admitting that the product should have been a library in the first place?

Terraform is actually in very crappy situation because even if they decide to expose everything as a library as the main interface, I don’t see people start using Go for “infrastructure as code”. Not as smooth as Ruby or Python anyway.

Happy coding, everyone!

Update (2018-07-21):

On a bit more positive note, the new splat operator looks like an improvement.

Update (2018-07-27):

Terraform looks even more like a “normal” language with Conditional Operator Improvements and null value. The conditional operator fixes previous oddities that it had.

Update (2018-08-02):

Terraform got type system. Looks powerful. Just need to see that Terraform does not evolve to Scala 🙂

Update (2018-08-11):

New template syntax brings more raw power. Looks good.

Update (2018-08-26):

  • HCL to JSON one-to-one mapping. When I read “having a clean 1:1 mapping between HCL and JSON, and ensuring every feature of HCL is supported in JSON” I immediately thought that there must be converting tools then… and was not disappointed 🙂 “In future versions of Terraform, we will also support native tooling to convert HCL to JSON and JSON to HCL cleanly (including comments)”
  • “Comments in JSON” – nice!


Terraform becomes a programming language

Declarative languages failure

Approach that in my eyes failed, again and again, is to start with your own declarative language and then with time grow the language. (SQL being among notable exceptions)

Puppet is the best example. map and each, added in Puppet 4.0.0 are, in my opinion, just two in a sea of evidence that the envisioned simple format has failed to handle the needs of the real world.

Ansible’s loop looks bad as the whole idea of making top levels of programs in YAML based syntax (and the rest in Python).

In my opinion, it makes more sense to create a language first and then libraries for it, not a library and then a language around it.

My hope for Terraform

I think Terraform guys are smart. Among other things, it manifests in implementing data sources. Data sources make Terraform much more flexible. I think it’s very clever.

Terraform, which started declarative, are now inventing their own programming language. They are going the way of Puppet and Ansible. I hope they can do better, in this awkward situation: there are quite a lot of constraints on the programming language because of the existing syntax and semantics.

Happy coding, everyone!


List of JSON tools for command line

I am considering making a JSON parsing and generating command line tool. Started with looking around a bit. Below is a list of existing JSON command line tools. Numbers are [GitHub stars] at the time of writing this post. (… contributed by …) means that this post was updated with the item.

  • jq [11126] – filter, extract, modify and output JSON or text using DSL
  • jid [4426] – “You can drill down JSON interactively by using filtering queries like jq.” (item contributed by /u/Tacticus)
  • gron [4103] – convert JSON or JSON lines (from file/stdin/url) to text (path=value) which can be processed with grep/sed/diff; the tool also supports converting back to JSON after such processing
  • jo [2209] – generate JSON based on command line arguments and stdin; can read data from files and place it as base64 encoded values
  • JSON.sh [1635] – written in shell/gawk; “traverses the JSON objects and prints out the path to the current object (as a JSON array) and then the object, without whitespace”
  • underscore-cli [1588] ‘THE “Swiss Army knife” tool for processing JSON data – can be used as a simple pretty-printer, or as a full-powered JavaScript command-line’. Added on 2019-09-30 following comment from @joeytwiddle.
  • jsawk [1239] – focused primarily on filtering and transforming a list (or an object). Update 2019-09-30: as @joeytwiddle suggested in comment, the project appears to be unmaintained and doesn’t work with recent Node.js versions. Latest commit and latest closed issue are from 2015.
  • json (by trentm) [1218] – “massaging JSON on your Unix command line”; JS-like syntax for extracting values; in-place file editing
  • rq [1007] – awk/sed-like tool for structured data; supports several formats, including JSON
  • TickTick [469] – use JSON syntax directly in bash; “This is just a fun hack”
  • jshon [309] – very CLI-ish way to extract, manipulate and output the data
  • jl [308] – “a tiny functional language for querying and manipulating JSON”; visually reminds Haskell
  • jsonpp [244] – JSON pretty printer (item contributed by /u/ferbass)
  • fx [227] – conveniently run your JS code to manipulate JSON.
  • RecordStream [224] – create, manipulate and output records; supports JSON; Perl-based so grep expressions for example are in Perl.
  • JSON.awk [186] – JSON.sh fork in awk; after fork the projects added different features.
  • jp [184] – “command line interface to JMESPath” (link contributed by Evgeny Zislis)
  • json-command [143] – conveniently manipulate JSON using JS.
  • jsonv.sh [130] – convert JSON to CSV; specify paths in JSON to
  • jgrep (aka “JSON-grep”) [78] – “Command line tool and API for parsing JSON documents” in Ruby (item contributed by /u/tophlammiepie)
  • jsed [48] – manipulate and extract data; somewhat similar to jsawk in mindset
  • jayin [10] “Piping with js at terminal”. Added on 2019-09-30 following comment from @joeytwiddle.
  • jsongrep [9] (by dsc) – extract data at given path using shell globs and output one per line
  • jc [2] – “jc is used to JSONify the output of many standard linux cli tools”. Added on 2019-10-29 following comment from Kelly Brazil.
  • jsongrep [0] (by terrycojones) – easily extract data at given path

Honorable mentions

Update 2018-09-10:

I’ve added related post in which I argue that jq functionality belongs to a shell.

If you feel that some project is missing from the list, please let me know in comments below.

No, not everybody uses X

How likely are you to give the wrong answer when everybody in the group gives the wrong answer? More likely than without the group. That’s what Asch conformity experiments have proven.

Marketing people know that. So when you get the impression  that “everybody uses X”, please be aware that it can be intentional and maybe does not match the reality. It can be just a trick. Bloggers for example, have incentives to write about X (consultants that can make money if you adopt X).

Makers of X must continue to grow no matter what

I don’t want to accuse any specific firm or product in this post but I suspect the “coolest”, the most advertised and the most pushed down our throats products. There is no guarantee makers of X are interested in your success. They are surely interested in their own growth and success.

Hope this post increases your chances to survive next marketing attack just by being aware of yet another deceitful marketing technique.


How fucked is AWS CLI/API

In the 21st century, we can do significantly better than this crap AWS CLI. We just need to think from the users’ perspective for a change and not just dump on users whatever we were using internally or seen in a nightmare and then implemented.

Think from the users’ perspective

I’m working on a solution which is described towards the end of the post. It’s not ready yet but the (working btw) examples will convince the reader that “significantly better” is very possible… I hope.


I’m building AWS library and a command line tool. Since I’m doing it for a shell-like language (NGS), the AWS library that I’m building uses AWS CLI. Frustration and anger are prominent feelings when working with AWS CLI. I will just list here some of the reasons behind that feeling.

AWS CLI/API – WTF were they thinking?

Overall impression

Separate teams worked on different services and were not talking to each other. Then the something like this happened: “OK, we have these APIs here, let’s expose them. User experience? No, we don’t have time for that / we don’t care”.


Representing a map (key-value pairs) as an array ( "Tags": [ { "Key": "some tag name", "Value": "some tag value" }, ... ] ), as AWS CLI does is insane… but only when you think about the user (developer in this case) experience.

AWS Tags – no, not in this form!


When listing EC2 instances using aws ec2 describe-instances, the data is organized as list of Reservations and each Reservation has list of instances. I’m using AWS for quite a few years and I never needed to do anything with Reservations but I did spent some time unwrapping again and again the interesting data (list of instances) from the unwanted layer of madness. It really feels like “OK, Internally we have Reservations and that’s how our API works, let’s just expose it as it is”.

Who da fuck ever used Reservations?

Results data structure

AWS CLI usually (of course not always!) returns a map/hash at the top level of the result. The most interesting data would be called for example LoadBalancerDescriptions, or Vpcs, or Subnets, or … ensuring difficulty making generic tooling around AWS CLI. Thanks! Do you even use your own AWS CLI, Amazon?


Kind of the same but not really

Security Groups

These are of course special. Think of aws ec2 create-security-group ...

  1. --group-name and --description are mandatory command line arguments. For now, I haven’t seen any other resource creation that requires both name and description.
  2. The command returns something like { "GroupId": "sg-903004f8" } which is unlike many other commands which return a hash with the properties of the newly created resource, not just the ID.

Elastic Load Balancer

Oh, I like this one. It’s unlike any other.

  1. The unique key by which you find a load balance is name, unlike other resources which use ids.
  2. Tags on load balancers work differently. When you list load balancers, you don’t get the tags with the list like you have when listing instances, subnets, vpcs, etc. You need to issue additional command: aws elb describe-tags --load-balancer-names ...
  3. aws elb describe-load-balancers – items in the returned list have field VPCId while other places usually name it VpcId .

Target groups

aws elbv2 deregister-targets --target-group-arn ...

Yes, this particular command and it’s “target group” friends use ARN, not a name (as ELB) and not an ID (like most EC2 resources).

DHCP options (sets)

(Haven’t used but considered so looked at documentation and here is what I found)

Example: aws ec2 create-dhcp-options --dhcp-configuration "Key=domain-name-servers,Values=,"

Yes, the create syntax is unlike other commands and looks like filter syntax. Instead of say --name-servers ns1 ns2 ... switch you have "Key=domain-name-servers,Values=" WTF?

Route 53

aws route53 list-hosted-zones does not return the tags. Here is an output of the command:

 "HostedZones": [
 "Id": "/hostedzone/Z2V8OM9UJRMOVJ",
 "Name": "test1.com.",
 "CallerReference": "test1.com",
 "Config": {
 "PrivateZone": false
 "ResourceRecordSetCount": 2
 "Id": "/hostedzone/Z3BM21F7GYXS7Y",
 "Name": "test2.com.",
 "CallerReference": "test2.com",
 "Config": {
 "PrivateZone": false
 "ResourceRecordSetCount": 2

Wanna get the tags? F*ck you! Here is the command: aws route53 list-tags-for-resources --resource-type hostedzone --resource-ids Z2V8OM9UJRMOVJ Z3BM21F7GYXS7Y . Get it? You are supposed to get the Id field from the list generated by list-hosted-zones, split it by slash and then use the last part as resource ids. Tagging zones also uses the rightmost part of id: aws route53 change-tags-for-resource --resource-type hostedzone --resource-id Z2V8OM9UJRMOVJ --add-tags Key=t1,Value=v11

… but that apparently was not enough differentiation 🙂 Check this out: aws elb add-tags --load-balancer-names NAME --tags TAGS vs aws route53 change-tags-for-resource --resource-type hostedzone --resource-id ID --add-tags TAGS and aws elb remove-tags --load-balancer-names NAME --tags TAGS vs aws route53 change-tags-for-resource --resource-type hostedzone --resource-id ID --remove-tag-keys TAGS . Trick question: on how many dimensions this is different? So wrong on so many levels 🙂

Here is another one: when you fetch records from a zone you use the full id, /hostedzone/Z2V8OM9UJRMOVJ , not Z2V8OM9UJRMOVJaws route53 list-resource-record-sets --hosted-zone-id /hostedzone/Z2V8OM9UJRMOVJ


(many more to come)

Expected comments and answers

Internet discussions are the best 😉

Just use Terraform

I might some day. For the cases I have in mind, for now I prefer a tool that:

  1. Is conceptually simpler (improved scripting, not something completely different)
  2. Doesn’t require a state file (I don’t want to explain to a client with two servers where the state file is and what it does)
  3. Can be easily used for ad-hoc listing and manipulation of the resources, even when these resources were not created/managed by the tool.
  4. Can stop and start instances (impossible with Terraform last time I checked a few months ago)

Just use CloudFormation

I don’t find it convenient. Also, see Terraform points above.

By the way, the phrases of the form “Just use X” are not appreciated.

You just shit on what other people do to push your tools

Yes, I reserve the right to shit on things. Here I mean specifically AWS CLI. Freedom of speech, you know… especially when:

  1. The product (AWS API) is technically subpar
  2. The creator of the product does not lack resources
  3. The product is used widely, wasting huge amounts of time of the users

If I’m investing my time to write my own tool purely out of frustration, I will definitely tell why I think the product is crap.

Is that just a rant or you have alternatives?

I’m working on it. The command line tool is called na (Ngs Aws). It’s a thin wrapper around declarative primitives library for AWS.

There might be a solution to this madness!!!

The command line tool that I’m working on is not anywhere ready but here is a gist of what you can do with it:

# list vpcs
na vpc

# Find the default VPC
na vpc IsDefault:true

# List security groups of all vpcs which have tag "Name" "v1".
na vpc Name=v1 sg

# Idempotent operations, in this case deletion.
# No error when this group does not exist.
# Delete "test-group-name" in the given vpc(s).
na vpc Name=v1 sg GroupName:test-group-name DEL

# List all volumes which are attached to stopped instances
na i State:stopped vol

# Delete all volumes that are not attached to instances
na vol State:available DEL

# Stop all instances which are tagged as
# "role" "ocsp-proxy" and "env" "dev".
na i role=ocsp-proxy env=dev SET State:stopped
  1. Na never dumps huge amounts of data to your terminal. As a human, you will probably not be able to process it so when number of items (rows in a table actually) is above certain configurable threshold, you will see something like this:
    $ na vol 
    === Digest of 78 rows ===

    It will show how many unique values there are in each column, min and max value for each column. Thinking about displaying top 5 (or so) top and bottom values for each column.

  2. Na has concept of “related” resources so when you write something like na i State:stopped vol , it knows that the volumes you want to show are related to the instances that you mentioned. In this particular case, it means volumes attached to the instances.
  3. Note the consistency of what you see in output and arguments to CLI. If something is called “State” in the data structure returned by AWS CLI, it will be called “State” in the query, not “state” (“–state”).

I will be updating this post as things come along.

Just use X


Typical conversation on the Internet.

I’m having this situation, I’m trying to do blah using blah and it doesn’t work for me because blah. How do I proceed?

Invariably, one of the answers is

Just use X

And to that I would like to answer right now:

Go fuck yourself!

Your answer shows lack of thought and arrogance. In addition, chances are that X is a blogosphere-hyped tool or product. Here are some suggestions for next time, instead of “Just use X”:

  1. Is there a reason you are not using X? I had similar situation, tried to achieve what you are trying to achieve and had positive experience.
  2. I haven’t tried myself, but I heard about X which I think should solve your problem, you should probably take a look if you haven’t yet.

Hope this helps both sides of the discussion.

You are welcome to link to this post when you get “Just use X” response.

Google deleted our G Suite (now recovered)


We, at Beame.io LTD, have been using G Suite for a few years now. At the moment of the story, we had 2FA enabled for all accounts except for one, which was stuck (because of our process) at setup phase. This account had no administrative privileges.

Pending meeting

On 2018-03-22 there is a scheduled remote meeting with big and important client for which we need to prepare. We estimate that the outcomes of this meeting will affect our partnership with the client. Most of the documents we need to deal in order to prepare to the meeting with are in Google Documents.

Involved people

In the events below we will mention employees A, B, C, and D. Employees A, C, and D have (had actually) admin accounts.


Google deleted all our G Suite data. All important data is recovered by now.

  1. 2018-03-18 – We got email notification about removal of G Suite. The notification went unnoticed because the domain in the subject and in the body of the email is a domain we do not use. The old domain (mentioned in the email) was primary G Suite domain.
  2. 2018-03-22 – Our G Suite is deleted because we did not respond to the email.
  3. 2018-03-27 – Support finally says that the data is unrecoverable. After more than an hour an email from another person in support gives us some hope.
  4. 2018-03-28 – We are requested to prove domain ownership. The data and accounts are either being restored or partially restored.
  5. 2018-03-28 – Restore is in progress. Most accounts are available.
  6. 2018-04-01 – The last (and the most important account) was recovered.

It took 5 days to tell us that we are completely f*cked. All our documents and emails are gone. The next day our stuff is being recovered.

Failure to respond to an email gets your G Suite deleted within days.

After recovering the data, Google failed to tell us that they have finished. We were contacted later.

Last update of this blog

2018-04-12 12:52 UTC+3

Timeline of events

2018-03-22 09:56 UTC+2

Message from A to the team – email account doesn’t work. B reports that he observes the same problem. It quickly becomes clear that we all can not access our accounts.

10:21 UTC+2

We have disproved our first theory – we accidentally did not pay for the service. Our Money guy says we paid.


C & D fail to find any obvious way to contact G Suite support except for Twitter.

Around 11:15 (twitter does not show exact times)

Conversation using PM with @gsuite .


looks like our gsuite domain was deleted and we can’t log in but we can’t phone google support because it requires PIN … which you get when logged in


Hi there, what is the domain name on the G Suite account? Please send a full screenshot of the error message you receive when you access http://admin.google.com from an incognito window https://support.google.com/chrome/answer/95464?co=GENIE.Platform%3DDesktop&hl=en …. -MO

D: pastes screenshots

The conversation continues in parallel to other things below.

11:42 UTC+2

Failing to get through phone support D opens new G Suite domain to get PIN to get some support.


D contacts G Suite support on the phone using the PIN from new G Suite domain.

11:49 UTC+2

Following phone conversation with the support, D gets email. The email does not contain the promised link to a form which D should fill.

11:53 UTC+2

D gets email with a link to account recovery form. D misses the email because he is talking to C, answers the previous email and tries to get to G Suite support via Twitter. D sees this email after a while, when a case using the form is already opened.

11:56 UTC+2

D answers in email (replying to email at 11:49):

I’ve seen that page before. It’s not clear which form you were referring to. I don’t understand how to proceed. Please advise.

12:39 UTC+2

After C and D both contact G Suite support via Twitter account, get link to the account recovery form and fill the form (at https://support.google.com/a/contact/recovery_form ), a case is opened.

Case text is:

Subject: [urgent] (CENSORED-DOMAIN) – Whole G Suite domain does not function

We started getting “account deleted”
errors (started less than 24 hours ago) when trying to log in. Looks like
the whole G Suite domain was deleted. We suspect malicious activity. We did
not even consider deleting this domain. I am one of the administrators of
the domain – (CENSORED-EMAIL). Recovering the access and the data is critical
for our organization.”

The email says

Thanks for opening this G Suite support ticket. Your ticket number is (CENSORED-TICKET-NUMBER), and we’ll be in touch with you soon.

13:17 UTC+2

D checks what our clients see when they send us emails. Here is the reply they could get if sent something to one of our mail accounts:

The response was:
The email account that you tried to reach does not exist. Please try double-checking the recipient’s email address for typos or unnecessary spaces. Learn more at https://support.google.com/mail/?p=NoSuchUser (CENSORED-SOME-ID) – gsmtp

13:30 UTC+2

Email from G Suite support regarding the case:


Thank you for contacting G Suite Account Recovery team. I understand that you are having issue with your G Suite account associated to the domain CENSORED-DOMAIN and getting error that the account has been deleted. I would like to know if your G Suite account is associated to another G Suite account before? Please let me know by replying to this email. Thank you.


G Suite Account Recovery team

13:34 UTC+2

Our reply to the email above:

We are not sure. If yes, it was (CENSORED-OLD-DOMAIN) .

Since this is very urgent issue that is critical to our business, can we have a phone conversation with you?
I think it will be more productive.


15:46 UTC+2

D does following PM to @gsuite:

Hi. Sorry to bother you but it has been 2 hours since my last email to the support. The issue is very urgent to us. Can you check maybe what’s going on with case (CENSORED-TICKET-NUMBER)

16:08 UTC+2

@gsuite to D:

Hi there, the service level agreement for G Suite technical support is 24 hours. The team will reply within 24 hours from your response. I hope this helps. -MO

16:20 UTC+2

D to @gsuite:

Can we buy premium support to accelerate this? The impact of this issue on our business is huge.

This is unanswered at the time of publication.

22:50 UTC+2

Additional email to support:

It is disappointing that I was still not contacted, despite defining this issue as urgent. It’s evening, and I’m going to sleep soon. Since the issue is urgent, please call me ( CENSORED-PHONE-NUMBER ) because I will not see your emails till the morning; I’m at UTC+2.

22:59 UTC+2

Email from support (despite requesting phone communication):


Good day! I hope this message finds you well. My name is CENSORED-NAME and I am one of the supervisors for G Suite Account Recovery. I understand that you are getting an error that the domain has been deleted when you try to sign in with your email account for CENSORED-DOMAIN. I’ll be taking over now of this case.

Google sends notifications to the administrators, especially to the primary administrator, whenever there’s an update or changes that might affect their G Suite account. You mentioned that you are one of the administrators of the account which said was deleted. Have you coordinated with the other administrators and check if they receive any notifications from Google?

Also, when the previous agent asked you if there was any other domain affiliated with the account, you said that it might be CENSORED-OLD-DOMAIN. Do you still own that domain?

I would also like to ask if you remember signing up for G Suite, what was the domain you used?

If you have questions, feel free to reply to this email.


G Suite Account Recovery Team

23:06 UTC+2

Answered the email:

Thanks. It’s good when my emails are responded to.

They did not delete the account and they did not get any notifications. There were no plans to delete the G Suite domain.

We do not own CENSORED-OLD-DOMAIN anymore. Please note that we are not sure whether these were linked.

I’m not sure I understand the question. When I joined the company, G Suite was already in use. Our emails etc were on “CENSORED-DOMAIN” domain, which we still own.

2018-03-23 01:09 UTC+2

Email to support:

New information. C ( CENSORED-EMAILS ) did receive notification about pending removal of CENSORED-OLD-DOMAIN G Suite. He did not think it was related. Apparently it is.

Please recover our “CENSORED-DOMAIN” domain as soon as you can.

Going to sleep now, please use phone to contact me if you have any questions.


08:15 UTC+3

Email to support:

Hello. Any updates? I’m asking because several hours passed, I haven’t heard from you and our business is continuing to suffer greatly from this issue.


14:56 UTC+3

No reply yet. Publishing in hope to apply some pressure.

19:06 UTC+3

Email from support:

Hello D,

Good day! Thank you for your response.  I apologize if I let you felt that your case is being not attended. Don’t worry, I have your case under my watch. To set proper expectation regarding my availability, I am in the office every Mondays to Fridays,  5:00AM to 2:00PM PST. I do understand how critical this situation is and how it is affecting your business. I’ll do my best to address the issue you are experiencing.

You have mentioned that your co-admin has received a message from Google regarding pending deletion of the G Suite account associated with CENSORED-OLD-DOMAIN. It was addressed to CENSORED-EMAIL-OF-C, which I think is an admin since it has received the notification.

Based on your answers, if the email notification from Google was received and resulted to the deletion of the G Suite account where CENSORED-DOMAIN  is associated with, most probably the primary domain configured in your G Suite account was CENSORED-OLD-DOMAIN, which its domain ownership had been contested by the new owner for them to be able to sign up for G Suite.

In short, CENSORED-DOMAIN was also deleted because it was configured as secondary domain of the G Suite account registered for CENSORED-OLD-DOMAIN.

For your reference, you may read this Help Center article about the importance of disassociating expired domain name with your G Suite account:
What if my domain expires? – https://support.google.com/a/answer/6359803
Before you change your primary domain (When do I need to change my primary domain) – https://support.google.com/a/answer/6301932

I regret to inform you that this can no longer be recovered as it underwent through proper process. Google already sent a notification to the primary administrator of the account. What I can advise is to sign up for a new G Suite account registered with the domain that you really own, CENSORED-DOMAIN.

If you have questions, feel free to reply to this email.


G Suite Account Recovery Team

19:31 UTC+3

D replies:

The damage to our company due to losing the documents is huge. We estimate it at millions of dollars and CENSORED. Please check how to recover our documents. Escalate if needed. It’s completely unreasonable situation.

Around 20:00 UTC+3

C finds a copy of notification email. It is dated 2018-03-18. C did not even open it till now because the title says CENSORED-OLD-DOMAIN. Well, nothing in the email says anything about CENSORED-DOMAIN.

23:23 UTC+3

Publishing the update, no more emails till now.

2018-03-24 12:10 UTC +3

PM to @gsuite:

Here is how this support nightmare looks from our side: https://www.reddit.com/r/devops/comments/86kq2n/g_suite_support_24_hours_without_our_account_and/

2018-03-24 14:22 UTC+3

Still no reply to email and no reply from @gsuite

18:01 UTC+3

Got this reply. I was thinking that we might not hear from Google till Monday because this guy told us (in one of previous emails) he is working Monday till Friday and today is Saturday.


Thank you for your response. I understand that you’re getting confused why the CENSORED-DOMAIN got deleted when in fact, you only received a notification regarding the pending deletion of the G Suite account for CENSORED-OLD-DOMAIN. I’ll be addressing the confusion to clear things up.

G Suite knows the nature of business when it comes to domain name registrations. When a domain name registration expires, it may be sold again to a new user who wanted to sign up the domain with G Suite. Proof of domain ownership is necessary when we use the service.

A G Suite account is recognized for its primary domain. If the primary domain used for G Suite got expired, the administrator needs to switch it to a different domain that they still own. It is because if your primary domain is not updated, there is a chance that someone may buy the domain name and sign it up for G Suite. When that happens, error will occur because the domain they try to sign up (or add as secondary domain or domain alias) is existing in the system.

How I understand the situation, this is the same thing happened to CENSORED-OLD-DOMAIN, as you have mentioned that you no longer own the domain name. The new owner must have tried to sign it up for G Suite, but they are getting the error that it is already in use. So they have to contact G Suite to contest the domain ownership for them to be able to use it with G Suite.

G Suite sends an email notification to the administrator of the existing G Suite account in the system, that a user has proven their domain ownership and wanted to use the domain name for G Suite. In your case, CENSORED-OLD-DOMAIN was the primary domain of the G Suite account, and if it is the primary domain is being contested, the whole G Suite account will be deleted, including the secondary domain in it, which was in your case CENSORED-DOMAIN.

There are some questions as well that I want to ask:
1) if CENSORED-OLD-DOMAIN has long gone expired, why was the primary domain of the G Suite account was not updated and changed it to an active one?
2) There were 3 days for the admin to reply on the said email regarding the pending deletion, was there an attempt of replying to it or was just simply disregarded because it was treated irrelevant?
3) Is there really a different G Suite account for CENSORED-MISSPELED-DOMAIN? If so, then why it got deleted too when CENSORED-OLD-DOMAIN ownership got contested? It would not be deleted if it has a separate G Suite account where it is set as primary domain, right?

Please be advised that the information I have provided are based on my deductive reasoning of the answers you have provided to me and my technical expertise regarding this matter. I would also like to let you know that this case has already been escalated and I am the best person to speak with regarding this technical matter. Please also note that in accordance to our privacy policy, I am not allowed to disclose any relevant information from our end since you are contacting us through an unauthenticated channel.

If you have questions, feel free to respond to this email.


G Suite Account Recovery Team

My thoughts: If you understand why we are “getting confused”, maybe the system should be fixed?

21:09 UTC+3

Email to support:


1) if CENSORED-OLD-DOMAIN has long gone expired, why was the primary domain of the G Suite account was not updated and changed it to an active one?

CENSORED-OLD-DOMAIN-WITHOUT-DOT-COM is previous name of our business. We are slowly phasing out usage of CENSORED-OLD-DOMAIN in all places. We are busy startup so theses things take time.

2) There were 3 days for the admin to reply on the said email regarding the pending deletion, was there an attempt of replying to it or was just simply disregarded because it was treated irrelevant?

The significance of the said email was not understood. The subject had CENSORED-OLD-DOMAIN in it so it was treated like low priority issue to take a look in the future.

3) Is there really a different G Suite account for CENSORED-MISSPELED-DOMAIN? If so, then why it got deleted too when CENSORED-OLD-DOMAIN ownership got contested? It would not be deleted if it has a separate G Suite account where it is set as primary domain, right?

We think that there was not a separate account, CENSORED-OLD-DOMAIN-WITHOUT-DOT-COM is previous name of our business.

Please be advised that the information I have provided are based on my deductive reasoning of the answers you have provided to me and my technical expertise regarding this matter. I would also like to let you know that this case has already been escalated and I am the best person to speak with regarding this technical matter. Please also note that in accordance to our privacy policy, I am not allowed to disclose any relevant information from our end since you are contacting us through an unauthenticated channel.

We own the CENSORED-DOMAIN domain, which we want to recover. How you want us to authenticate? We can prove ownership of CENSORED-DOMAIN by setting a DNS record for example.

21:33 UTC+3

Email to support:

Most importantly, we would like to make sure that a technical team is working on recovering our data: emails and Drive. Every minute without our data is critical to our clients and workers, any help with that would be great.

We consider that situation where 3 days without replying to an email causes removal of all our accounts and data is totally unreasonable. Especially so when CENSORED-DOMAIN domain was in active use which could be seen from Google side and it was still deleted.

23:44 UTC+3

Got email to D’s email on the affected CENSORED-DOMAIN domain. D was able to get the email because we use different mail provider for the affected domain for now.

From: PlatformNotifications-noreply@google.com
Subject: Your Google Developers Console project is scheduled for deletion

Project Shutdown Announcement

Your Google Cloud Platform project CENSORED was shut down on Saturday, March 24, 2018 8:44:47 PM UTC.

If you take no action, after Monday, April 23, 2018 8:44:47 PM UTC, you will be unable to recover this project. If this was unintentional, visit this URL before Monday, April 23, 2018 8:44:47 PM UTC to cancel the project shutdown:


If you have any questions, please visit the Developers Console Help at this URL, or contact support:


The Google Developers Console Team

© 2016 Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043

You have received this mandatory email service announcement to update you about important changes to your Google Developers Console product or account.

D has no idea about this and suspects it might be a byproduct of Google working on recovery. C suspects Google are deleting something additional related to our domain.

The link works only for logged in users. Since none of us can log in, we can not use the link to take a look.


2018-03-27 13:34 UTC+3

Email to support:

Any news? It’s almost 3 days since we’ve heard from you … regarding urgent case.

2018-03-27 19:16 UTC+3


Good day! Thank you for your response. Sorry if my reply came too late as I just came back to the office.

I have read your answers from my previous questions and also your request for the G Suite account to be recovered. I’d really want to help out regarding this matter as I know how this is really impacting to your business. However, the best thing that we can do regarding this situation is to tell you the truth that it is no longer recoverable and provide education so that it will not happen again in the future.

Here are my responses to your answers:

1) “CENSORED-OLD-DOMAIN-WITHOUT-DOT-COM is previous name of our business. We are slowly phasing out usage of
CENSORED-OLD-DOMAIN in all places. We are busy startup so theses things take time.” – Thank you for letting me know about how CENSORED-OLD-DOMAIN-WITHOUT-DOT-COM is transitioning to a new business name. The opportunity I find here is that since the business is undergoing transition, the G Suite account should have adapted the changes in the organization too by changing the primary domain. To know more how to change your primary domain, you may check this Help Center article: https://support.google.com/a/answer/7009324

2) “The significance of the said email was not understood. The subject had
CENSORED-OLD-DOMAIN in it so it was treated like low priority issue to take a look in
the future.” – I really feel sorry if that email was not prioritized because of its subject containing a domain which you no longer own. However, it is always a best practice as an admin to keep the communication lines open and check notifications from G Suite as it may contain important, sensitive and private message that concerns your G Suite account.

3) “We think that there was not a separate account, CENSORED-OLD-DOMAIN-WITHOUT-DOT-COM is previous name of our
business.” – Thank you for letting us know that you are aware that both domains are configured in one G Suite account.

Based from your responses, I think the opportunity here is to understand the importance of these terminologies in G Suite:
1) Primary Domain – The domain name used in which the G Suite account is registered. The very foundation of a G Suite account.
2) Secondary Domain – A type of additional domain that shares from the storage of the primary domain’s G Suite account. Users may be provisioned under this domain and use it to log in.
3) Domain Alias – A type of additional domain that automatically adds email aliases to all users under the primary domain. Email addresses under domain alias can not be configured as login username.

It is really important to update the primary domain if the domain name enrolled in it has expired its registration. For your reference, you may visit this Help Center article regarding the importance of updating the primary domain if in case it expires: https://support.google.com/a/answer/6359803

The reason it is no longer recoverable is because the domain CENSORED-OLD-DOMAIN was set as primary domain of your G Suite account that was legitimately contested by the new owner for them to be able to add their new domain with G Suite. In which, it was also admitted by your end that CENSORED-OLD-DOMAIN is no longer owned by your organization. Also, I have also checked that the new owner has already enrolled the domain name to G Suite.

Thank you for your understanding.


G Suite Account Recovery Team

2018-03-27 20:54 UTC+3

Email from another person in support. Gives some hope.


Thank you for contacting G Suite Support. I understand the account CENSORED-DOMAIN. has been deleted. My name is CENSORED-NAME and I am in charge of your case.

I am aware that retrieving your domain is very important to you. I have contacted a specialist team regarding this issue. As soon as I hear from them, I will update this case and provide you with further notifications regarding the issue at that point. I would like to be honest with you and provide the right expectations, I can not promise to recover your domain but I will exhaust all the resources in my hands to do it.

The case will remain open. If you have any question please respond to this message and I will be very happy to follow up with you. I look forward to contacting you at the earliest convenience. I’ll be available Monday through Friday from 4:00 pm to 1:00 am IDT. Have a nice day!


G Suite Support

2018-03-28 02:33 UTC+3

Email from third support person:


This is a friendly follow up regarding the case you currently have on Google G Suite Support.

I hope this message finds you well. We thank you for patiently waiting for a resolution to your case. I just wanted to let you know that due to the nature of the issue we can’t guarantee that the data will be restored since it got all permanently deleted but, our engineering team is currently working to verify if we have an option to restore it. In the meantime, We would greatly appreciate if you don’t create a brand new account until we get a final resolution to your case.

Please don’t hesitate to reply back to this email if you have any additional questions. HAve yourself a wonderful day.

Best regards,

Google G Suite Support.

2018-03-28 06:14 UTC+3

Email from support:


This is a friendly follow up regarding the case you currently have on Google G Suite Support.

I hope this message finds you well. We thank you for patiently waiting for a resolution to your case. I just wanted to let you know that due to the nature of the issue we can’t guarantee that the data will be restored since it got all permanently deleted but, our engineering team is currently investigating. In the meantime, We would greatly appreciate if you don’t create a brand new account but verify domain ownership by adding the following CNAME:


Destination/Target: Google.com

Time to live (TTL): 3600

Please don’t hesitate to reply back to this email if you have any additional questions. Have yourself a wonderful day.


Best regards,

Google G Suite Support.

2018-03-28 11:12 UTC+3

Email to support:


CNAME added as requested.



2018-03-28 16:18 UTC+3

Email from support:


Thank you for your reply.

I apologize for contacting you until now but I am starting my shift. Your case is a priority for us and if I can not contact you, someone else will. I see that CENSORED-NAME-OF-SUPPORT-PERSON-3 asked you to create a CNAME record. We are still working on your case, I’ll keep you updated.

The case will remain open. If you have any question or additional comments in regards to your case, please feel free to reply to this email.


G Suite Support

2018-03-28 23:04 UTC+3

Automated email from Google:

30 days remaining to set up billing for G Suite Basic

Our records indicate that you have no payment information on file for G Suite Basic for CENSORED-DOMAIN. You have until April 27, 2018 to set up your billing information, after which you will be suspended. Please set up billing in order to continue uninterrupted service.

Here’s what you need to do to continue your subscription to G Suite:

Click the Set up billing button below.
Select payment plan.
Review your purchase and accept the terms of service.
Enter your payment information.
If you would like to pay by check or manual bank transfer every month, please contact G Suite support.

D logs in with his email at CENSORED-DOMAIN. Users appear to be there. D calls C. C fails to log in. In admin, C is a “deleted user”. The documents, at least most of them appear to be there, we are not sure, it’s late, we’ll look into this tomorrow. We also hope to get some official notification about recovery finish.

2018-03-29 06:55 UTC+3

Email from support:


I want to thank you for your ongoing patience while we have working to resolve your issue. My name is CENSORED-SUPPORT-PERSON-4, and I am the Technical Solutions Engineer (TSE) who will be taking ownership of your escalated case from CENSORED-SUPPORT-PERSON-2.

Over the past ~30 hours, I have been engaging with our Product Engineers to identify the safest (and quickest) way to recover the “@CENSORED-DOMAIN” users that previously existed on the G Suite account associated with “CENSORED-OLD-DOMAIN”. In most circumstances, it is easy for us to restore a deleted G Suite account. However, in your case—because you did not maintain ownership of the primary domain—another customer has set-up a new G Suite account with it.

Unfortunately, our systems cannot accommodate two G Suite accounts with the same primary domain, and we cannot evict the one that was recently created by the current owner of “CENSORED-OLD-DOMAIN”. If you were that individual, I am sure that you would not appreciate us deleting (or asking you to delete) the G Suite account that you just created.

Since “CENSORED-DOMAIN” cannot be restored independently of “CENSORED-OLD-DOMAIN”, we have created a new G Suite account (on your behalf), with “CENSORED-DOMAIN” set as the primary domain. In addition, we have begun the process of moving your deleted users to this new G Suite account—this is outside our normal processes, which is why it has taken longer than desired.

At this time, we have been able to restore the following users, and move them to the new G Suite account:


At this this time, the aforementioned users should be able to sign (via https://accounts.google.com/) and access their data. Additionally, as a Super Admin, you should also be able to access the Admin console (via https://admin.google.com/), where you can set-up your billing information, and manage these user accounts.

Please understand that were are doing all of this on a best-effort basis, and we cannot guarantee that user data has been (or can be) recovered. Currently, due to technical constraints, we are having difficulty moving “CENSORED@CENSORED-DOMAIN” and “CENSORED@CENSORED-DOMAIN” to the new G Suite account—however, we are continuing to work on this, and will let you know once we have determined whether or not these users can be recovered.

I also want to note that we cannot restore any Google Groups—however, I believe that you only had “CENSORED@CENSORED-DOMAIN” and “CENSORED@CENSORED-DOMAIN” on the former G Suite account. If these are necessary, you should be able to re-create them via the “Groups” page within your Admin console.

I will reach out to you around this time tomorrow with the latest information on our progress. From your cell number (+972 CENSORED), I understand that you are located in Israel. Since I am located in Mountain View, California, there is little overlap in our working hours—however, if you would like to speak with someone on phone, please let me know, and I will try to co-ordinate something with my European colleagues.



2018-03-29 14:53 UTC+3

Email to support:

We appreciate the technical efforts being put into solving the problem. Thanks!

Me and some other users were able to log in and see our emails and documents. I was able to log into admin. That’s great. C was not able to log in but I understand that you just haven’t finished with the account. C is listed under “deleted users” in admin.

I will gladly speak to you tomorrow, if my 7AM are OK for you. I do prefer to speak to the person who did the recovery and not more-time-zone-connvenient colleagues. CENSORED.


2018-03-29 18:00 UTC+3

Call from technical person that works on our case.

  1. They are still working on recovering the last account. It was slowed down by the fact that C opened consumer Google account with same email address (he needed to authenticate to an external service).
  2. The technical team got the case just about two days ago.
  3. Google will be improving the process
    1. Better notification that will mention the relevant domains.
    2. Better escalation. Apparently first line support (“agents”) were not sure what to do with our case because it was unusual so it took a while to escalate.
    3. Support will be instructed to use the mentioned communication channel
  4. There should be news in a few hours or maybe tomorrow morning (UTC+3 time)

2018-04-01 10:16 UTC+3

No further communications from Google. Admin shows that the last account was recovered. C checked the documents and they seem to be OK.

2018-04-06 18:42 UTC+3

We started to check possible backup solutions. We are also considering which other systems are critical to us and hence need to be backed up.

2018-04-09 21:55 UTC+3

Email from support:


My name is CENSORED-SUPPORT-PERSON-5, and I am one of the support managers in Google Cloud Support.
NAME-OF-SUPPORT-PERSON-4 will be out of office this week, so I wanted to follow up on the status of the issue.

Based on the case and issue history tracked by Engineering, we have addressed last issues associated with CENSORED-EMAIL and CENSORED-EMAIL on April 4th and thus all the issues should have been addresses. Please do let us know if that is not the case, and I will work with another engineer to look into it.

Thank you for your patience with this case.

Google Cloud Support

2018-04-10 15:59 UTC+3

Email to support:


We have noticed that the data was recovered. It was strange that we had to notice that by ourselves because we were not contacted after the last accounts were recovered.

Other than this additional item for your post-mortem (we are really curious what are the resulting action items), everything seems to be OK, thanks.


2018-04-10 18:04 UTC+3

Email from support:


Thank you for your message. I’m really happy to hear that you have been able to access the data for CENSORED-EMAIL and CENSORED-EMAIL.

During our last phone conversation, I had mentioned that our engineering team was encountering significant difficulty recovering these users. However, on April 4th (a little before midnight IDT), they confirmed that the necessary changes had been made to undelete them. I did not contact you at the time, as it can take 24-48 hours for all user data to be fully restored—especially for a user like CENSORED-EMAIL, who has used over 9 GB of data storage.

A notice about this “propagation delay” used to be mentioned in the Help Center at: https://support.google.com/a/answer/1397578, however it was recently removed for unknown reasons. I have confirmed with our technical writers that this notice has been reincluded in the current article draft, which is currently undergoing review.

I am glad to see that NAME-OF-SUPPORT-PERSON-5 contacted to you yesterday, since I was out of the office. As CENSORED mentioned, I will be out for most of this week—however, I did want to take some time to inform you of the progress being made on the “action items” (from the post-mortem) that we discussed over the phone. With regards to your concerns about how your case was handled by our tier-one team, I have relayed your feedback to each of their managers, and have asked that all of them receive additional training to ensure that they do not avoid making outbound calls and/or escalating cases when specifically asked by customers.

In addition, we are continuing to work on updating our email templates to ensure that all domains are listed—instead of just the one with contested ownership. We are currently working with our Product Counsel team on several proposed changes to our procedures/workflows, and this has been included amongst them.

Finally, I am happy to report that our engineering team did address the root cause of the technical issues that were preventing your two users from being restored. Should any of our customers ever end up in a similar situation, we should be able to initiate the restoration process a lot faster!

Because of all the trouble that you experienced, I have gone ahead an extended your “G Suite Business” trial to May 31, 2018 (the farthest back possible)—I hope that this will give you enough time to backup/export all of your user data, and to re-evaluate the product. If you encounter any further issues during this trial period, please do not hesitate to respond back to this email and let NAME-OF-SUPPORT-PERSON-5 or me know!


Google Cloud Support

2018-04-12 12:52 UTC+3

Email to support:

Thank you!

TODO: Schedule post-mortem


The missing link of Ops tools

It’s like we went from horse to spaceship, skipping everything in between.


Let’s say you are managing your system in AWS. Amazon provides you with API to do that. What are your options for consuming that API?

Option 1: CLI or library for API access

AWS CLI let’s us access the API from the command line and bash scripts. Python/Ruby/Node.js and other languages can access the API using appropriate libraries.

Option 2: Declarative tools

You declare how the system should look like, the tool figures out dependencies and performs any API calls that are needed to achieve the declared state.

Problem with using CLI or API libraries

Accessing API using CLI or libraries is fine for one off tasks. In many cases, automation is needed and we would like to prepare scripts. Ideally, these scripts would be idempotent (can be run multiple times, converging to the desired state and not ruining it). We then quickly discover how clunky these scripts are:

# Script "original"
if resource_a exists then
  if resource_a_property_p != desired_resource_a_property_p then
    set resource_a_property_p to desired_resource_a_property_p
  if resource_a_property_q != desired_resource_a_property_q then
  # resource_a does not exist
  create resource_a
  set resource_a_property_p to desired_resource_a_property_p
# more chunks like the above

It’s easy to see why you wouldn’t want to write and maintain a script such as above.

How the problem was solved

What happened next: jump to “Option 2”, declarative tools such as CloudFormation, Terraform, etc.


Other possible solution that never happened

If you have developed any code, you probably know what refactoring is: making the code more readable, deduplicate shared code, factoring out common patterns, etc… without changing the meaning of the code. The script above is an obvious candidate for refactoring, which would be improving “Option 1” (CLI or a library for API access) above, but that never happened.

All the ifs should have been moved to a library and the script could be transformed to something like this:

# Script "refactored"
create_or_update(resource_a, {
  property_p = desired_resource_a_property_p
  property_q = desired_resource_a_property_q
# more chunks like the above

One might say that the “refactored” script looks pretty much like input file of the declarative tools mentioned above. Yes, it does look similar; there is a huge difference though.

Declarative tools vs declarative primitives library

By “declarative primitives library” I mean a programming language library that provides idempotent functions to create/update/delete resources. In our cases these resource are VPCs, load balancers, security groups, instances, etc…

Differences of declarative tools vs declarative primitives library

  1. Declarative tools (at least some of them) do provide dependency resolution so they can sort out in which order the resources should be created/destroyed.
  2. Complexity. The complexity of mentioned tools can not be ignored; it’s much higher than one of  declarative primitives library. Complexity means bugs and higher maintenance costs. Complexity should be considered a negative factor when picking a tool.
  3. Some declarative tools track created resources so they can easily be destroyed, which is convenient. Note that on the other hand this brings more complexity to the tool as there must be yet another chunk of code to manage the state.
  4. Interacting with existing resources. Between awkward to impossible with declarative tools; easy with correctly built declarative primitives library. Example: delete all unused load balancers (unused means no attached instances): AWS::Elb().reject(X.Instances).delete()
  5. Control. Customizing behaviour of your script that uses declarative primitives library is straightforward. It’s possible but harder with declarative tools. Trivial if in a programming language can look like count = "${length(var.public_subnets) > 0 ? 1 : 0}" (approved Terraform VPC module).
  6. Ease of onboarding has declarative tools as a clear winner – you don’t have to program and don’t even need to know a programming language, but you can get stuck without knowing it:
  7. Getting stuck. If your declarative tool does not support a property or a resource that you need, you might need to learn a new programming language because the DSL used by your tool is not the programming language of the tool itself (Terraform, Puppet, Ansible). When using declarative primitives library on the other hand you can always either extend it when/if you wish (preferable) or make your own easy workaround.
  8. Having one central place where potentially all resources are described as text (Please! don’t call that code, format is not a code!). It should be easier done with declarative tools. In practice, I think it depends more on your processes and how you work.

As you can see, it’s not black and white, so I would expect both solutions be available so that we, Ops, could choose according to our use case and our skills.

My suggestion

I don’t only suggest to have something between a horse and a spaceship; I work on a car. As part of the Next Generation Shell (a shell and a programming language for ops tasks) I work on declarative primitives library. Right now it covers some parts of AWS. Please have a look. Ideally, join the project.

Next Generation Shell – https://github.com/ilyash/ngs


Do you agree that the jump between API and declarative tools was too big? Do you think that the middle ground, declarative primitives approach, would be useful in some cases? Comment here or on Reddit.

Have a nice day!

Why I have no favorite programming language

TL;DR – because for me there is no good programming language.

I’m doing mostly systems engineering tasks. I manage resources in Cloud and on Linux machines mostly. I can almost hear your neurons firing half a dozen names of programming languages. I do realize that they are used by many people for systems engineering tasks:

  • Go
  • Python
  • Ruby
  • Perl
  • bash

The purpose of this post is not to diminish the value of these languages; the purpose is to share why I don’t want to use any of the languages above when I write one of my systems-engineering-task scripts. My hope is that if my points resonate with you, the reader, you might want to help spread the word about or even help with my suggested solution described towards the end.


So let’s go over and see why I don’t pick one of the languages:

Why not language X?

All languages

  • Missing smart handling of exit codes of external processes. Example in bash: if test -f my_file (file is not there, exit code 1) vs if test --f my_file (syntax error, exit code 2). If you don’t spot the syntax error with your eyes, everything behaves as if the file does not exist.
  • Missing declarative primitives libraries (for Cloud resources and local resources such as files and users). Correction: maybe found one, in Perl – (R)?ex ; unfortunately it’s not clear from the documentation how close it is to my ideas.

All languages except bash

  • Inconvenient/verbose work with files and processes. Yes, there are libraries for that but there is no syntax for that, which would be much more convenient. Never seen something that could compare to my_process > my_file or echo my_flag > my_file .


  • Compiled
  • Error handling is a must. When I write a small script, it’s more important for me for it to be concise than to handle all possible failures; in many cases I prefer an exception over twice-the-size script. I do understand how mandatory and explicit error handling can be a good thing for larger programs or programs with greater stability requirements.
  • Dependencies problem seem to be unresolved issue


  • Functional programming is second level citizen. In particular list/dictionary comprehension is the Pythonic way while I prefer map and filter. Yes, that’s probably one of the features that makes Python easier to learn and suggested first language. Not everything that’s optimized for beginners must be good for more experienced users. It’s OK.
  • Mixed feelings about array[slice:syntax] . It’s helpful but slice:syntax is only applicable inside [ ] , in other places you must use slice(...) function to create the same slice object

Ruby and Perl

  • The Sigils syntax does not resonate with me.


I can’t put my finger on something specific but Ruby does not feel right for me.


  • Contexts and automatic flattening of lists in some cases make the language more complicated than it should.
  • Object orientation is an afterthought.
  • Functions that return success status. I prefer exceptions. Not the default behaviour in Perl but an afterthought: autodie.
  • Overall syntax feeling (strictly matter of personal taste).


Note that bash was created in a world that was vastly different from the world today: different needs, tasks, languages to take inspiration from.

  • Missing data structures (flat arrays and hashes is not nearly enough). jq is a workaround, not a solution in my eyes.
  • Awkward error handling with default of ignoring the errors completely (proved to be bad idea)
  • Expansion of undefined variable to empty string (proved to be bad idea)
  • -e ,  -u and other action at a distance options.
  • Unchecked facts but my feelings:
    • When bash was created, it was not assumed that bash will be used for any complex scripting.
    • bash was never “designed” as a language, started with simple commands execution and other features were just bolted on as time goes by while complete redesign and rewrite were off the table, presumably for compatibility.
  • Syntax
  • No widely used libraries (except few for init scripts) and no central code repository to search for modules (Correct me if I’m wrong here. I haven’t heard of these).

My suggested solution

I would like to fill the gap. We have systems-engineering-tasks oriented language: bash. We have quite a few modern programming languages. What we don’t have is a language that is both modern and systems-engineering-tasks oriented. That’s exactly what I’m working on: Next Generation Shell. NGS is a fully fledged programming language with domain specific syntax and features. NGS tries to avoid the issues listed above.

Expected questions and my answers

People work with existing languages and tools. Why do you need something else?

  • I assume I have lower bullshit tolerance than many others. Some people might consider it to be normal to build more and more workarounds (especially around anemic DSLs) where I say “fuck this tool, I would already finish the task without it (preferably using appropriate scripting language)”. I don’t blame other people for understandable desire to work with “standard” tools. I think it’s not worth it when the solutions become too convoluted.
  • I am technically able to write a new programming language that solves my problems better than other languages.

Another programming language? Really? We have plenty already.

  • I would like to remind you that most of the programming languages were born out of dissatisfaction with existing ones.
  • Do you assume that we are at global maximum regarding the languages that we have and no better language can be made?


Would you use NGS? Which features it must have? What’s the best way to ease the adoption? Please comment here, on Reddit (/r/bash , /r/ProgrammingLanguages) or on Hacker News.

Update: following feedback roughly of the form “Yes, I get that but many Ops tasks are done using configuration management tools and tools like CloudFormation and Terraform. How NGS compares to these tools” – there will be a blog post comparing NGS to the mentioned tools. Stay tuned!

Have a nice day!