Hacker News new | past | comments | ask | show | jobs | submit login
Trapperkeeper is a new Clojure framework for long-running applications, services (puppetlabs.com)
229 points by lazyloop on Apr 13, 2014 | hide | past | favorite | 94 comments

Perhaps I've drunk too much of the Unix and Heroku 12-factor kool-aid, but I'm skeptical of the usefulness of some of TrapperKeeper's features:

> a way to cohesively manage the lifecycle of the various components making up an application

I'd need a more specific example to understand exactly what this is talking about, but shouldn't each component with an independent life cycle be a Unix process?

> a common logging mechanism that wouldn't need to be set up and configured by each component

Just log to stderr. Don't even bother including timestamps; an external utility like svlogd can do that (and rotate the logs too).

> a web server flexible enough to load multiple web apps

This one in particular strikes me as an anti-feature, common in JVM environments. In the Heroku 12-factor approach, each app embeds a web server (like Jetty), rather than the web server containing apps. Then you use a front-end proxy like HAProxy or nginx to route requests to multiple apps.

> and to support a rich set of options for configuring SSL

That's the job of the front-end proxy, or maybe even a special-purpose SSL termination daemon such as stud.

I'm struggling to find a way to say this that doesn't come across as either bitchy or trolling, but none of this is exactly surprising coming from Puppet Labs. Puppet is hardly a poster child for simplicity. The people behind Puppet are smart, and very capable implementers, but simplicity and modularity have never been goals of theirs.

Debugging: You can step from one service into another in the same debugging sesssion.

Profiling: Analyse one snapshot to find the main bottleneck across a number of services.

Performance, security etc. etc. Basically the ability to use a lot of the things that make the JVM powerful and save you time and money. (Not only that but the things that make clojure powerful like its concurrency mechanisms etc across services)

Besides one process is often simpler than many. Interprocess communication suffers from some of the "Fallacies of Distributed Computing."

If you like to keep your UNIX process mental model just think of JVM threads as processes.

(One other thing: Running services in multiple JVMs uses more heap than multiple services in one)

> One other thing: Running services in multiple JVMs uses more heap than multiple services in one

That sounds like a failure of the JVM. You are also putting multiple independent services in the same fault domain.

> That sounds like a failure of the JVM.

That is a natural feature of garbage collection. The asymptotic complexity of copying garbage collection is O(complexity of live object graph)/(total available heap size). That is, having more heap available makes it consume less computational resources, up to an including making many real loads have near-zero garbage collection cost if the heap is large enough. Having three individual processes share a heap can make them actually do less work than if they each had a static third.

Modern operating systems are not set up to exploit this. There has actually been some work done on Linux user space reclaim for it but it's not yet usable. Until there is a way to tell the kernel that you want to use every last free byte on the machine if possible but can likely free most of it when any other process needs it, to make best use of the machine you will have to roll your own in userspace.

> You are also putting multiple independent services in the same fault domain.

