1. 1

    Have you considered support for remote+dynamic config? I’ve a co-developed such a thing for Java (https://github.com/irenical/jindy) but we never found a Node equivalent. In the Java ecosystem a lot of the pieces were already there, so this is basically an API and glue. If one would want to centralise configuration using Consul, etcd or what have you, what would you suggest? What about if you need to react to runtime config changes? Do you see these features as something that would make sense in HConfig? I’m really trying to avoid having to write a “jindy.js” from scratch.

    1. 1

      Hmm, I don’t know if that would make sense in HConfig. It’s more supposed to just be a parser for a language. However, it would totally be possible to build something on top of that which uses HConfig as a configuration language. Reacting to runtime config changes would probably also be up to the application or another language to implement; just parse the file again whenever you want to reload it, and do whatever application logic is necessary to incorporate the updated configuration.

      1. 1

        We use HOCON, which, used with the typesafe config jars, has wonderful support for overriding values. The idea is that each jar can have it’s own reference.conf, and then you can add a new config file with a fallback to the default. So you can read config from consul or etcd and then use it to override the default values, We use typesafe config a lot and it makes our lives a lot easier. We use a single object which contains all of the config values which we care about. This is immutable and typed. If we need to re-read (because of changes in consul), then we re-read and we have a new immutable object.

      1. 7

        Poor framework choices cause a bad development experience in any language. This is particularly prone to happen in Java because most of the “de facto standard” frameworks are rubbish. To make elegant Java projects, you have to ignore 90% of the internet. Hopefully not this comment.

        1. 10

          In my experience, to write elegant Java:

          • Learn SML, Haskell, Lisp, or at least Python. By no means should you learn idiomatic Java. If you already know it, unlearn as much as you can.
          • Use Java 8+.
          • Never use any dependency with more than a handful of public classes.
          • Never use anything which uses reflection, annotations or inversion of control.

          At this point, you’ve basically got a very verbose Python that’s screaming fast and has basic static typechecking. I honestly prefer it.

          Also, for what it’s worth, I think (though I’m sure as hell not going to trawl through Spring’s garbage fire of “documentation” to confirm) that the author didn’t have to write as much boilerplate as they actually did; there are magic annotations to autogenerate at least some of that, like the mapper and probably the DAO as well. Note that this has absolutely no impact on their point (because none of this is discoverable without dealing with the pain yourself, cf. aforementioned garbage fire).

          1. 2

            Learn SML, Haskell, Lisp, or at least Python. By no means should you learn idiomatic Java. If you already know it, unlearn as much as you can.

            This gave me pause. So you’re advocating for people writing code that will be all but unmaintainable by the rest of the team in the name of elegance?

            I agree that learning other programming languages can make you a stronger programmer in your language of choice, but this strikes me as really unfortunate hyperbole.

            1. 9

              Given the specific list “SML, Haskell, Lisp, or at least Python”, I think what whbboyd’s actually going for here is “get comfortable writing simple programs that mostly pass values around, preferring simple uses of generics (i.e. parametric polymorphism¹) or interfaces (i.e. duck typing²) over doing unpleasant stuff with deep inheritance hierarchies, and not being scared of lambdas”, because that’s roughly the intersection (not union) of those PLs’ feature sets.

              (¹ fancy word for “when you put a thing into a list-of-Ducks, the thing you put in is a Duck, not an arbitrary Object” and “when you take a thing out of a list-of-Ducks, you get a Duck back, not a mysterious Object reference that has to be cast to Duck and which might throw an exception when you do that.)

              (² non-fancy word for typeclasses ^_~)

              This is an argument for writing less-complicated Java. I’d expect the resulting programs to be more comprehensible, not less, and they might actually look simplistic.

              This is not an argument for rewriting all your Java programs with the control flow implemented as Church-encoded data structures. That would be wildly incomprehensible.

              1. 4

                Precisely this. Java’s typical idioms are not conducive to writing elegant code, so learning better idioms instead will put you in a better place, and shouldn’t significantly affect the ability of competent teammates to understand and maintain your code.

              2. 4

                I agree that there is some hyperbole here, but I also do think the above commenter has a point. Java can be nice if you subtract the cultural gunk that has built up around “patterns”. The jOOQ blog covered it well, I think.

          1. 4

            Seeing as I’m up this late only because I’m dealing with mitigating Kafka queue lag due to our big data team performing excessive complex queries on our OpenTSDB, this post couldn’t come across my screen at a better time, thanks! I’ll be interested in stress testing this soon. Has anyone here used this in a high-scale high-availability production environment yet?

            1. 2

              Probably not as this seems to be in development still. You can read at the end of the document: “A clustered version is in private beta with select customers.” Doesn’t sound like production-ready. I would also like to have read something about cluster resizing and resilience to node failure, which are usually giant pain points in sharded data systems. Either way this seems interesting and I’ll be looking for excuses to try it out.

              1. 2

                Yep, Hadoop node failure and replication lag is what caused our problem last night.