They are just functions that take an AST tree, modify that AST or produce a new AST and return it. Its just normal Nim code working on an AST object. That's it! I wrote a small blog article about them when I first learned about them: http://blog.ldlework.com/a-cursory-look-at-meta-programming-...

I encourage you to conquer your fears!

I was just comparing to C++ - where you have to understand how everything about templates and the STL works if you intend to understand the error messages produced by the compiler if you use STL. Or any library that interacts with STL containers. I heard things on this front have improved - I myself have left C++ for C a while ago.

C++ is a monstrosity. A common advice is "just pick the parts you like and stick to them". But it never works that way - as soon as you interact with 3rd party code, you have to deal with the parts THEY liked.

In comparison, my intuition says that despite all the dark corners (and if you read the entire manual, there are quite a few of them), that's not the case with Nim; Instead, if you treat it like a dialect of Python, you'll get simplicity close to Python; You'd only need to understand those dark corners if you plan to make use of them.

But I will need actual experience in Nim to find support for or against this intuition.

I tried Golang, because it was sold to me as something I would love since I am a long time Python developer. I strongly dislike Golang. It doesn't have much in the way of letting me model my programs like I am used to. I am told "that's wrong, do it the Go way". This is too much friction. Once I am done thinking how to solve my problem algorithmically, I do not want to then figure out how to rethink my algorithm just for the sake of the maintainer's of Golang.

I tried Rust. I think Rust is beautiful (mostly). However, Rust has a far too fundamentalist view on memory safety. And that's not to downplay the importance of memory safety. But there's just too much friction. I want to sit down an implement my algorithm. I don't want to stop and spend just as much time thinking about the particulars that Rust demands.

When I found Nim I almost couldn't believe it. The core language was simple, clean and immediately absorbable. I was able to start writing basic Nim programs after just perusing the language docs for a few minutes while the compiler compiled. I read that Nim had powerful meta-programming facilities and this started to turn me off. I had heard that macros were generally a negative force in the world but only knew them from Lisp. Then I learned that Nim's macros are just functions that take and AST tree, perform modifications to that AST and return an AST tree. Wow that's pretty simple. Oh hey the generics "just work" like in C#. Woah, Nim even supports inheritance!

Nim is definitely the next language for me. In thinking about it, I find that I agree with one of Jonathon Blow's sentiments that we have been seeing a number of new up and coming languages but they are all Big Idea languages. Big Idea languages who's ideas have yet to be vetted and proved out over the course of a decade or two. They all incur too much friction.

Nim seems like a competent, low-level systems language with a helpful repertoire of well-implemented modern tunings to features that are all mostly established in the field. It doesn't try to revolutionize systems languages. It tries to bring us a modern refinement by bringing us a highly performant yet relentlessly productive take on what has already been shown to work.

Please don't be offended if you see me around evangelizing its existence.

The conference was awesome and there was plenty to announce at that point. It certainly helped drive home the conceptualization of containerization for many.

> we should take a good minute and consider

You're right we should consider - except what you're doing is making charges like;

"we are head-first rushing", "perpetuated by a for-profit company", "my company will be at the whims of Docker"

And other fear in this thread without providing your audience with the context of: - for profit companies backing an innumerable number of major technologies in a variety of fields since technology was a thing - most of the development of Docker happens outside of Docker Inc - the project has an independent governance board - the project has been nothing but the epitome of successful transparent open source

If Docker ends up achieving a cohesive ecosystem of holistically designed pieces solving one of the most difficult unsolved problems (a class of problems, really) in modern computing benefiting so many then is it really a problem paying Docker Inc for first class support to all of that? I imagine there are already companies selling support for Docker other than Docker Inc

It seems like you're the one imagining there is going to be no competition, honestly.

Yes, but managing multiple containers is more effort than 1.

Single process is a single process. [e.g. Nginx]

I think you are confused by what I meant.

Stateless single purpose containers is good. One process per container is bad because it involves more service discovery before you actually need it.

Furthermore, you can easily set all of the containers to share the same networking namespace so they can all just listen locally if you wanted a turn key solution. The pretty trivial issue of single-host service discovery is not a very strong argument against the benefits of single process containers in my experience.

1) Multiple docker containers to spin up and be managed.

2) Multiple health checks.

3) Set additional flags/do additional config for Docker.

The fact people consistently say "Eh, this is a non-issue" is great. It means you are much luckier and more skilled than I since you can manage all of that with 0 additional effort.

For me, all of this is effort I don't need to expend.

From the Docker Host itself, if you need to manage the state of a container, the intuition is that you need to go into the container (with SSH) in order to do so. But by externalizing your state, you can manage it without the need to enter the container. Assuming your Docker Host is secure, this doesn't make anything less secure just because you're no longer abusing SSHd in order to manage your application's state.

In the case you need to gdb, or strace the process, you can do that from the Docker Host with nsenter. Assuming your Docker Host is secure, you no longer need to abuse SSHd to carry out a debugging task that has nothing to do with needing a secure shell.

Neither of these use-cases have anything to do with the security of SSH.

In the case that you need to do these things from a remote host, the prescribed answer is indeed SSHd to access the Docker Host, at which point you switch to the previously suggested methods for managing state.

"I don't see how granting access to the host is a cleaner architecture... from a security standpoint, it seems the opposite."

Because now you only have to worry about one security layer instead of N security layers for each container you run. The security layer is now actually coupled to the act of granting access to the host, its intended purpose vs granting access to a container so you can manage its state or debug it or whatever.

As far as being locked into Docker's APIs, I totally miss the aim of this remark. Volumes are just paths on the filesystem. If you're talking about the interoperability of standard tools to manage your state, I don't think they will have problems in this case.

Yes, you missed the point. Please read the other response to comprehend the difference.