In practice, unless you are doing a few stupid things (which most places don't let you do), it's extremely uncommon for whole JVM processes to go down. With a bit of work you can make almost all faults only take out individual tasks.

Not that I personally like JVM. I'd much prefer to do work on the actual OS, not wrap it all and pretend it doesn't exist. However, the people who build and use it are not idiots -- there is an actual method to their madness.

Actually, there is already (proprietary) multitenancy support for the jvm that provide full isolation (minus JNI calls). See http://www.ibm.com/developerworks/library/j-multitenant-java... .

IIRC I saw some talks about introducing it in java9.

I agree with your points to a certain extent, but if you understand things from a Java mindset the features make sense.

The thing to understand is that, much like Smalltalk, the JVM is its own world. The underlying OS is only there to bootstrap the JVM, there is no Unix underneath. So every time you think they would do better to use some feature of the underlying OS you are breaking with the Java way of doing things.

a Java mindset

I'd just like to point out that this is not the only Java mindset. It's certainly true that Java has a long and horrible tradition of people thinking that everything and the kitchen sink should go in the app server (which can then be managed with a SOAP interface!), but this is not intrinsic to Java, and it's not the only way to work with Java. Some of us are actually pretty keen on the 12 factor approach.

I appreciate that many JVM proponents treat the JVM as a world to itself. I guess the JVM community is big enough that it can afford to be that insular; that just makes it seem all the more foreign to the rest of us. Still, it seems to me that pragmatic developers can take advantage of the good parts of the JVM while rejecting the NIH syndrome. Puppet Labs, in particular, can rely on Unix being the OS underneath.

This is a Clojure framework though, so the Java mindset doesn't apply.

Heroku's architecture makes sense when you bill per process and primarily target a slow runtime like MRI. If you want low latency you want as little as possible between your HTTP endpoint and the actual processing. You don't need HAProxy, SSL termination daemons, and so on when the JVM has the grunt to do this itself, and you end up lower latency as a bonus. It is also to my mind a simpler system. All things being equal I would rather configure and monitor one system than a zillion.

One minor point of clarification: this framework is not intended to prescribe that we (Puppet Labs) or anyone else should move all of their services into a giant monolothic process, a la JavaEE. In fact, that's one of the main reasons we decided to build the framework rather than use an existing solution.

Trapperkeeper is simply intended to give us the flexibility to decide how to bundle different services together. If we have 2 or 3 tiny web services that can benefit from some shared state and are lightweight enough that they don't really warrant running a separate web server for each one, now we can choose to deploy them that way. But, absolutely, we can still run more than one instance of this framework on the same machine, to reap the benefits of truly isolated OS processes in cases where that is appropriate.

Another minor point to highlight is that, at Puppet Labs, we're building on-premise software that our customers install and administer on their own networks. We're not building SaaS products that we administer ourselves. This means that we need to be able to support a wider range of deployment configurations, so that we can tailor a particular installation to the needs of the particular user who is installing it. For some users, they may have enough traffic to warrant peeling out every individual service to its own process and distributing them across many nodes. For other users, they may have a very tiny network where it is perfectly sufficient (and much simpler) to run everything in a small number of processes on a single node. The new framework is all about giving us the ability to make those choices more dynamically--not about prescribing a particular deployment model to all users.

Also--we do indeed use the embedded Jetty model for serving web apps. It's entirely up to a user of the framework to decide how many apps they'd like to run in each embedded Jetty instance.

This is very cool, especially that they took the time to write up a series of tutorials for "TrapperKeeper" which is really what the post is announcing: https://github.com/puppetlabs/trapperkeeper

It looks very quick and easy to spin up a service which has all benefits and performance of running on clojure / jvm. Combining this with a website front end using Clojurescript looks like it could be a sweet spot.

I've been looking at Clojure a lot lately. It's a really cool looking language that appears pretty powerful. As an outsider I'd really like to see some more "ramping up" kind of posts to get my head around all the basics of the tooling (leiningen) and how to actually structure a program.

Clojure is a great language that has an achilles heel right now. The community doesn't treat the lack of learning resources / documentation as a serious problem. I've heard prominent members of the community say this exactly, "Clojure is such a great language that the lack of learning resources doesn't constitute a real problem in the grand scheme of things." I know what they're trying to communicate, but to beginners it comes off like "We've created the greatest thing since sliced bread - but we're not going to tell you how to use it - and if you would just take our word for it and blindly follow with no guidance you'll be a better developer". Which is really frustrating to hear, because it's like this thing seems so great, and smart people are all about it, but the only way to learn it is absolute misery. It's a tough perspective to have when you're only a couple years in to your dev career.

Clojure gives you massive benefits, but god it's a brutal road to competence. Things that should be simple like setting up a web server, adding user authentication, making JSON API's, trying to find the best libraries, it's all a time-consuming trudge through pain and suffering. And after some months when you get somewhat competent with the language, you realize that in order to get the full power of Clojure you need to not only learn the Clojure language, but the entire Clojure ecosystem. So you need Clojure, Clojurescript, Datomic, Edn, Core.async etc... And each piece of that puzzle is equally horribly documented and has no beginner resources so you have to struggle at each point in the process, praying to god that it's ultimately worth it.

It's frustrating as hell, but it really is rewarding, because you have to learn every little piece at a low-level to ever make anything happen. There's no Rails-like framework that makes things 'just-work' waiting for you. I find that using Clojure is awesome, but learning Clojure is awful. I'm hoping to play a role in fixing that second part pretty soon, but really wish the community would be more active in helping to remedy the problem. The first step is admitting that the problem exists and it matters, and not sure that we're there yet.

[context: I work at Cognitect on Clojure and community efforts]

I'll start by saying that documentation, examples, getting started, etc could be better and efforts are ongoing to improve all of those to various degrees.

However, there are substantial and rapidly growing resources (http://clojure.org/getting_started) for learning Clojure and other parts of the ecosystem. Some of the more recent beginner resources I'd recommend are "Clojure for the Brave and True" (http://www.braveclojure.com/) and Kyle Kingsbury's "Clojure from the ground up" series (http://aphyr.com/posts/301-clojure-from-the-ground-up-welcom...). There are also many good Clojure books - I'd recommend any of them.

In the web area, the philosophy is different than other languages and it is evolving rapidly (especially on the client side). Luminus (http://www.luminusweb.net/) is a good effort to provide a reasonable set of defaults that tie together the various Clojure web libraries.

So yes, it could be better. However, there are significant resources now and gaps continue to be filled.

One thing I've always found bizarre is that ClojureDocs hasn't been updated since 1.3. I know it isn't an official resource so you may not be able to do anything about it, but it's always at the top of Google's results.

I am working on that. :)

What are your thoughts on Neal Ford and Stu's Clojure from inside out series?

I haven't watched it but they are both excellent teachers with thorough knowledge of Clojure, so I can confidently predict that it's high quality.

I've been emailing one of your colleagues about working at cognitect - any chance you could help me get inducted into that software illuminati?

I had the opposite experience. It's pretty obvious how to do anything in Clojure. I don't need to hunt down magical incantations to use libraries like I had to in Ruby.

I started Clojure for web development. Once I found out about the Compojure template, everything else was just a stone's throw away.

    $ lein new compojure myapp
    $ cd myapp
    $ lein ring server-headless
    Server started on port 3000
I wager the average HN reader could run with that.

    > There's no Rails-like framework that makes things
    > 'just-work' waiting for you.
That's actually what stifles the productivity of Rails projects I've worked on. It's why I started looking at other solutions and why the simplicity of Clojure pulled me over.

    rails g devise:install
    rails g devise user
    rails g devise:views
Nobody really knows what just happened. Things kinda work til the answers to your questions can't be pasted from Devise's wiki anymore.

    > because you have to learn every little piece at a low-level to 
    > ever make anything happen. 
Maybe we have different things in mind, here. The alternative to this in my experience is an application where nobody actually knows, for example, what's being put into the cookie, when it's put into the cookie, what part of the session is serialized in the DB, if the cookie is signed, etc.

At least that's how it was at all the Rails projects I worked on.

https://github.com/ring-clojure/ring/wiki was refreshing. It turns out that managing your own session/cookie/authentication lifecycle in your own application code is easy. And it turns out that these "it just works" generators doesn't actually save any time because when you want to make trivial changes to them, you have to credentialize in yet another abstraction.

I haven't found that true, especially compared to any other language at this stage of development (complicated by the lack of the modern Internet, but I'm thinking especially about C++).

E.g. I'm helping someone with a web application and I've found no need whatsoever for Datomic (PostgreSQL + korma is just fine), I gather that means Edn is irrelevant, Core.async appears to be less than a year old, so I'm not surprised it might be lacking in documentation, and I don't see it as critical for a lot of applications, including mine. Clojurescript: we'll see, I do engines, and would prefer to continue to have others do almost all of that side of things.

Granted, it did take me a while to find and get up to speed on a set of libraries to do the web app I'm working on (mostly CRUD with some non-real time backend external communications), but it's been relatively pain free. I started with a recommended set, then as I found I needed to do something new, like JSON, I found a good library in a few minutes with Google and didn't find it at all difficult to fold it in.

Did change after a bit my form validation library to Red Tape, which modulo one detail (limited data available to form level cleaners (functions that act on more than one item in the form)) is superb.

And "superb" in general describes my experience doing all this. And I fully expect documentation and other learning resources to continue to improve as Clojure gets greater acceptance.

(Disclaimer: I'm an old Lisp and Scheme hand, e.g. not someone who had to learn anything conceptually new to use loop and recur. I could see the above plus learning basic functional Lisp concepts to be brutal if you're new to everything.

On the other hand, I can remember the days when learning MACLisp required reading an old David Moon manual and then the archives of a mailing list following it's publication; thank goodness there was a really great Lisp Machine Lisp manual and they were just starting to be somewhat available to use and learn on.)

I attended the Clojure/West conference about 3 weeks ago, and the sentiments are valid. But also, the Clojure community is starting to focus on the beginner learning curve aspects. Right now, there's a ClojureBridge effort (based on RailsBridge) to increase the diversity in the community. And it's been generating interest among people even outside the under-represented demographics. I'll be co-teaching the ClojureBridge SF session in 3 weeks, ping me if you're interested in future Clojure workshops (given the huge amount of interest, there definitely will be more!).

I think there's going to be some efforts in the near future in the Clojure community to tackle the low-hanging fruit of improving beginners' path to mastery.

If you come from OOP school of programming and the Algol/C++/Java style of syntax (true of many popular languages these days), then Clojure does require a re-think of the programming paradigm. But it truly is worth it -- it will make you a better programmer -- and the community is friendly, smart, and always learning and improving. It's certainly a language that I think that I will grow as a programmer by being with.

I think you might be overstating the syntax switching problems. The syntax of earlier Lisps is insanely simple, and Clojure only a little more so.

I base this in part on the very popular Python language's use of white space, which to a seasoned Lisper looks very familiar.

As for the focus on "diversity", I submit it might be misplaced at the moment, especially to the extent AlwaysBCoding's complaints are valid. To the extent Clojure is not making the sale to a target audience that's already 98%" heteronormative eeeevil white male (https://news.ycombinator.com/item?id=7581226), how likely are you to entice those outside that demographic? In fact, if you view Clojure as an experiment that may fail, are you doing them a favor by evangelizing it to them?

(I'd argue yes, since it's probably one of the easiest functional programming (FP) languages to learn, and it really helps to have FP in your toolkit. But I'd argue SICP or something gentler with multipardigm Scheme would be a better approach if you're just trying to accomplish that sort of thing.)

The first two ClojureBridge (http://clojurebridge.org) workshops sold out quickly and many more cities are working on events in the coming months. In addition, 100s of people have signed up to help or attend on the mailing list. There is clearly demand in diverse communities to learn programming via Clojure.

I don't think any serious student should expect to learn only one language. Clojure can teach concepts that any learner will find valuable in applying to other languages. In particular, I think that clear separation of values, identity, and state avoids many kinds of complication in learning how to program that are introduced early with other languages.

I am definitely not the best developer you will ever find, however I learn clojure by myself and it wasn't so hard...

(This is exactly the behaviour you are point as wrong, and I know it.)

The resource I had (back in the 2011/2012) were just a book, `The joy of Clojure`, my background was some C and mostly python, nothing about FP.

I don't see any of ClojureScript, Edn (???) nor core.whatever so fundamental... Those are just other tools, you can write any webserver using the old JS, JSON and any other lib you may need... (Anyway you should not try to learn clojure building web server, are the less clojure-y piece of software you can build IMHO)

IMHO, the biggest problem is the paradigm shift that most developer need to have in order of learn clojure.

Indeed. Learning functional programming in any language is a major jump for those of us (pretty much all of us?) who started out with imperative languages. It's ultimately very rewarding, but plenty of work in addition to mind stretching.

Then again you probably should have listened to all those people telling you to do The Structure and Interpretation of Computer Programs (SICP/6.001) ^_^, I merely lucked out to be at the edge of the community that created it, so it sort of fell into my lap, with strong recommendations that "this is revealed truth" as I like to put it.

I catch up on the SICP :)

To give but one example, if you're having any trouble with loop/recur, do the exercises on recursive functions that implement iteration without stack growth through tail recursion (the latter a feature that's unfortunately not available in the JVM; the flip side is that recur isn't going to blow your stack).

In the last couple of weeks I had to write a bunch of those in Clojure for the first time "in anger" (for real), and that part of it was trivial because of the SCIP I'd done in the early '80s. Learning that and pounding in my head for the first time was a bit hard, but well worth it, back then and of course now.

I am the developer of HiveMind (crudzilla.com), it is a web app platform which supports Clojure...it does have a middleware which is language independent, meaning you can use Clojure for your logic and tap into the middle-ware for things like DB interaction, email and JSON based application configuration...etc

You can find a quick installation guide here: http://blog.crudzilla.com/2014/04/hivemind-on-digital-ocean-...

Here's a screencast showing usage of Clojure, it requires no additional setup besides the installation guide above: http://crudzilla.com/assets/img/info-graphics/lang-demo.gif

Let me make a suggestion - the next person you convince to start working with clojure ... hold their hand through the process and make notes of everything you had to tell them about (because they couldn't find it in the docs) ... then at the very least publish those notes.

One of the big problems is that it's -really- hard to go back and explain this stuff once you're already an expert, and I metaphorically burts into tears at your comment because if you'd documented all the things you had to learn the hard way as you went, you'd probably've gone a noticeable way towards fixing the problem you describe.

Note: I'm not, at all, trying to criticise you for not doing so. I'm just saying that if you could arrange for this to happen as you mentor somebody else it would be really really awesome :)

> Clojure is a great language that has an achilles heel right now.

The other thing is that you cannot learn Clojure without learning Java, despite various claims; the atrocious error messages are just the tip of the iceberg there (and I say this as a professional Java developer).

Embracing the host (the JVM and Java) provides tremendous leverage in tooling, performance, and reach but has the corresponding tradeoffs of leaking that host environment throughout various parts of the stack. This is just something to accept and manage - the compromise is made.

I personally do not think the error messages are "atrocious". Some error messages are confusing or lack context. There are many tickets in progress to improve those and they continue to get better over time. This is an area we continue to work on within the language.

I'd say that might be moderated if you're got a good grounding in Lisp. I've been able to get a good distance basically learned nothing more about Java that what it took from C++ ... but that knowledge I brought to the table might enough to satisfy your claim in essence.

The community doesn't treat the lack of learning resources / documentation as a serious problem.

This is what drove me back to Haskell from Clojure. Haskell is miles ahead in documentation, references, tutorials and tooling. Tools like Hoogle are manna from heaven for beginners and experienced developers alike. Couple that with the self-documenting aspect of types and even undocumented Haskell libraries are grokkable in a reasonable amount of time.

While this has no bearing on anything you or anyone else should do today, it's worth noting Haskell is 24 years old, Clojure 9. I'd be astonished if Haskell wasn't miles ahead on all that you mention.

That may be so, but Haskell went through a very long gestation period while Clojure really hit the ground running. The Haskell as we know it today (from the revised Haskell 98 report) didn't come around until early 2003.

If you don't mind a longer journey to learning Clojure (works for Scala also): as you learn Clojure from online tutorials or books, also spend some time learning a bit about Haskell because so many ideas behind Clojure (and Scala) come from Haskell.

You can follow planet clojure [1] on twitter[2] or even facebook[3].

[1]: http://planet.clojure.in/

[2]: https://twitter.com/planetclojure

[3]: https://www.facebook.com/clojurian

Aphyr's Clojure from the ground up [1] series is the best place to start in my opinion.

[1]: http://aphyr.com/tags/Clojure-from-the-ground-up

This course on pluralsight wasn't half bad and covers a lot of a basics.

I knew how clojure felt and behaved, but IMHO you still have to memorize most of the core library, or most code will look confusing.


I find http://clojure.org/cheatsheet to be a great help in getting an overview of what's in the core library.

Yes the cheat sheet is great once you 'have a foot in the door', so to speak.

For beginners, getting familiar with namespaces in the REPL quickly is key, if you're trying to load a sample of code froma file.

Also another gotcha is multiple arity functions which I haven't seen before (in a dynamically typed language).

We have been using clojure for 2 years for testing web apps in our q/a team.

My journey looked ~like this:

1) Managed to get counter-clockwise working, played around with http://tryclj.com/, solved most of the http://clojurekoans.com/, and first ~15 of 99 functional problems that float around the web.

2) what helped, that I have already gone through a course of haskell while undergrad, so functional paradigms weren't that foreign :-) (immutability, laziness, partial application, e.t.c), so if you want to give it a try, you can look at Learn You a Haskell :P

