Pretty simple really: do the ads for the frying pan make the direct claim that the pan will put you on the path to becoming highly paid chef? Perhap opening a Michelin-starred restaurant with the skills your new pan has unlocked?
"you can cook better food" and "you can drastically improve your economic situation" are two very different promises (or implications) that should be held to very different standards.
I was investigating that for entirely unrelated reasons just yesterday and the answer so far seems to be "none". You can patch the server to serve the locally built frontend and it all works just fine.
I believe it’s slightly different in that I can declare a value (or parameter) of type T and know that it can’t be null/invalid.
Consider this Java method:
void frobnicate(bar Bar)
{
// is bar null? Who knows?
}
To get the same behavior in Helix, one would have to declare the parameter type as “Bar?”. If the parameter type is plain “Bar”, callers can still pass you a “Bar?”, but presumably you’d get an NPE at the call site and not somewhere further down the stack.
I’ve never heard of this language before today and don’t have an opinion on it, but I do find the Questionable Types interesting: sort of collapsing Option and Result into one very concise notation.
One simple idea* would be an option to exclude certain React elements from auto translation. That would allow users to handle these specific cases “manually” while still reaping the benefits of the automated system the other 99% of the time.
> Since XHP executes on a server that emits HTML, the most that you can do relatively seamlessly is to replace parts of an existing markup with the newly generated HTML markup from the server by updating innerHTML of some DOM node.
It’s a very long post so maybe I missed it, but does Dan ever address morphdom and its descendants? I feel like that’s a very relevant point in the design space explored in the article.
I’m curious, are you running GoodJob in the same database as the application? For smaller scale stuff this is super convenient, but I wonder if it will become a problem at higher loads.
> If you have a single page front end setup, and a "RESTful" backend
Rails really doesn't encourage this architecture, quite the opposite in fact.
> designers and users of the applications I have been building for years never want just one model on the screen.
... and this is where Rails excels. When you need to pull in some more data for a screen you just do it. Need to show the most recent reviews of a product in your e-commerce backend? It's probably as simple as:
> People get distracted by the idea of pure capability systems. See the thread above. Pure caps don't work, …
I’m one of those “distracted” people who has never gone far enough with a capabilities-based language to figure out why they don’t work.
I read a lot about E and tinkered with Pony, and it seems that the biggest barrier is bootstrapping/network effects (e.g. lack of available libraries & expertise) rather than something intrinsic to a capabilities oriented security model.
In contrast, I only just learned about Javas SecurityManager from an earlier comment on this post. Reading the documentation at https://docs.oracle.com/javase/8/docs/api/java/lang/Security... leaves me with an impression of more complexity for integrators (as you noted) and a need for vigilance at system boundaries by runtime implementors. Building on reference capabilities seems much much simpler, but maybe that’s just my lack of experience ?
> There are some conceptual and social difficulties with this kind of security, at some point I should write about them.
I guess my comment is a long way of saying: please do!
Yes, sorry for the rather pithy response, but separating out the "what changes" vs. "what doesn't" (config vs. code in your terms) is what makes these things possible.
As you also noted, doing this in plain terraform is kind of a pain, so using a tool like Hiera allows you to skip a lot of the work involved in doing it the "right" way. IMO if you're starting greenfield Pulumi (or CDK, anything that lets you use a "real" programming language) allows you to write (or consume!) that config in basically any form, instead of needing to funnel everything through a Terraform data provider.
The ruby-lsp project made by Shopify has (or had...) a rails plugin that worked this way. It adds some routes to your server during development and uses them to introspect the running process.
"you can cook better food" and "you can drastically improve your economic situation" are two very different promises (or implications) that should be held to very different standards.