Dhall: A Non-Repetitive Alternative to YAML - <AUTHOR> https://dhall-lang.org/ <comment><USER3> Dhall is an awesome tool to have in your DevOps tool belt - we're heavy dhall users at meshcloud [0] and couldn't be happier about it. We picked it after evaluating a long list of contenders (yaml madness with anchors, jsonnet, ksonnet, j2/jinja, a hacked ejs compiler [1] and some more I forgot). It's so good we're looking into how we can give back/donate to the project.

Dhall elegantly solves a major challenge: configuration management at scale. We build a multi-cloud management platform, which serves DevOps teams, IT Governance, Controlling and IT Management in large enterprises. That means we're an integration solution for a lot of things, so we need to be highly configurable. Because we also manage private clouds (a la OpenStack, Cloud Foundry, OpenShift etc.), we often run on-premises and operate our software as a managed service. Using dhall allows us to _compile and type check_ all our configuration for all our customers before rolling things out. We use dhall to compile everything from terraform/ansible, kubernetes templates, spring config, to concourse ci pipelines and customer-specific reference data to load into our product. Since adopting dhall earlier this year, we measurably reduced our deployment defect rate and re-gained the ability to safely refactor configuration.

It takes a little time to get used to, but we appreciate that it's highly opinionated around formatting and "how to do things" \- somewhat in the same way as golang is. It has certainly helped that we had a member with haskell experience on the team, as dhall is built in haskell and the syntax feels familiar.

Plug: if you're looking for a job working with dhall, reach out :-)

