On Mon, Apr 4, 2016 at 7:36 AM, John Bollinger <john.bollin...@stjude.org> wrote:
> > > On Sunday, April 3, 2016 at 8:21:46 PM UTC-5, Henrik Lindberg wrote: > > In the long run, in general, we want it to be possible to express as >> much as possible using the Puppet Language itself, and where that is not >> practical, that it is easy to integrate an implementation (written in >> c++, ruby, or whatever the logic is best written in for the target). >> > > I have kept my language biases to myself until now, but the implementation > language(s) for extension point interfaces is a technical question. If you > want to use C++ *inside* then that's your call, and I won't judge. But > C++ is not well suited for external interfaces, especially if you intend to > ship binaries instead of relying on users to build from source. This is > mostly because C++ has no compile-time encapsulation > <http://yosefk.com/c++fqa/defective.html#defect-1>, and C++ has no binary > implementation rules <http://yosefk.com/c++fqa/defective.html#defect-5>. > If you think you have trouble managing compatibility issues now, just wait > until you have to deal with third-party plugins implemented against a C++ > interface -- or better, just avoid that. > You are absolutely correct, on several counts: * C++ as a generic extension point (e.g. for 3rd party plugins) doesn't work for the reasons you point out. That is simply a technical fact about C++ and in no way specific to the Puppet ecosystem. As such, C++ as an extension point is nowhere on any plans or conversations I've ever been involved with. There seems to be some FUD around this point, so it's really important to emphasize: C++ is not an external interface point. * It's very important to distinguish language choice for core *implementation* vs language choice for *extension* points. E.g. while some folks at Puppet Labs are working on porting some of puppet's core functionality from Ruby to either C++ or Clojure, neither of those is intended (or in the case of C++, even viable) for use as an extension point language. (Though, if you want to write external facts or puppet subcommands in C++ or Clojure or Lua or Haskell, knock yourselves out: that wouldn't be an extension point language choice, that would be a language choice for an external binary that puppet runs as instructed.) > I'm inclined to agree that plugins written in the Puppet language itself > are a good target, and it seems that Ruby plugins are likely to be a fact > of life for a long time yet. > Absolutely. Ruby plugins will be around for the foreseeable future and that's a good thing. At the same time, we've introduced more options for Puppet plugins (e.g. EPP, functions in puppet) and would like to add more in the future (e.g. types in puppet). I tried to capture this direction, along with the core vs extensions notion, in an "at some point in the future" slide in my PuppetConf talk last year: https://speakerdeck.com/kylog/under-the-hood-c-plus-plus-at-puppet-labs?slide=27 In short, there's a tremendous amount of fabulous puppet module content out there, written in a mix of puppet and ruby, and we absolutely intend to emphasize backwards compatibility so that that content can be leveraged while the underlying platform becomes higher performing and more scalable. > If you want a lower-level interface as well, then you could consider C for > that interface. > I have had a few people ask about this. Honestly I think those asks were pretty idle, but yes, if there were demand we could in theory support C as an extension point language at some point in the future. That would need some serious RFC and design work, and feels quite far out to be honest. > C can integrate fairly easily with your C++ implementation, and it > provides for a more stable interface. If you want real-world cases, > consider that both Ruby and Python choose C over C++ for their native > interfaces. > Yep, totally agreed. As you stated well above, C++ isn't suitable as an external interface language. A fairly common pattern for those who want to provide an external interface to a C++-implemented library is to wrap a C interface on top of it. > > Of course, since we're now talking about the long run, these comments may > be premature. Nevertheless, I hope to put this in folks' heads so that > some thought goes into these choices when the time comes to make them, for > it's all too easy to just roll ahead with whatever seems natural. > Great comments - thanks! Kylo > > > John > > > > John > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/b241c647-cc2c-4ca8-bcbe-5839f8ecc65f%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-dev/b241c647-cc2c-4ca8-bcbe-5839f8ecc65f%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Kylo Ginsberg | k...@puppetlabs.com | irc: kylo | twitter: @kylog PuppetConf 2016 <http://2016.puppetconf.com/>, October 17-21, San Diego, California *Early Birds save $350* <https://www.eventbrite.com/e/puppetconf-2016-october-17-21-tickets-18750712887?discount=EarlyBird> - Register by June 30th -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CALsUZFHzh%3Ds7LwigiC63xQGD6fKd6QnkSWNc3QJsqP9H6XRbDw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