3) we have since moved to python, and when I am sad, I try to write my code without loops, but using (for in) generator for everything, pretending I am still using lisp :P

4) clojuredocs.org/clojure_core/ were quite helpfull but after a year, clojure 1.5 was already out, and lots of functions recieved updated counterparts, so I spent quite a lot of time reading their sources ...

I have ample Java experience and had been using JavaScript and Node for three years now. I have spend quite a lot of time programming in Clojure with just toy examples and am building a simple game to get a handle on it from a more practical standpoint.

That said I too still can't figure out how to use leiningen and it seems clunky and slow. It's also easy to find examples that don't work. I'm not sure if getting it to work with as little hassle as npm would help it's growth, but seems like it couldn't hurt.

Please open a bug report in the Leiningen issue tracker if the problems you encountered came from the official documentation.

I've also released an opensource tool called TrapperKeeper which is for storing and displaying SNMP traps. We use it at Dropbox to turn SNMP traps into stateful alerts so that they can be polled by monitoring services. We haven't really announced it publicly because I want to finish writing up docs but it's been public on Github for about a month.


So you both are re-appropriating someone else's trademark.

One is Python, one is Clojure. Different namespaces; no collision.

Given both are in the field of Sysadmin/Operations, I can definitely see there being confusion.

A talk by Rich Hickey (creator of Clojure) about what sets Clojure apart from the usual object oriented languages, concurrency-wise: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...