\- 0: [https://meshcloud.io](https://meshcloud.io) \- 1: [https://github.com/Meshcloud/ejs-compiler](https://github.com/Meshcloud/ejs- compiler)

<comment><USER4> Heads up - Your naked subdomain redirect to www doesn't seem to be working. If I go to www directly, I don't get the timeout.

<comment><USER3> thanks! turns out it wasn't working for https, should be fixed now.

<comment><USER4> working for me now as well

</comment></comment></comment></comment><comment><USER5> I'm trying to use it for Kubernetes since it can both work like helm (paramerizing functions) and kustomize (using the merge // operator). Moreover it has (safe) imports which make defining constants quite easy.

There are already kubernetes bindings available [https://github.com/dhall- lang/dhall-kubernetes](https://github.com/dhall-lang/dhall-kubernetes) .

The syntax in the examples looks a bit more verbose and less readable than yaml but I think building sensible abstractions on top of it will alleviate the pain (abstractions here are innocuous since you can 'normalize' the code and they disappear)

I'm not too happy with the default formatting though. I think if the formatter indented nested values similar to yaml that would look better to the human eye.

<comment><USER6> > Moreover it has (safe) imports which make defining constants quite easy.

I read about dhall's imports, and I don't think I like it. If I add a text configuration mechanism to software, I do not want it accessing the network by default, full stop. To me, a "safe" configuration language means that parsing terminates, does not have side effects, does not touch the network, and that parsing the same file twice gives the same output unless I _explicitly_ change an input. Pulling a prelude off of github does misses several of these requirements.

(Having your config file fail to parse if your network is down is bad, bad news if that config is needed to bring your network up. It's also bad news if a parsing failure due to a transient network issue leaves your system in a state where it won't quickly recover if the network comes back.)

<comment><USER7> You can still do that, though. In Dhall you may import things remotely as you develop and then tell Dhall to pre-fetch the result, you can commit that and it will not access anything.

You may also just download any imports yourself and source them locally.

Additionally Dhall supports import fallbacks, for example you may try first a remote import, and if it fails it will look for another place, which I've could be remote or local. This is a good strategy for developing locally and then committing imports for production use.

You can also, of course, host the files in your local network.

</comment></comment></comment><comment><USER8> Thread from 2018: [https://news.ycombinator.com/item?id=17523623](https://news.ycombinator.com/item?id=17523623)

2017: [https://news.ycombinator.com/item?id=15185015](https://news.ycombinator.com/item?id=15185015)

2016: [https://news.ycombinator.com/item?id=13109672](https://news.ycombinator.com/item?id=13109672)

</comment><comment><USER9> This isn't an alternative to yaml. It's a yaml generator. To me it's not competing with yaml it's competing with python or Haskell, and i'd argue that putting yet another language in your stack just for generating config files is added unneeded complexity. And sure while both python and Haskell are Turing complete, how often do we actually run into issues when generations flat config files? I mean I've never had that issue, and I've never caught myself thinking "if only there was a nice way to limit myself to a non Turing complete subset of python/Haskell"...

<comment><USER10> That's kind of like saying C isn't an alternative to assembly, it's an assembly generator.

<comment><USER11> On a practical level, C is an alternative to assembly because the appropriate black-box tools and combinations of tools allow the user to easily turn source code in either Language or a combination of both into an executable.

Generating assembly from C is an implementation detail, and many C compilers don't do that.

On the other hand, Dhall really is a YAML generator: the available tools allow only one-way conversion (in particular, there is no interpreter/library to ingest Dhall from the configured application itself).

<comment><USER10> Dhall is also a JSON generator. And you could write your own Dhall implementation that lets you consume it directly from an application if you want to, it's just nobody's considered that worth doing.

<comment><USER9> Which is odd because tons of applications in the wild already have this amazing capability of directly consuming python and Haskell without first converting to yaml. But of cause you still have the ability to both produce and consume yaml if that's needed for some reason.

<comment><USER10> What applications directly consume Haskell code? The only examples I can think of off the top of my head are apps written in Haskell that actually get recompiled any time you change the "configuration" Haskell code.

As for Python, that's because the Python interpreter can be embedded in an app.

That said, Dhall is exposed as a Haskell library, so if you're writing a Haskell app you could consume Dhall directly and skip the YAML. [https://hackage.haskell.org/package/dhall-1.24.0/docs/Dhall-...](https://hackage.haskell.org/package/dhall-1.24.0/docs/Dhall- Tutorial.html) shows examples of this.

</comment></comment></comment></comment></comment></comment><comment><USER12> If you have functions that can call functions, you'd better not have recursion if you want to not be Turing-complete.

Non-Turing-completeness is certainly very important in many cases (e.g., in DTrace and eBPF), but I'm not sure that it's so important for _configuration_. Assuming for a moment that I don't need non-Turing-completeness for configuration, my choice of DSL would be jq[0]! Using jq for configuration means that I can use JSON, TOML-style, and other ways of expressing complex data, including combinations of them, all with "interpolation" (not quite) and complex computation being available.

      [0] https://stedolan.github.io/jq/

<comment><USER13> One valuable point of Dhall is that it is _programmable_ (yet not TC) in such a way to that you can e.g. describe a _whole system_ entirely in Dhall and then (in Dhall!) derive whatever further configurations (plural!) you need from that. This is much more feasible than in e.g. YAML because Dhall is strongly typed.

So you could describe e.g. a cluster of machines entirely in Dhall and derive Ansible YAML scripts (with all their boilerplate), derive DNS config files, etc. etc. all from a single strongly typed description.

<comment><USER12> I mean, jq is a powerful programming language. Did you look at the link I posted?

<comment><USER13> Sure, I'm familiar with it. It's nothing compared to what Dhall can do.

... unless of course it's grown to a similar point. As of about a year ago, for some complex transformations I had to stitch together multiple invocations of jq using pipes, etc. etc. That may have been my inexperience with using it, though.

Regardless, the point about typing stands. Dhall uses structural typing/subtyping which turns out to be hugely useful for config transformation.

<comment><USER12> I never have to "stitch together multiple invocations of jq using pipes". There was a time when I did have to, but that was years ago, and it now has the features needed to avoid that. Not sure what the point about typing was -- you can do the same derivation of data from a master entity with or without strong typing (though my preference is always for strong typing, which jq lacks).

<comment><USER13> > you can do the same derivation of data from a master entity with or without > strong typing (though my preference is always for strong typing, which jq > lacks).

Yes, of course you can. The point is that the strong typing helps prevent inadvertent and hard-to-spot mistakes. In jq even simple typos of a field name can lead to "empty result set" silent failures instead of "what do you mean!" loud failures. That's a big thing.

<comment><USER12> Strong typing generally doesn't speak to "how many values this expression should produce", only their types. Not saying it couldn't, but that even in Haskell you don't quite get that.

<comment><USER13> I was talking about a mismatched field name. What case are you talking about?

EDIT: Actually, responding to

> Strong typing generally doesn't speak to "how many values this expression > should produce"

Have you heard of affine/linear types?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Dhall keeps popping up on HN. Here what I don't like about it:

\- Why use '=' instead of ':' for attributes? If you used ':', then '=' could be variable assignment and eliminate the need for 'let'.

\- Why is there a need for commas?

\- Why quote via ticks?! Gee!

\- What's with the '{-' and '-}' for comments?! It's like its author decided to differ _at any price_!

In general, good ideas, but it's too weird and unnecessarily deviates from common syntax.

<comment><USER15> Dhall heavily borrows both ideas and syntax from the ML family of languages. E.g. Haskell, OCaml, Elm, Purescript

Colons are used for type signatures.

Commas are presumably required because you can have multi line and nested records. (don't quote me on this, not a parser expert)

The comment syntax is from Haskell.

Not saying this syntax is familiar to _everyone_ , but it is familiar to some. The lineage of the syntax might help you understand where the language is coming from

<comment><USER16> Weird that it's billed as an alternative to YAML, but effectively has zero roots or influence from YAML. Looks more like an alternative to... whatever configuration language is popular in ML language projects?

<comment><USER17> So? They live in the same solution domain for the same problem. Moreover, Dhall can generate (typechecked) YAML and JSON.

<comment><USER16> It's not even in the same solution space. I can't replace my YAML with Dhall and consume it directly. I have to now depend on the converter to go from Dhall -> YAML/JSON. All I did was add another layer of complexity into my config.

Maybe you'll benefit from the added abstraction; I see the value in having "typed" configs that are semi-scriptable but not turing complete. But it's in no way a "replacement".

<comment><USER18> > All I did was add another layer of complexity

If that was in fact all you had done, it would not be worth it. But it might remove a ton of boilerplate from your YAML.

<comment><USER19> or, one can eliminate boilerplate in code so that configuration stays simple and the logic in the application

I mean what's the role of configuration? is so that installer can tune or match environments. if configuration becomes as hard as your program to understand then installation won't ever scale

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> Couple of contenders:

\- Jsonnet ([https://jsonnet.org/](https://jsonnet.org/)) - simpler syntax and less concepts to learn, just an extension of JSON. But no type checking. An open source offspring of Google's internal config language (GCL/BCL)

\- Cue ([https://github.com/cuelang/cue](https://github.com/cuelang/cue)) - <USER2> more ambitious attempt to fix GCL/BCL by replacing inheritance as the fundamental compositional primitive with constraint unification.

Great thread comparing them against each other by the authors of both: [https://github.com/cuelang/cue/issues/33](https://github.com/cuelang/cue/issues/33)

Cue seems kind of similar to Dhall on first sight, but I haven't used either enough for an informed opinion yet.

<comment><USER21> We tried to introduce Jsonnet at our org. It failed miserably because ops kept mistaking the name for JSON which they hated. (International multilingual team).

It was a real shame because ops then implemented some features of Jsonnet via scripts to to parse and merge YAML. What was 0 LOC in Jsonnet is now about 300 LOC plus custom CI checkers, all because of a marketing problem.

<comment><USER22> If I go to the mentioned Jsonnet homepage it says "A simple extension of JSON". The graphic explains its relation to JSON. The example looks awfully similar to JSON.

What I don't understand is the following: config files are read by text editors, and in the end, by human beings. Because of the latter they should have certain traits. We must agree on the importance of these traits before we can settle on a standard.

For me, important features are that they must be readable, and easily editable. They must be readable with a certain text editor (vi) for backwards compatibility. So that means it shouldn't require syntax highlighting or schema. Well, these 2 simple requirements of mine rule out anything remotely resembling JSON.

It just appears to me that JSON is for JavaScript developers, YAML for Python developers, and Dhall for ML (the whole family I suppose, not just Haskell) developers.

Well then if we're going that route then perhaps all we need is some kind of glue between text config and binary config (which reminds me of Systemd...). Ie. that it accepts multiple config file formats.

<comment><USER23> I'm a little confused by one part of what you wrote. You say that your config files must be readable by vi, and that in turn adds a no-highlighting-required constraint and a no-schema-required constraint, and that in turn adds a no- JSON-nor-anything-like-it constraint.

I deal with JSON all the time in vim, effortlessly. I'd be willing to deal with it in Notepad if necessary, and certainly in non-vim vi. Pipe it through a prettifier (lately I use `jq . file.json`) if necessary.

I don't need syntax highlighting, and I don't need a formalized schema (although I certainly appreciate an informal one, interpreted by the 1.0 Human Meatbrain I carry around). Also, if by "vi" you meant "vim", this is EVEN MORE confusing, because vim syntax-highlights JSON.

<comment><USER22> With vi I mean vi, not vim. If I meant vim, I'd have written vim. I use vim if its available (with my own configuration which includes syntax highlighting), but it isn't always available.

With my Human Meatbrain syntax highlighter I have far more issues with JSON than with say YAML or any other markup language.

Consider, for example, how easy the syntax is of a Wireguard configuration file. It is basically akin to a shell script or ini configuration file. And these have a proven track record. Why is that way of configuration broken in the first place? You could do things such as variables in shell scripts as well.

I also believe that the whole Systemd drama is basically because of moving away from such a proven track record. And it might very well be true that shell scripts are slow. That is why I argue for backwards compatibility and converting to/from formats. Which is something Dhall is able to (it can convert to/from YAML and JSON).

</comment></comment></comment></comment></comment><comment><USER24> Immediate response?

I hate commas at the start of lines and I would prefer not to have curly braces in a human editable/readable format.

Neither reason is terribly rational but my first impressions weren't great.

<comment><USER25> It looks that Dhall has been inspired of the Elm language [0] and it's formatter.

[0]: [https://guide.elm-lang.org/](https://guide.elm-lang.org/)

<comment><USER26> It's a common practice in the Haskell community. Knowing where the creator of dhall comes from I would say that that's the source of inspiration

<comment><USER27> Author here: the syntax is inspired by all three of Haskell/PureScript/Elm

</comment></comment></comment></comment><comment><USER28> So far, only comments complaining about syntax. You can do better, HN!

<comment><USER14> Yeah, because that's what most configuration languages differ in.

<comment><USER29> And yet, in focusing on the syntax, you missed the biggest difference between Dhall and other configuration languages: safe, termination-guaranteed non- Turing-complete computation.

<comment><USER14> How is it better than Jsonnet or Starlark?

<comment><USER30> static type system

<comment><USER14> True. But isn't this also accomplished when pairing JSON with JSON Schema?

<comment><USER7> The schema applies to the generated values, but what's the equivalent of a schema for a programming language? Types.

Jsonnet does not have a way to validate its functions without running them first.

<comment><USER14> I clearly get that, but many IDEs use the schema to help you produce valid JSON.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> For a pragmatic, _really_ readable configuration file format, TOML never disappointed me ( [https://github.com/toml-lang/toml#user-content-local- date](https://github.com/toml-lang/toml#user-content-local-date) ).

\- This is human readable contrary to the JSON family and its {} abuses.

\- It is not space / ident base contrary to YAML that becomes very quickly a mess to write and a mess to parse.

<comment><USER14> TOML is _almost_ perfect. The only things I don't like are the need for commas and the double brackets.

<comment><USER32> Perfection is a bugaboo. Give me 95%, minor inconveniences, and declare vict'ry, say I.

</comment></comment></comment><comment><USER33> Still much prefer HJSON ([http://hjson.org/](http://hjson.org/)) for stuff that people might need to touch.

If it's truly for end-users (read: non-admin/dev types), you probably shouldn't have them touching configuration files _at all_.

<comment><USER28> How is this at all related to Dhall? It looks like a completely different thing with a completely different purpose.

<comment><USER33> They are both text based configuration file formats made to be easier for humans to interact with, so I'm not sure what you're confused about?

<comment><USER28> That's about the least interesting thing about Dhall. (It's weird that they tout it prominently on the homepage.) There are so many flavors of syntax sugar for JSON, Dhall is a completely different beast.

<comment><USER34> You might want to ask the HN admins to rename the title for this post, then.

<comment><USER28> It looks fine to me. Reducing repetition is precisely the type of thing Dhall's features should be useful for.

</comment></comment></comment></comment></comment></comment><comment><USER35> My comment isn't specifically about Dhall, but about the note on Turing completeness. I often read comments about how YAML/JSON is not turning complete. These comments normally frame the lack of Turing completeness as being a short coming of the format(s). I find this interesting because one the reasons that the industry moved away from XML was to have cleaner separation between data and logic. I generally tend to think that it is cleaner to separate logic and data, instead of creating a tight coupling. I don't read many people making comments from this perspective though. I am not trying to say we can't do better then YAML/JSON, I am just trying to offer some food for thought. I tend to view JSON/YAML as a data exchange format, and not a programming language, so I am not bothered by the lack of Turing completeness.

<comment><USER36> Not being Turing-complete is a feature.

A Turing-complete language allows to write programs that never terminate. This is not what a config file should be capable of.

<comment><USER21> Previously in my career I've abused Jinja templating to build "scripts" out of Ansible and SaltStack YAML. It solved business problems effectively but I'm sure when I left that role I passed on a big plate of spaghetti to my successor with minimal automated tests.

If it depends on conditional logic or iteration, it probably belongs in a proper programming language with a linter, type checkers, debugger and unit test framework.

<comment><USER37> This is one of the reasons why, coming from a background of writing Chef and writing exhaustive testing around my configuration management, I've never been able to deal with Ansible without grinding my teeth. Or, for that matter, Terraform; HCL is godawful and trying to write it in JSON is a sucker's bet, too. With the move towards more containerized systems I don't write Chef much anymore (thankfully), but Terraform has become ever more of a boil on my rear end. Fortunately there's also Pulumi now and writing this stuff in TypeScript is a lot faster and feels really good.

<comment><USER35> The thing is, although Ansible is not perfect, it is python. When you are writing playbooks you should be defining the state of the world, if you are writing custom logic it is probably best to write a custom module, which are commonly unit tested. I haven't tried Pulumi yet, thanks for pointing it out.

<comment><USER38> I'm not quite ready yet (esp. documentation is lacking), but I'm working on something to get the best of both worlds: [https://freckles.io](https://freckles.io)

Basically, you write your state-defining code in Ansible, using either modules, tasklists, roles, or a combination thereof. 'freckles' lets you wrap those up in re-usable, distinct, atomic units which you can combine for more complex tasks. Then you can use those directly via the command-line, or you can auto-generate (wrapper) Python (will do other languages later) classes from them (e.g. [https://freckles.io/doc/interfaces/python#code](https://freckles.io/doc/interfaces/python#code) ), for when there is more 'logic' to be implemented.

I reckon it's a bit like Pulumi, but it is less opinionated. Actually, it's probably more like it lets you create your own little domain-specific Pulumi, if that makes any sense. It also works really well as a wrapper for Packer and Terraform.

As I said, documentation is not quite there yet, but most of the important stuff works. Starting to look for people to try it out, if anybody on here is interested.

<comment><USER37> First off: congratulations on shipping something! Shipping is hard.

But this misses the mark. With respect, and I'm trying to not not dunking on your project, to me Ansible is the worst of every world and is emblematic of configuration management retreating from the realm of "infrastructure as code" to "infrastructure as magic notepad files because incurious sysadmins won't _write_ code.". I don't really care that Ansible is being wrapped so long as, inevitably, I'm going to have to go deal with that when it breaks. Eventually Pulumi/Terraform will break too, and there is no _programming_ language I have more eyerolls for than Golang, but at least it's a programming language, you know? (And I really don't relish the thought of ping-ponging from the Python wrapper to YAML hell to a Python module, tbh.)

The biggest thing that a project like Freckles fails to capture, and where Pulumi shines, is that _it 's all code and you just treat it as code_. They're compiler wonks, or at least the guy I know there is one, and they leverage that--when dealing with stuff like Lambdas/GCP Cloud Functions, you just write them inline and they're hoisted into deployable packages without comment or incident. There's no zipping of files, there's no messing around--you wrote a function to do a thing and it gets run. Done-and-done.

It's got a lot of other nice features, but that it is transparently code, and that they're investing most of their effort (it seems) into hiding the unfortunate fact that eventually some Terraform providers get run, makes Pulumi a really hard one to top.

<comment><USER38> Fair enough, I can see some of your points, but (obviously) I don't think they are entirely relevant, and my experience and view of Ansible is a different one.

Also, Ansible is only one backend for freckles, it's just the first one I implemented because of all the roles and modules already available for it. There will be a Terraform backend, and a Packer one, and a Kubernetes one too, probably. And I'm actually much more excited about the shell backend I have in mind, but that is much more work to create a repository of tasks for. You'll be able to just select one of those backends, or combine all of them.

The goal is for 'end-users' never having to deal with underlying backends and Ansible code and the like, if they don't want to. Those are just there to provide the building blocks end users would use to compose their provisioning/orchestration -- which they can do entirely in code. I hope to have a stable 'stdlib' of such tasks at some point, comparable to what is available in Pulumi, which people can just use without any other concern.

I don't know how Pulumi works under the hood, are you saying they basically wrap Terraform modules? If that's the case, that's not that different to how freckles works. With the exception that freckles can also be used for non- cloud things.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER39> Dhall is fantastic and I try to encourage everyone in tech I meet try it.

<comment><USER40> OK, _why_?

<comment><USER39> Because it is a good mix of features, syntax, execution speed and correctness.

Of course. Didn't you read the article?

<comment><USER40> I did, and it's bad form to suggest otherwise.

I was asking about your personal opinion, since you said it was great but didn't give any info as to _why_.

<comment><USER39> > I did, and it's bad form to suggest otherwise.

If you say so. But... I said I think the features are good and you ask "why?"

I could relist the features, but that's a waste of time. As I said, I think the combination is a good combination. In a world where people try to encode loops in YAML or JSON, even small improvements are better and Dhall is a large improvement.

> I was asking about your personal opinion, since you said it was great but > didn't give any info as to why.

I don't really get what you're asking. I said I think the combination of features is good. I don't need to describe the features. The reason I like them is probably related to neurochemistry?

Are you asking for a deep dive on how Dhall compares to alternatives?

<comment><USER40> Then I apologise; because you posted I assumed you were happy to or wanted to engage in discourse, maybe highlight your favourite features, possibly debate the value it bring, that kind of thing, but I see my mistake now.

</comment></comment></comment></comment></comment></comment><comment><USER41> Hmm...

So the authors claim that their language is guaranteed to terminate for all well-typed programs. That is actually a nice spot for configuration languages. Yet, I wonder how

a) they guarantee it, as I have seen no obvious link to the language's semantics

b) useful this is in practice.

Nevertheless, very nice approach, indeed.

<comment><USER42> Build systems tend to get very complex Turing complete scripts, such as gradle for Java or Make for C. Having something almost as powerful but reducible to a normal form is very helpful for CASE tools.

<comment><USER43> Banning Turing completeness doesn't give you the property you want, though. Knowing that reducing to a normal form eventually terminates if you wait a million years may be something mathematicians care about, but isn't of practical use.

What matters is that you can analyze the code quickly. To find that out, one way is to try it and kill the process if it takes too long.

Or perhaps better would be to come up with a portable definition of what "takes too long" means that you can put in a presubmit check. Something like "running out of gas" in Ethereum.

</comment></comment></comment><comment><USER44> Rust bindings tracking issue

[https://github.com/Nadrieril/dhall- rust/issues/77](https://github.com/Nadrieril/dhall-rust/issues/77)

</comment><comment><USER45> I'm sure people will be happy to crucify me for throwing this out there but I don't see a big risk in just using JavaScript in most cases if you want something like that. You could use template literals to replicate the example.

</comment><comment><USER46> How far does "non turing completeness" really get you in this context? It looks easy to write a program in this language that will take longer than the age of the universe to evaluate and whose result can't be represented explicitly without collapsing the galaxy into a black hole. How much comfort can you take in the fact that you know it doesn't diverge?

<comment><USER30> How would you write such a program?

<comment><USER47>
        let replicate = http://prelude.dhall-lang.org/List/replicate
        in replicate 999999999999 Natural 1

(add additional nines if necessary)

</comment></comment></comment><comment><USER48> I love this!

How small is a static binary to run this in my containers?

How are some ways to integrate the typed config in a language?

<comment><USER27> The static binaries for the various interpreters and conversion utilities (i.e. `dhall`/`dhall-to-yaml`/`yaml-to-dhall`) are all roughly 10 MB each

The following languages natively bind to Dhall:

* Haskell * Clojure * Ruby

... and the following language bindings are in progress:

* Rust * Go * Python * PureScript

In the absence of a native language binding, you can convert Dhall to YAML or JSON and read that in.

</comment></comment><comment><USER49>
       let input =
          { relative = "daughter"
          , movies   = [ "Boss Baby", "Frozen", "Moana" ]
          }

We don't frequent the same kind of "non-technical users" I guess.

</comment><comment><USER50> I thought the typo in the challenge was that the keys were in the root of the user's home directory, instead of the `.ssh` directory. So, I added `.ssh/` between the key and user home directory.

</comment><comment><USER44> This looks very useful.

<comment><USER44> looking further, it seems that aside from repetitiveness, safety is the main focus:

[https://github.com/dhall-lang/dhall-lang/wiki/Safety- guarant...](https://github.com/dhall-lang/dhall-lang/wiki/Safety- guarantees#types)

which in Rust, we're solving this via SANE and SCL:

[https://gitlab.com/bloom42/sane-rs](https://gitlab.com/bloom42/sane-rs)

[https://github.com/keats/scl](https://github.com/keats/scl)

I'm not sure how much need there is for an additional programming layer, especially within config (the part of a program with the simplest syntactic requirements).

for my projects where "ahead-of-time validation" is needed, we're currently using SCL's parser for safety guarantees:

[https://github.com/foundpatterns/contentdb](https://github.com/foundpatterns/contentdb)

[https://github.com/foundpatterns/lighttouch/blob/d7ada4576a6...](https://github.com/foundpatterns/lighttouch/blob/d7ada4576a6f8865a625f6ffa18452ec90353db5/loaders/models.lua)

[https://github.com/foundpatterns/torchbear/blob/4dd2b9ea76ba...](https://github.com/foundpatterns/torchbear/blob/4dd2b9ea76ba0911d586ec5a0276f53053bd9738/src/bindings/text/scl.rs)

<comment><AUTHOR> From a cursory look to SANE and SCL it looks like Dhall still offers some more:

\- functions

\- a powerful typesystem

\- remote (HTTP) imports with sha256 checksums

</comment></comment></comment><comment><USER51> Programmable configuration is always and without exception a monumentally stupid idea.

Programmatic _generation of static configuration files_ can be very useful.

Sufficiently complex examples of the latter might as well be the former as far as maintenance is concerned.

If you need to write a program to configure your program, you're probably doing it wrong.

<comment><USER36> Configs allow to add flexibility past compile time, often dynamically at runtime.

<comment><USER51> Yes, that's the problem. I'd like to be able to look at a config file, on disk, loaded at startup, which defines the initial state of the server without having to think through how it was evaluated.

Generating the config during deployment, eh... often necessary. Best done with transforms and templates because they're simple.

Executable config, run during startup or, worse, on each request? NO.

[edit] I think that's the main disconnect here: 'past compile time'. The whole point of testing, strong type systems, etc is to lock down the set of states the system can be in. If your configuration is so 'dynamic' you are essentially abandoning all those benefits and saying 'yeah, do what you like to our live servers'.

In short, configuration which is that powerful is indistinguishable from running untested code in production.

<comment><USER7> Dhall give you exactly that, since you can store the normalised version of any configuration. Or inspect it at will by running it.

<comment><USER51> Yes, I'm not criticising Dhall so much as the behaviours it permits. IMO it should be _difficult_ to 'program' the generation of a config file, because the application should be designed such that that degree of flexibility is not required at the level of configuration.

We've done things with generated config before. Looked necessary. We took a few steps back and realised that it was never necessary, only permitted, so it got fudged in deployment instead of being fixed in application design.

<comment><USER36> If you operated services that should run at scale, or 24/7, or both, you must have noticed that the ability to fix an urgent issue (which may be totally not a fault of the deployed code) by changing just configs is valuable.

<comment><USER51> Of the failure modes I've had to deal with, even when we did use a lot of interpreted scripts which could be live-patched, very few of the important issues were fixable that way. Because the stuff which broke was _rare_ and _deep_.

One could argue that everything would be config-related if all the code were interpreted and considered to be configuration. So absolutely everything could be fixed in Production.

I'd argue that absolutely everything could be _broken_ in Production too, in that case. The point is that you test the invariant stuff, and have a small surface area of variables which define the permutations of Live behaviours.

Configuration is not code. Code gets tested and doesn't vary between Canary, Nightly, Stable Test, Customer Test and Customer Live for a given build.

Because some of us build stuff for customers who won't justify the 'risk' of updating every day, and have upgrade cycles measured in months.

</comment></comment></comment></comment></comment></comment></comment><comment><USER52> To me, worrying about config files seems like the ultimate exercise in bikeshedding.

You either need a simple list of items (eg. dependencies) or key/value pairs. Use a text file or yml or json or whatever.

Or you need templating, the use of functions, etc, like dhall provides. But then, why not use the language you're already using for the rest of your project, or a bash script to export some variables?

Might sound like I'm throwing sourness around, but I just don't see the niche for this, except inventing a new thing for the joy of it?

<comment><USER53> > You either need a simple list of items (eg. dependencies) or key/value > pairs. Use a text file or yml or json or whatever.

You clearly haven't wrestled with kubernetes configuration files.

Reams and reams of YAML, heavily indented to represent umpteen nested objects.

Templating, bash scripts, using your favourite language to roll your own config generator - these are all well trodden approaches that fail to scale.

Official shitshows like Helm have come along with nothing more innovative to offer than templated YAML. The next version uses lua to generate config, but I remain skeptical given previous design choices.

We can question whether kubernetes has pushed the dial too far towards necessitating mountains of config, but for now it is most definitely a problem for us users.

<comment><USER30> My favorite is when people write scripts that concatenate YAML files in such a way that you have to be really careful about how this one file always needs to be indented by 12 spaces otherwise everything breaks in horrible ways.

</comment></comment></comment><comment><USER54> What's with the commas at the start of lines?

<comment><USER55> Makes it easier when commenting out. Use this trick for SQL and JS too (to prevent trailing comma issue)

<comment><USER16> I don't get why you'd build a language in 2019 which disallows a trailing comma in lists.

<comment><USER24> Yep. The solution to comma issues isn't to put every single one in a place nobody usually puts them - it's to be more forgiving about allowing the occasional trailing one.

<comment><USER56> The solution is to get rid of them. They are not necessary.

<comment><USER27> Author here: commas are necessary to separate list elements in any language where function application uses whitespace (i.e. Haskell-style function application). If you're not familiar with the syntax, an expression like `f x y z` is a function `f` applied to three arguments (`x`, `y`, and `z`), analogous to `f(x, y, z)` in a more traditional language.

Nix made this mistake of using whitespace to separate list elements _AND_ using whitespace to separate a function from its argument and it is a very common pain point for new users, because they will write something like this:

        [ theFunction theFunction'sArgument ]

... thinking it will be parsed as:

        [ (theFunction theFunction'sArgument) ]

... but it actually gets parsed as a list with two elements, leading to a bizarre type error.</comment></comment></comment></comment></comment></comment>


Groovy 3.0 Released - <AUTHOR> https://groovy-lang.org/releasenotes/groovy-3.0.html <comment><USER2> Congrats to the team - it's been a huge undertaking and a long time and many fundamental improvements to the language are included, including a lot of harmonisations to make Groovy syntax compatible with more recent features of Java.

</comment><comment><USER3> Does anyone know if there are any known breaking changes? I know they wrote a new parser which is the reason for the 3.0, but I can't find any place that lists out what's known to be breaking.</comment>


An idea for an RSS filter: if it existed, would you use it? - <AUTHOR>

I am thinking of writing a RSS filter/reader with an extremely simple user interface: you upload an OPML file, and it displays a reddit like list of links which you can rate or visit. My question is: how important is an RSS reader's ability to display the content of the RSS feed? Since many feed doesn't include the full content and you have to visit the main site anyway, it is better to just display the title as a link? The reason I am asking is that in order to personalize, you would have to gather data, which is impossible to do unless the user is using your RSS reader, and I do not have the expertise to write a (full featured) RSS reader. <comment><USER2> <http://aiderss.com></comment>


Ask HN: What are your thoughts on pulling a "Jason Zimdars"? - <AUTHOR>

http://jasonzimdars.com/svn/ is what I'm talking about.
There's a particular company I want to work for and they have recently added a job posting that I can apply for. I really want this job and I have done something similar as Jason did for 37 Signals (although I didn't design anything as the position is not for design).
I am having second thoughts on how it will be perceived.
(I'm not also sure if it's a good idea to post this here, I know that one of the company's recruiters visits HN) <comment><USER2> What's the harm in trying? If they laugh and think it's dumb, oh well, they probably would have done the same for your resume, if they even see it. At least it's different from the man resumes and emails they will receive.</comment>


Can We Have Prosperity Without Growth? - <AUTHOR> https://www.newyorker.com/magazine/2020/02/10/can-we-have-prosperity-without-growth <comment><USER4> Growth is an international arms race.

I think the biggest problem is that economic growth gives countries a (military) advantage. If you opt out of growth-based economic system, your neighbors will have more army or resources or manpower. They will eventually invade you or dominate you economically.

This is similar to the situation Africans were during Industrial Revolution. Europeans needed a lot of workers for factories and plantations, so they would visit a coastal African country and buy slaves. You could refuse to sell them slaves, but then they would sail to your neighbors and sell them firearms. Then those neighbors would have substantial military advantage and could invade you. There were only two options: be the ones that receive the rifles, or form a large alliance which refuses to sell slaves to Europeans. Forming large alliances is HARD. Africans weren't stupid - they tried to negate the technical advantage, for example the king of Kongo wanted to pay well for ship technology. (source: "Black Mother" by Basil Davidson)

Back to prosperity without growth. To resist pressure from neighboring states that practice economic growth, you would need to continuously improve efficiency and that's hard. Produce terminator-like killer machines and drones to make up for less numerous army. Have super advanced science, strategy or diplomacy. The only country I know that comes close is Switzerland, and it has the advantage of mountainous terrain away from major transport routes. Ideally the advantages you have should be ones that can't be taken away from you or "stolen" via espionage.

<comment><USER5> 1% growth difference over 100 years is the difference between the per capita income of the US vs Mexico. So yes, unless you arbitrarily limit the entire globe to some level of prosperity like a novel about a disutopian world ruled by an evil anti-science theocracy, people are going to look at countries growing faster than them and wonder why they have to slum it like peasants without their flying cars and vacations on the moon.

<comment><USER6> > _So yes, unless you arbitrarily limit the entire globe to some level of > prosperity like a novel about a disutopian world ruled by an evil anti- > science theocracy,_

I don't see much evil to that (limiting the "the entire globe to some level of prosperity"). Nor it has anything to do with being anti-science. You could be pro-science (pro understanding the world, physics, math, etc), and against continuous growth.

Better that models that treat the environment as externalities, or which convolute and stress the daily life for ever more trinkets to fuel the growth machine...

<comment><USER7> You probably live a comfortable life and is mostly satisfied with what you have so you see no need for more growth. Now imagine someone had the means to implement this same idea 200 years ago. We probably wouldn't have water and sewage treatment, fast transportation, modern medicine, electric light and all the appliances that come with it, internet, etc. I find it disingenuous to dismiss all these as trinkets.

This would be basically limiting the possibilities of all future humans in the name of some "greater good". That is textbook evil for me.

I think the main problem with this kind of thinking is that it is always based on what you know now, and not on what is possible. The world we live today, our technology, and the way we use resources would be unimaginable 200 years ago. The same is true about our knowledge of what will be possible 200 years from now.

<comment><USER8> I think you are being disingenuousby saying 200 years. Except medical advances and science, I'd be all willing to trade ALL the economic "growth" in the first world of the last 20 years if we could also revert wars, climate change and destruction of habbitat for the last 20 years. Oh, and by "growth" I mean the insane asset price inflation and concentration wealth, strengthening of the military-industrial complex, monopolisation by corporations, too big to fail banks and financial institutions.

<comment><USER9> Do you also mean AI, space flight, genome research, evolution of computing, etc?

Also - I agree that growth in the first world came at the expense of the middle class - but in much of the rest of the world, it didn't. I was _massively_ poorer 20 years ago (and not just me, most of my country, really). And it's not a singular thing - AFAIK a lot of people came out of poverty in those last 20 years. In east asia & pacific this seems to have been dramatic: [https://ourworldindata.org/exports/share-of-population- livin...](https://ourworldindata.org/exports/share-of-population-living-in- extreme-poverty-by-world-region_v4_850x600.svg)

<comment><USER10> I think you know OP didn't mean those:

> Except medical advances and science, I'd be all willing to trade ALL the > economic "growth"

I don't understand if you're making a larger point or not, but the "first world" is the focus of the discussion of whether or not growth economics is harmful. It worked fantastically well for the first world for many years, possibly even the 200 year scale that the commenter above challenged. The issues have arisen in the last 50 years (opinion incoming) and particularly since the US, and UK embraced the Trickle Down model that Reagan pulled over the American people's eyes.

Western Civilisation spent some 600 years taking their freedoms from those who held them down -- the politically, and economically, elite. In 8 years President Reagan convinced the American people that these overlords no longer needed to be held account for taking the bulk of the wealth of the masses for themselves, on a promise that it would come back to them, and that this was a required measure to encourage growth of the economy as a whole.

This was a bald-faced lie, wealth-capture and the chasm of wealth inequality was at an all time low in the developed world circa 1970, the last 50 years have served only to restore the land- and robber-barons to their political city on a hill.

They used the oldest tools in the despots handbook to achieve this: propaganda and agents provocateurs.

Today it is easier than ever for the political class to deploy these weapons against their citizens (whom, by the way, should be their peers in a democracy), and to obfuscate the use of these tools from those worst affected.

<comment><USER11> Problem is that view is contradictory.

In the absence of discovering a natural resource bounty, GDP (economic) growth comes from two sources:

1\. More people working harder.

2\. Better technology.

If you exclude "medical advances and science" you're basically excluding (2) which means the only source of growth is (1). More people working harder. Saying the world can only get better by increasing the number of hours we work is dystopian and doesn't make sense to wish for.

Ultimately, all progress comes through technology.

<comment><USER12> That's a big claim you're making. Can't economic growth (AKA inflation) come about from rising asset prices such as houses?

It seems to me that conflating humanity's progress and economic growth is exactly where our problems start.

<comment><USER8> How is a rise in house prices helping the nobler parts of the economy? People spend considerable more of their income on mortgages or rents, leaving a lot less for other less fixed and shorter lived assets. I'd be 1000% satisfied with a 50' house and valuation, leaving me to spend my money on travel, charity, high-tech or just work less, do stuff that really interests me; or spend a lot more on education. How is the education bubble helping the progress of humanity?

I'd be extremely happy with the education + costs of 50 years ago, or just online education -- I'm not talking about content, but delivery and costs.

It boggles my mind that people don't see it for what it is -- the feudal lords are back and they take a lot more of your production just so you stay alive.

They are not helping humanity(except for some benevolent ones) progress, they 99% help themselves.

<comment><USER12> Sorry if the language wasn't clear but that is the point I was trying to make: when we use economic growth as a measure of improving quality of life for people, it ceases to be a good measure.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> The one fundamental reason why growth is so important is that without growth, the economy becomes a zero sum game. In order for you to get more money you _must_ take it from someone else since there is only a fixed amount. A low growth world is one where we plunder each others' wealth, not one were the incentives are aligned with building new industry.

That's why productivity increases are so important. Without them, if we want growth, we have to get it from positive sum games. I'm skeptical that will provide enough to stop people from reverting to a more Malthusian plunder mindset.

Any vision of a non-growth world needs to take that into account. Without growth we'd have to fundamentally rethink how we handle distribution without reverting to bloodsport.

<comment><USER14> As bilekas was saying, the one fundamental reason why growth must not be so important is that it cannot continue ad infinitum, thus we will have to learn and cope with that.

While you state an important point, the issue of growth having to stop (sooner or later) cannot be ignored.

<comment><USER15> Growth may eventually stop if humans remain constrained to Earth, but if we can advance to a point where we can mine the Asteroid belt between Mars and Jupiter, the wealth influx from that will be enough to sustain growth in human society far into the future.

</comment></comment></comment><comment><USER16> As far as I can tell this is just a misunderstanding of "growth" in an economic sense. Growth is the result of improvements in productivity, which tend to reduce energy use (per item produced). We consume more energy _net_ because we produce more.

If, eg., products became more expensive because of limited energy (or relevant taxing of externalities) then we would grow more slowly -- we can still produce more through innovation _and_ consume less energy.

It took a huge amount of energy in the past to make a single pair of socks -- today, it takes a tiny amount.

I think the relevant question for 'exponential energy-consumption graphs' is what the relationship is to growth (it simply cannot be assumed that there is a 'deep causal' relationship; this is fallacious equivocation).

Eg., population has been increasing exponentially. Could a static population size produce a flat (or falling) net energy use graph -- whilst still obtaining economic growth (ie., productivity improvements)?

<comment><USER17> Empirically, economic growth has always been related to consumption of energy and raw materials. One explanation is the Rebound effect[1]

Maybe theorically they can be decoupled, but we have yet to see that in the real world.

More about it: [https://eeb.org/library/decoupling- debunked/](https://eeb.org/library/decoupling-debunked/)

[1] [https://en.wikipedia.org/wiki/Rebound_effect_(conservation)](https://en.wikipedia.org/wiki/Rebound_effect_\(conservation\))

<comment><USER18> There is a lot of raw materials and energy. The problem is how clean we can do extraction and energy generation. So it's not surprising that we are still very much tracking both correlates.

</comment></comment></comment><comment><USER19> Lots of people underestimate the degree to which economic growth fuels good life outcomes for wide swaths of people.

-Even though many people live paycheck to paycheck at many different income levels, enough income growth can get you out of a paycheck-to-paycheck lifestyle and enable you to have real financial autonomy.

-One thing that has stuck in my mind over the last few years is that one of the worst outcomes of unemployment is when people feel useless as a person- leading to psychological problems and behavioral problems.

-The pace at which we solve real, useful problems grows with economic growth.

<comment><USER20> More importantly, you can enjoy (maybe exploding inequality moderates this a bit) a rising standard of living while living from paycheck to paycheck.

Growing up I was raised by classical musicians permanently on the bleeding edge of solvency (not with debt either) but new _stuff_ kept coming that increased both their quality of life and "nonmonetary" productivity: microwave ovens and computers that my dad could use to take his orchestral compositions (in sheet music for all parts) to part sheets (for individual players) automagically whereas this was _work_ before.

We weren't in the kind of self-reproducing poverty because my parents had a high "cultural level", but we were definitely cash poor, and yet kept getting wealthier and wealthier.

</comment></comment><comment><USER21> It's fascinating how the reality of Earth being embedded in a vast ocean of resource is completely lost on so many. Human ingenuity is key. With every step we unlock another level of resource utilization driving prosperity. If anything social organization and financial frameworks need to support the unfolding of our technology tree. As humanity we just woke up. Enlightenment now.

<comment><USER22> > Earth being embedded in a vast ocean of resource

This reads like prosperity gospel and law of attraction nonsense rolled together and repackaged for a technical audience.

A kilogram of _anything_ from space is orders of magnitude more expensive to acquire than a kilogram on Earth. No technology will change that within my lifetime. If there are no physics-redefining advances in nuclear fusion and/or nuclear fission, my grandchildren will probably be able to make the same claim.

<comment><USER23> >A kilogram of anything from space is orders of magnitude more expensive to acquire than a kilogram on Earth.

This is true, if you are on Earth and wish to remain there.

If you are in space already, and don't have deal with pesky things like gravity and friction, it could conceivably be way easier to chip a lump of metal off an asteroid and hurl it in the general direction of where it needs to be, than to dig it up and put it on a boat. It's a bit chicken and egg, but it's easy to imagine a scenario where off-world becomes the new Shenzen.

<comment><USER24> > It's a bit chicken and egg, but it's easy to imagine a scenario where off- > world becomes the new Shenzen.

So easy to imagine that we've been doing so for 40 years [0]. In fact, the basic technology seems to have been in place for 40 years as well, but no economic incentive to execute on these grand plans for permanent human habitation in space has yet been found. Furthermore, I have yet to see any evidence that such incentive will ever be found.

[0]: [https://en.wikipedia.org/wiki/The_High_Frontier:_Human_Colon...](https://en.wikipedia.org/wiki/The_High_Frontier:_Human_Colonies_in_Space)

</comment></comment></comment></comment><comment><USER25> I talk about the effects of limiting GDP-style growth on our lifestyle with my wife. We burn a lot of carbon and use a lot of resources traveling, but on the other hand in our day to day life we tend to buy food in bulk at health food stores, try very hard to avoid using plastic, share one fuel efficient car, etc.

Our take is that, for the sake of our grandchildren's generation and generations beyond that, that we would be willing to reduce our travel, concentrating more on visiting family and friends rather than international travel.

The effect has taken years to become noticeable, but not having network TV in our home so we are not deluged with BUY THIS NOW commercials for stuff we don't need has helped us to avoid buying stuff we really don't need.

As a society, if we invested more in libraries, public parks, venues for entertainment, science and education, etc. then I think we would be better off than embracing a more material world/life style.

Everyone gets to make their own decisions, so for my preferences to be achieved, we would need to stop corporate socializism and make consumers pay the real costs for goods. An example would be to remove the $50b per year water subsidies for the beef industry, and make consumers pay for the approximately 4000 gallons of water required to produce a pound of meat in the grocery store.

<comment><USER26> > An example would be to remove the $50b per year water subsidies for the beef > industry

Do you have a source for that? Every one I have been able to find indicates that total meat and dairy subsidies are less than that, let alone just water subsidies for the beef industry.

<comment><USER27> I doubt it's a remotely accurate figure. However, cattle consume a LOT of water. 20~ gallons per head per day is a fairly accurate figure and the US has something like 95 million cows.

So with farming and animal husbandry water rights are a big thing. Often water rights will go to farmers/ranchers long before they go to people.

So you've got cows, with a conservative estimate, using 500 billion gallons of water a year in the U.S. alone just for drinking. Obviously most of that is coming from natural sources but that has financial impacts on the treated water that ends up pumped to your house/business via pipes. How big is that financial impact? _shrugs_

I highly doubt it's close to 50 billion USD a year though.

They definitely do get comparatively obscene amounts of financial benefit though. Water rights, forage disaster, livestock compensation, indemnity payments, feed assistance, general relief, then you have to think about what sort of subsidies the growers get that then gets passed through as a benefit in the price of the feed going to the livestock...

Man I love meat, I love love love meat, but I switched to primarily whole food plant based last year. WFPB is far more sustainable as far as water and land, arguably much healthier, requires far less fossil fuel input, and noticeably cheaper (my weekly grocery bill as halved).

<comment><USER28> And who knows if that water even comes from renewable sources...

</comment></comment></comment></comment><comment><USER29> Cue to a physicists view on this subject (starting from basic termodynamic principles):

[https://dothemath.ucsd.edu/2012/04/economist-meets- physicist...](https://dothemath.ucsd.edu/2012/04/economist-meets-physicist/)

<comment><USER30> Do the Math is one of my favorite sites on the internet for the value and perspective it brings. I had a few great conversations with its author on my podcast [http://joshuaspodek.com/guests/tom- murphy](http://joshuaspodek.com/guests/tom-murphy).

I found this report valuable too: Decoupling debunked – Evidence and arguments against green growth as a sole strategy for sustainability: [https://eeb.org/library/decoupling- debunked](https://eeb.org/library/decoupling-debunked).

</comment></comment><comment><USER31> Debt-based monetary systems will skew towards ever increasing growth.

<comment><USER32> The way I think of it is that in order for debt to exist, interest on the debt must be paid. But to pay interest, you must create more value than the debt you incurred, otherwise you'd not have enough to pay the interest!

But the other side of debt is somebody's deposit. So if you summed the debt, it must be equal to all deposit. So from where would the interest come from? It must come from new production. But interest paid become a new deposit (for somebody), and from that new deposit, new debt is created...and hence, require infinite growth to continue to service interest payment.

<comment><USER33> I think there is something wrong with your premises. There is no rule of law nor nature that interest must be paid. Negative or zero interest are completely possible.

<comment><USER32> but if someone loaned out money to somebody else, you'd expect that they'd ask for interest payment.

negative interest rates seems like it's an impossibility (in the sense that only a central bank is willing and able to charge negative rates) for normal commercial loans. And if a bank charged negative rates on deposits (higher than it costs to keep cash safe in a secure safe!), then i suspect people will just withdraw their cash, unless something forces them to keep it in (like the abolishment of cash by central authorities).

<comment><USER33> In Denmark you can take a mortgage and "pay" negative interest rate [1]. That is, you pay less back than what you borrowed. I fully agree that most people would expect the interest rate to be positive, but their expectation is no rule.

Actually I am very sure interest rates have no causal relationship with continuous growth. The one (and only?) thing where the the continuous growth requirement comes from is that most people do not want to be unemployed. _That_ is the choice you need to make. Do you want growth or unvoluntary unemployment?

[1] [https://www.cnbc.com/2019/08/12/danish-bank-is- offering-10-y...](https://www.cnbc.com/2019/08/12/danish-bank-is- offering-10-year-mortgages-with-negative-interest-rates.html)

<comment><USER32> that denmark negative interest rate is interesting. But it still doesn't quite answer the central issue - who is "giving up" money to lend? The guardian article ([https://www.theguardian.com/money/2019aug/13/danish-bank- lau...](https://www.theguardian.com/money/2019aug/13/danish-bank-launches- worlds-first-negative-interest-rate-mortgage)) only mentions that it's banks passing on negative rates from institutional lenders in money markets.

<comment><USER33> Sorry, I do not quite understand your question.

Anyway, it is ultimately (when you get your head around it, that is...) relatively simple. These institutional investors have cash (well, not exactly cash, but "cash" as in overnight deposits) that they need to invest. some poart of that they want to invest in "safe" instruments, e.g. bonds/commercial papers issued by banks. And it happens to be that they are willing to do that even if they are paid negative interest rate[1]. So the bank pays for its funding say -1.0%. Then the bank can lend the money forward with -0.5% and still make money.

[1] Why do they want to do that? If you have a decent amount of money, say millions, and you want to save that for a while to purchase something say next month, you have not that many good alternatives to bank deposits/commercial papers/bonds. Actual cash is surprisingly cumbersome and expensive. Stocks are risky, you may lose quite a bit within one month. Government bonds pay even less. so if your bank says yep, we take your money for a month and pay you back a bit less in a month, you are likely going to swallow it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER34> This is dumb, and subtly evil too. We can have the cake and eat it too:

The point is to keep the growth of _scientific understanding_ and of _technical know-how_ without producing too much physical crap that is hard to recycle and overloads the environment. We need to:

(1) move our economy to more non-physical / virtual goods and service - we're doing this, but we could do better, since there are still lots of "status goods" (with little practical survival utility) that are physical and damage the environment by their production and operation - _the rich should be able to buy better VR-avatar spells or exclusive-in-game-diamonds or whatever instead of cars, yachts, expensive to maintain houses etc.!_

(2) make warfare fully digital in means and virtual/economical in consequences - 99% of conflict should be cyberwarfare-with-low-environmental-impact - <USER2> in "hacking to steal coins from country X's national budget wallet", not "hacking to sabotage industrial infrastructure" (sure, people will still die when country X goes bankrupt and nobody living there has health insurance anymore, but this shouldn't happen that often...)

A solution for accelerating (1) would be increasing research into how to make virtual stuff feel real and be more and more _addictive_ \- real-world "stuff" should feel soul-crunchingly-boring to our dopamine addicted brains (why go on a cruise ship or travel to Tropifukistan, when you can ride a dragon around Hogwarts and earn $$ if you're good at it!) For (2) it probably helps that everyone getting to have WMDs makes everyone scared s`less of larger scale military conflict. Oh, and fear of communicable diseases also helps move towards (1), as we can see now, but I'd personally prefer alternative "solutions"...

 _So we 're probably heading in the right direction, we just need to stabilize the symptoms/consequences of environmental degradation short-term, and to push-the-pedal-to-the metal to disconnecting our consumption-oriented economy from the physical world (and on a parallel track go for the space- colonization-game for actual physical action - the fans of "real war", could have it too, but outside Earth, heck they could even bring in the nuclear toys, space is large)._

<comment><USER28> ur dumb :p

No, seriously, the "digital economy" is not new these days - have you seen any positive impact on resource consumption / pollution ? It only got worse...

Warfare is about control of real resources - some people might be willing, but countries in general won't settle for fake ones !

<comment><USER34> Ofc you'll say that "it only got worse" overall bc other things got worse... The digital-virtual economy needs to grow at least 10x, and percentually to at least 95% of the actual economy (physical goods need to be comoditized, and some maybe distribute equally in a pseudo-socialistic way, outside of the economical system - the fight should be for virtual resources). You're not going to see any "things getting better" result yet, we need to go full-speed all-in in this direction, not half-heartedly... Virtual economy has a > 100x growth potential once we have better VR, AR, and later neural interfaces. "Demand" will appear or be manufactured, in the end we'll probably have too much of it.

And tons of services can be created even around the negative consequences of this... all the cornucopia of new diseases mental and physical brought about by excessive virtual consumption will boom into a huge healthcare industry etc. This will also be growth!

And just like "power" can't be real or fake, it either is or isn't, same with resources - as long as there are exchange mechanisms, there's no difference between "real" or "virtual", everything is as real as everything else...

Entities that insist on "old fashion fighting for `real` resources" should be restructured. People rewired / reeducated.

 _We 're on the right path, but yeah, we're maybe only 0.01% of the way there... need to do things faster and harder. Let's not chicken out now and go retro/conservative instead of pushing further! The future is... amazingly incomprehensible! Heil to it!_

<comment><USER28> I concur, you'll either have the power working to make your computer/VR/network run - or not. And it's the people that have the control over that power delivery that are going to have the real power (as they always did). Who is going to restructure / rewire / reeducate Vladimir Putin (or the like), hmm ?

<comment><USER34> > Who is going to restructure / rewire / reeducate Vladimir Putin (or the > like), hmm ?

"Control over physical resources" is just a means, not an end... If you want "more power for your nation" or whatever and the world stage has been restructured so you can better get that by playing a different game, you'll switch the game. And Russia seems to be good at both cyber-warfare and "mental games", they can get even better and win even more, good for them, whatever.

(And the future of cheap-renewables plus mini-nuclear will mean power/energy will be available to everyone... fight would be more on "fabrication and repair capability/tech for next-gen hardware" or stuff like that - here China and SE-Asia seem to be winning the game, and they overall are pretty pro- globalistic and pro-virtual... for their own f up reasons, but whatever, if it pushes things in the right direction, fine.)

Anyway, things are going fine, though slow (sometimes progress goes one casket at a time unfortunately)... let's just hope some people don't f things up because they have their own personal/national/etc. crusade to fight for and mix it up with nostalgia for the "past full of meaning" and they drag us into some messed up war. Let's try and be peaceful and keep commerce flowing, previous generations have worked too hard to get this global system going for us to f it up by, ironically, being nostalgic for some good-ol-times that never actually existed...

<comment><USER28> > And the future of cheap-renewables plus mini-nuclear will mean power/energy > will be available to everyone...

This is wishful thinking. You would need incredible improvements in technology to maybe hope to start reducing resource consumption. Because so far, resource consumption only got worse as efficiency got better.

</comment></comment></comment></comment></comment></comment><comment><USER35> "Growth" is surely a good way to ease domestic pressure, but I believe it's not the only option. What we need is more "optimization", not corporate-wide, but society-wide.

The idea is still vague even to myself, so let me give a concrete example: self-driving car. While CV/AI-based self-driving cars certainly can drive, it should still acquire most critical information, like signals, crossroads, lanes, obstacles, etc, through ambiguous-at-best algorithms. At the same time, the inherent difficulty in making good-enough AI empowers companies over people, which is a straight highway to cyberpunk dystopia.

However, what if we implant digital data sources all over the road? (1) self- driving cars will always acquire correct data (2) developing safe self-driving cars become much easier (2-1) market diversity is ensured (2-2) people regain power (3) it is much easier to achieve the economy of scale with sensor nodes than cars.

Or, perhaps, what about delivery/reservation services? If the standard protocols are enforced on all restaurants, we can cut all the middlemen, lowering the prices. The same can work for taxi, hotel, scooter, bicycle, etc.

We really should start rethinking about things we have and use. The industrial structure we have today is just a mess caused by the rapid IT revolution. We weren't really ready for it. But now we've expanded enough, and should shrink down, so that we can have breathing room for another move.

<comment><USER36> 100% agree - Most likely data interoperation/protocols need to be enforced by government as there is no economic incentive to do so otherwise.

</comment></comment><comment><USER37> As long as you have short term growth targets (quarterly financial results) you cannot get big businesses to reckon with the environment. The only possible way is for people to stop buying unwanted stuff just because it is cheap.

<comment><USER38> > _" you cannot get big businesses to reckon with the environment."_

Well, that's what governments are for. It is the government's role to create regulations which promote the broader, long-term interests of the population and environment in situations where markets fail to do so.

<comment><USER28> And the issue is that big business can afford to "buy" the government. I don't see any other solution to this than to outlaw big business...

</comment></comment></comment><comment><USER39> But why? The universe is so vast and under-populated it's hard to make a case why growth would be constrained.

<comment><USER6> We don't live in the universe at large, we live on Earth. Until someone takes us there or shows us how to go practically, and bring stuff back practically (not with e.g. "generation ships" and not with hand-waving about what we could or could not do with "ingenuity" in 100 years), we should not use a mere wish as a permission to not respect the hard present limits.

(That's not something said against the idea of space exploration. In the contrary, not respecting those limits might be the very reason why we never reach the universe -- e.g. because we collapse before we have a chance. Same in this regard as our playing with nukes and other careless follies).

<comment><USER40> To do that, we need more research, more production, better technologies, better energy usage, which turns out to be growth.

<comment><USER6> No, we could do that with limited growth (of general commerce economy) and just having more resources given to science. Even as a matter of political will (tons of resources in the US e.g. are given to the military which could be use for NASA programs).

We went to space with an 1/10th the economy of today. We had not been to the moon for 40+ years, despite the economy growing ever stronger.

<comment><USER40> What got America to the moon was taking the leftovers of an beyond-imagination evil dictatorship, designed to take over the world, and applying it to win a race against another dictatorship. During that whole process millions of people experienced horror or lost their lifes in the cruelest ways imaginable.

While I acknowledge, that economic growth has problems, it does not seem all that bad to me.

I imagine going to the moon just is not a priority right now. The superrich already want to spend their money on space projects. Let's wait what regular people want to buy, after health, etc. is solved.

</comment></comment></comment></comment></comment><comment><USER41> Growth includes technological advancement, including for example ... trying to cure cancer and Alzheimer's.

Am I correct in this?

If so, please let's stick with growth.

<comment><USER42> Innovation can positively influence growth. But the article, including references and papers, is not about reducing innovation.

It is about the fallacy that economic growth (= increase in GDP), somehow magically solves all problems of society. This belief is mostly ideological and the implication is that the market should not be regulated, which would reduce growth and prosperity. The effects of this strategy include increased inequality, weak infrastructure/education and ecological exploitation with dire consequences.

Innovation, which really advances society in sustainable ways, is often intrinsically or socially motivated, not financially and certainly not by a GDP increase, which benefits a tiny minority.

Reducing inequality, improving education and increasing individual freedom within organizations seem to be much more sensible ways to fuel innovation in the long term, than just deregulating the market.

</comment></comment><comment><USER43> What a more important measure is growth per capita, not growth in the absolute for personal prosperity / national stability etc. Population decline combined with growth per capita can both bring prosperity while reducing our adverse impact on the planet.

</comment><comment><USER44> Yes — iff your monetary base isn't brought into being by payment of interest.

If interest must be payed in order for each unit of currency to exist, then growth is required. If not, then equilibrium between stock/flow of money and available goods/services/wealth for sale can be maintained.

If currency is brought into being by attachment of wealth (as is done in typical users based Fiat via Liens), then issuance/withdrawal of units of currency is accomplished across the entire base, to ensure absolute value stability vs. a reference basket of arbitrary commodities (or whatever)

</comment><comment><USER45> I'm not sure how you would fund pensions without growth

<comment><USER46> Agreed. you can not. There are just too many pensioners: "Between now and 2050,the number of older persons will rise from about 600 million to almost two billion. In less than 50 years from now, for the first time in history, the world will contain more people over 60 than under 15"

[https://www.cassandracapital.net/post/the-unprecedented- demo...](https://www.cassandracapital.net/post/the-unprecedented-demographic- boom-and-bust)

<comment><USER47> And how is that a problem? As long as productivity grows at same rate as workers/pensioners ratio, the portion of gdp that should go towards retired ppl remains constant.

<comment><USER48> That productivity will have to come from automation, and a robot doesn't get a salary so doesn't have to pay income tax. So that'll have to change if you plan on using the productivity growth to fund pensions, no?

<comment><USER49> You might not need a pension if you have a robot that is highly productive towards you. Everything might be so cheap. All the externalities that one needs to pay for a lot today, might be vastly available tomorrow. I think it is hard to predict the future.

<comment><USER45> This is an interesting thought experiment. I think it's conceivable the cost of many things one needs would fall as a result of automation - but there are many things which have limited supply and that there would still be competition for, many of them consumable - so you would still need a source of income for these.

</comment></comment></comment></comment></comment></comment><comment><USER38> Perhaps a better way to phrase the question would be:

Can we have economic growth, improving prosperity and quality-of-life, while reducing our environmental impact?

<comment><USER50> That's actually the question most people have been asking for the past decades. The answer is: The world has tried and failed and there's some serious questions about the plausibility of that endeavour.

The question whether growth==good or maybe just.. it's more complicated than that and we may be able to get more quality of life without growth is far more interesting.

<comment><USER38> Have we _really_ tried? Firstly, despite a lot of talk and bluster, politicians around the world have done very little to regulate against climate change and other environmental issues.

Secondly, many of the technologies that will make this possible - <USER3> energy, electrification, energy storage, etc, are only just now beginning to reach the mainstream. Many of them seemed like science fiction in past decades.

<comment><USER50> > Firstly, despite a lot of talk and bluster, politicians around the world > have done very little to regulate against climate change and other > environmental issues.

Interestiong question is what's cause and effect here. You could argue politicians haven't done more against CC because they always shy away from doing anything that might harm the economy.

</comment></comment></comment></comment><comment><USER51> Prosperity without growth. Only possible if money has a half life. This slow devaluation of money over time would allow stable prices, growth and more granular control of the economy. This kind of money could be electronic and only minted by the fed as FED-COIN. The blockchain would be essential in tracking and controlling each fedcoin. An interesting solution might be for the fed to give fed coin to people as a UBI(Universal basic income). Of course once the fedcoin is spent(undergoes a transaction) it's value would freeze. the seller of a product would then have regular money. The current mode of the fed being limited to repo operations is blunt. Direct involvement of the fed with the public would allow more direct management of the economy. In addition fedcoin would traceable (anti crime), taxable, and controllable(it might have no value for example in trade for gambling, cigarettes alcohol or other items that are unhealthy)

<comment><USER52> You would then have to try to ban bitcoin Why would an individual want to keep around an eroding by design currency?

> In addition fedcoin would traceable (anti crime)

You would only successfully trace the law abiding citizen IMO.

<comment><USER51> The incentive to spend it will drive the economy. The ability to prevent its use in 'bad' transactions will limit 'bad' behavior.

</comment></comment></comment><comment><USER53> Relevant: WTFHappenedIn1971.com

</comment><comment><USER54> I am getting the impression that growth is largely an illusion, because there is also something like inflation. And it also seems that it is mostly the (very) rich that benefit from the growth.

<comment><USER28> Growth doesn't necessarily mean money-wise. And GDP is generally tweaked to make inflation disappear.

</comment></comment><comment><USER55> If an industry has grown so much that it can fulfill all the demand the market has for it, why does it need more growth?

So "growth" would come from changing demands eventually.

</comment><comment><USER56> The more important question is: can we have growth in economic output (which is what we actually want) without growth in economic input (which is purely instrumental)?

<comment><USER28> Short-term - maybe, though past history isn't exactly positive about that.

Long-term : no, as this would reduce economic input to an arbitrary small fraction of the overall wealth, which anyone would be able to corner. So it's either self-limiting or unstable.

</comment></comment><comment><USER57> Prosperity is subjective. Growth is not or relative. Can we turn a long string into a boolean? So no. The question itself is logically flawed.

</comment><comment><USER58> well, we better figure out how to do it or will kill the planet and then die along with it.

it's not an easy challenge; over 6000 years of western cultural evolution are built, hinged and based on growth and expansion by exploitation. but there aren't many thing left to exploit nor expand into.

</comment><comment><USER59> Can you get countries not to compete?

</comment><comment><USER60> As long as

* our needs and deeds don't take over

* marketing stops to teach us longings for things we actually do not need --

Yes!

</comment><comment><USER61> Can we have prosperity without growth? No. Can we have sustainability with growth? No. Then we can not have prosperity and sustainability. Can we afford not having sustainability? No. Then we can not afford prosperity.

<comment><USER62> We can have sustainability and prosperity.

It's a triangle: prosperity, sustainability, population. Choose 2 (and obviously if you don't choose sustainability the sh*t is going to hit the fan at some point anyway).

The key issue is the global population.

(Edit: We're discussing life on this planet. Colonising space obviously means that human population may continue to grow, but not on Earth and not using Earth' resources)

<comment><USER32> why can humans not expand interplanetarily? Then, inter-stellarly, then finally, inter-galactically?

<comment><USER63> If humans can expand inter-galactically, then it likely it would have happened already by some other species, given the size and age of our galaxy. But since we're not part of some prior alien galactic empire, it's probably not feasible. And we would also be able to see the energy output from other galactic civilizations nearby. But we see nothing. Not from Andromeda, not from anywhere in our local cluster.

<comment><USER64> >If humans can expand inter-galactically, then it likely it would have happened already by some other species, given the size and age of our galaxy.

That's only true if we assume the chance of life arising is relatively high. It could actually be incredibly massively low, and we wouldn't notice, because we're observing from a position of extreme selection bias. I.e. probability(intelligentLifeInUniverse given weAreObservingIt) = 1.0.

</comment></comment></comment></comment></comment><comment><USER65> It depends on who "we" includes.

</comment><comment><USER66> Yes

</comment><comment><USER67> Europe

</comment><comment><USER68> Growth is good but we are entering an economic environment where countries and companies are growing simply to show growth. It's inorganic. In the past this type of behavior would result in boom and bust cycles, now the easy money has made it possible for us to go on indefinitely.

This all started with Wall Street. I want to make that ABSOLUTELY clear.

<comment><USER69> "Growth" just means "Wall St gets a positive return". That's all it has ever meant.

When wealth was being more aggressively redistributed this also meant the rest of the US saw some practical benefits. Now that's no longer true, it's just a numbers game for the 1%.

</comment></comment><comment><USER70> Yes, we can prosperity without growth. — We call that "socialism."

<comment><USER28> The USSR in the early 20th century astounded everyone by its amazing growth. Not surprising since Lenin's main goal was to beat the capitalists at their own game! (But the price paid was very high too...)

</comment></comment><comment><USER71> Short answer: No

Long answer: [https://ourfiniteworld.com/2011/02/21/there-is-no-steady- sta...](https://ourfiniteworld.com/2011/02/21/there-is-no-steady-state- economy-except-at-a-very-basic-level/)</comment>