sentiental

Thanks for looking! Yeah, I managed to typo the HN example - yes, my existing templates contain type="text/template", and I think that's how I filed the bug. It's possible for me to inject those templates with a variable instead of including them directly in the template, although that's a bit more invasive of a change than what I was doing before.

One thing that might snag web applications built with Go 1.8 is the change to the html/template library. If you ever need to include script templates in your HTML for usage by a Javascript template framework (in my case it was EJS), then you will need to be aware that html entities will be escaped in a way they were not in 1.7

Given the following literal:

<script type="text/javascript"> <div><%= something %></div> </script>

Go 1.8 will escape the EJS delimiter, breaking the template. I.e.:

<script type="text/javascript"> <div>&lt;%= something %></div> </script>

I selected EJS specifically because I wanted a templating library that didn't conflict with html/template's handlebars syntax. If you're in the same boat you'll want to find a template engine with non-html entity delimiters.

I have been concerned that Docker's scope was expanding too far for a while now, so I'm glad to see an alternative that might work appear on the horizon. That said, I am somewhat concerned that CoreOS has a suspiciously similar business model to where Docker would probably like to be.

It's in a business's best interest, and exceedingly common practice, to "land and expand" with something clear and compelling, and following that add features to compete with alternative solutions. I don't think there's anything inherently altruistic about CoreOS that would keep Rocket lean in the long-run, especially as they begin migrating their various tools away from Docker containers.

One of the authors here. We didnt want to change the AST in a way that would be backwards incompatible with vanilla PHP. There is some luxury in being able to turn off this extension when needed. We also have a large enough existing codebase that switching to SPL types everywhere was a non-starter. Our goal here was partly to be able to use PHP's native types and still get some good coverage.

Phpdoc may not seem ideal, and it's not, but it has afforded some significant flexibility