I've tried Clojure for a while, but it didn't stick. It's probably the whole Lisp specific approach being the reason why Lisp never really took off as a main stream language. I've tried Scala after that and stayed with it since. Besides all the good points, Scala has Typesafe behind it - a solid stack/platform that (to best of my knowledge) Clojure doesn't have.

I've managed to do the opposite: Scala didn't stick, Clojure did. I guess there's some subjective reason why or why not Clojure/Scala would stick with someone.

However, it's false that Clojure doesn't have a company behind it: Cognitect is certainly backing up Clojure by developing ClojureScript and Clojure itself, Clojure consulting, the Datomic database and the Pedestal "framework".

Speaking of Datomic, are there any alternatives that are completely free?

Datomic has two free editions - Datomic Free and Datomic Pro Starter. http://www.datomic.com/pricing.html

I know about those, but the key word in my post was completely.

In what way are the free editions not free enough for you? (serious question, not trolling)

I'm guessing he means the GPL sense of free as in freedom, not free as in beer?

First of all, you haven't indicated any problems with Clojure - just a circular argument about lisp.

Second, Typesafe is a tiny company, and the most prolific committer to the Scala compiler just quit - not just Typesafe, but Scala altogether. Doesn't seem rock solid to me.

Clojure has several companies behind it.

> Second, Typesafe is a tiny company, and the most prolific committer to the Scala compiler just quit - not just Typesafe, but Scala altogether. Doesn't seem rock solid to me.

Paul Phillips did NOT quit Scala altogether: https://github.com/paulp?tab=activity

This is a surprising bit of FUD that has taken hold amongst gleeful Scala haters.

In all fairness paulp has been bashing the shizazz out of Scala since his departure.

And yes, he's still involved, but far less so than before when he was working full-time on the compiler at TypeSafe.

On the plus side, Dotty, the new "simplified" Scala compiler, is in the works and collections library will likely be overhauled in the process.

as for Clojure, typed Clojure looks interesting, but otherwise the little rascal Haskell is my Scala escape hatch for the time being.

I'm not a scala hater. I've used it in production, and produced more than one open source library, and attended scala conferences at my own expense.

I'm simply pointing out that it doesn't have a rock solid base.

I would like to use scala more, but I found clojure easier to use and equally powerful in practice.

That is just a plain rude non-argument that smears Lisp because you didn't like clojure.

I don't like clojure either, but it has nothing to do with its Lispy-ness.

I don't think it's that rude: He's stating a preference.

There are many reasons to not be fond of a language. Clojure is in the middle of two worlds: It's not as pure as a real lisp, and yet it still has all of lisp's syntactic sensibilities.

Some people dislike it for one reason, other dislike it for the other. Both reasons are quite valid, but I'd bet that reading like a lisp is the most popular reason.

My personal opinion is that if Lisp's approach to syntax was a winner, it'd have won a decade or two ago. But that doesn't mean other opinions are not valid.

And again, it's not that I don't appreciate Lisp: Many Lisp features have been added into members of the Algol family over the years, and it has made them better.

A good counter argument to the Lisp syntax issue was made by our host in his "Beating the Averages" essay: http://paulgraham.com/avg.html (jump down to the The Blub Paradox section if you wish).

Trapper Keeper is a long-established brand name for a type of loose-leaf binder. I might expect a challenge on the name by Mead.

Unless Puppet Labs gets into the business of office/school supplies, I don't. Trademark protection is limited by the type of product, which is why "Apple" the computer company and "Apple" the Beatles record label were able to coexist (mostly) peacefully...until Apple Computer released a music player and entered the music business.

I'm going to extend myself way into pure speculation IANAL-land, but I'd guess that it depends on how common the term is and consumer confusion over similar use of the term in another context.

Sure, "apple" can't be protected everywhere in all contexts, just like "windows" can't be protected everywhere in all contexts... but what about naming your erectile dysfunction company "Microsoft"?

That's a word used as a specific name, not a commonly used word just being used as a name for a company in a different market. It would be pretty obvious that you're leveraging the popularity and consumer brand confusion of Microsoft.

In addition to the principle Karunamon mentioned, made up names have greater protection than words in common usage. Microsoft isn't as exotic as Xerox and Kodak, deliberately completely made up, but it still gets a greater degree of protection than, say, Apple.

Well, karunamon seems to be disagreeing with me where you are agreeing with me. Any further clarification would be interesting. Thanks.

In everything I've ever done or been involved with in startups, I'm not sure anything besides people was more complicated than trademark law.

Unfortunately, my Amazon search and Google fu isn't good enough to find the book I learned most of this from, but if you're really interested in this, it requires a book level and length treatment. E.g. did you known Owens Corning has a mark regarding the color pink? (Only, or at least originally in the context of insulation.)

In between, I'm not sure, but try the usual suspects like Wikipedia: https://en.wikipedia.org/wiki/Trademark

That is a new one on me. I guess it makes sense though.. along those same lines, UPS has a trademark on a very specific shade of brown (hex 644117).

Nobody's going to go looking for paper organizers and end up on a programming website or vice versa.

Unless they Google it, you mean?

Edit: right now Googling "trapper keeper" brings up the Mead product. That could change if this product gets sufficient Google juice. I can't imagine that Mead would be happy about that.

Mead has annual revenues of $6 billion, so they could hire enough lawyers to make life plenty miserable, even if they didn't wind up winning in the end.

Yeah, the name is intentionally in reference to that. It's playing with the idea that the framework binds everything together, including Ring.

Because of all the great benefits of centralized accounting of our infrastructure and exported resources we started using PuppetDB when it was in its relative infancy. We did make the mistake early on of using the built in DB backend instead of the Postgres.

When I looked at migration strategies there wasn't a real migration tool available. To interact with PuppetDB I ended up learing a bit of clojure and rollng my own tool, the built in REPL helped wonders with this (granted it was only enough to accomplish this task and haven't had a chance to touch Closure since).

Only kept getting irritated by the startup time which I don't know if it can be attributed to the JVM, Closure or PuppetDB itself.

Does anyone else see dedication to a single language as a flaw? When I read "X is a Y language company" all I can think is "that company has a long ways to go." I imagine the people or person there, having found their favorite pet language and some political energy, forcing it upon everyone else and I feel angry. I get recruiter emails "looking for a Java developer" and have to ignore them. The companies just don't get it. Language Y is not going to fit all needs and cases except for very, very small problems. A company dedicated to one language is like a Popsicle with dirt all over it.

I agree with you but I also believe there needs to be limits. I like Google's strategy of N approved languages.

From an operational perspective there's too much overhead to effectively running any language in a production environment.

From a maintenance perspective you want to have common skill sets between a large intersection of employees so you're not the only person doing bug fixes on a system.

There needs to be a balance for sure.

Good points. I took over management of a software development group that had a four server commercial product that was dependent upon having developers knowledgeable in all of the following: Windows, Linux, MSSQL, PostgreSQL, MySQL, C++, C, Java, C#, PHP, Perl, Bash, and Javascript.

The development team was very siloed. Nobody could work on anyone else's code, not even a little bit.

When a new developer approached me with a module that he had written in Jython, I almost lost it.

Not sure where you're getting this. The article says they currently do a lot of Ruby work, and they're moving to Clojure for most new back-end projects.

It also talks about how Trapperkeeper works with Clojure, JRuby and Java modules.

You may well be right about single language companies, but I'm not seeing any evidence that Puppet Labs is one of them.

CircleCI is a Clojure company from day one, so there was no need to force it on people. We've found a lot of advantages from this, not just on the code side but also from recruiting.

One problem we've had is that our frontend isn't clojure/clojurescript (its coffeescript+haml+knockout). In theory that means its easier to find frontend developers and designers. In practice it has meant creating a frontend/backend division where the backenders in particular don't like to work on the frontend. We testing out whether a move to clojurescript (and hence being a truly one-language company) will solve that.

Your comments apply to the HN link text, not the article or headline.

Puppet Labs isn't a single language company.

Yes, the submitter broke the HN guidelines by editorializing the title. On the other hand, the article's official title is uninformative. So I replaced it with the sentence from the article that most seems to describe its content (shortened to fit 80 chars). If anyone can suggest a better title, I'll change it again.

Not sure if you're the one who changed it, but the " Trapperkeeper is a new Clojure framework [...]" title works fine and is much less misleading imho.

As a clojure-n00b and a Puppet expert (ahum), this triggered me to do a bit of research and write down my thoughts: http://www.olindata.com/blog/2014/04/clojure-outsiders-inves...

Not a big shocker. Last time I spoke with Luke, he mentioned client agents (facter, puppet) might eventually need to be non-Ruby compiled binaries.

I'm still trying to figure out how to allocate my attention between Clojure and Scala, and this just rebalanced the situation (I had been leaning toward the latter).

I do question their conclusions about OSGi though - it seems like a good fit for their case despite the complexity. Apache Felix is particularly nice to work with.

Scala is static typed, clojure is not - that makes Scala faster in many cases. Scala is also more widely used and adopted by quite a few major companies - http://en.wikipedia.org/wiki/Scala_%28programming_language%2...

Maybe I'll actually use Puppet now. Very cool news.

This is very disappointing.

Given how often 0-day vulnerabilities are discovered in the Java ecosystem I can't see how this is a good choice for a critical piece of infrastructure.

We love using puppet, but one big issue we have is it's lack of consistency, a big part of that is the fact that theres Puppet, Ruby, ERB syntax and ideologies and now you also have thrown Java in the mix?!

When we saw this news several people in our team have already started looking at alternatives.

The security concerns of in-browser java and java on a server are completely different. I rarely if ever see security problems for servers running on the jvm. Almost all problems are with applets.

To be clear: these changes should be totally invisible to most or all of our end users. We'll still be packaging our server-side applications as rpms/debs/etc., and none of the client-side tools are changing at all as a result of this. So you won't need to learn any new syntax. If you're using PuppetDB, then you're already using this new technology stack; we're just making it more modular so that we can re-use it in other places.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact