Hacker News Reader

Comment by hannofcart | Hacker News Reader

> What happens when we run an engineering organization by constraining the number of tools in our toolbox “for the greater good”?

I read this and think: ok, I guess this is going to be one of those posts advocating for boring tech (i.e just use Java everywhere).

> the answer is quite short... Clojure for production services, Kafka for asynchronous communication, Datomic as our database for high value business data, Scala for our analytical environment, and Flutter for our mobile app

Holy non-canonical technology choices, Batman!

View on HN

For longevity I'd put my money on Clojure over Flutter or Kafka (which are younger techs too). And of course Datomic now is effectively in-house software for Nubank and has been conceptually validated besides on its own merits, by the number of kindred DBs around[1].

IME Clojure is boring in a good way vs Java, as the pace of language evolution is slower, the language is simpler, and simplicity is more highly appreciated in the culture of the ecosystem.

[1] See first 5 in https://github.com/razum2um/awesome-clojure#database

Nubank is known clojure shop similar to how Jane Street is an OCaml shop.

Both are great examples contradicting conventional "wisdom".

Kafka is very much a boring Java technology, and one that's pretty bad as well.

I disagree with all three claims.

Voting -1 might have been a better response; alternatively you might have phrased things in a way that requests an answer, or at least articulate your argument.

The Kafka being Java one is the most difficult one to refute I'd say.

Would you recommend something less boring for scale?

Aeron maybe, also Java-friendly.

Aeron is for a pretty different use case. Kafka is optimized for volume batches, Aeron is for very low latency transactional. I wouldn't use one in place of the other. They have very different operational requirements too.

Both are technologies to transport messages over the network in a topic-oriented producer/consumer fashion, and both provide the ability to record and replay from a specific point.

I don't think that Kafka is bad per se, it's just that it's often used as a message queue which it doesn't seem optimised for. Half of the stuff you need for a proper MQ (e.g. DLT handling) isn't provided by Kafka proper (although interestingly it is provided by spring-kafka - but that locks you into that tech and just means another abstraction which makes things harder to understand). Also, Kafka doesn't really deal well with long-running consumers, something that might be quite necessary for many async systems.

Love these choices? Wait two years and read again.

More seriously, this content should be read and evaluated divorced from the reader's personal affection for specific tools, otherwise what value did this writeup provide if your opinion was set from the get go?

this content was written 3 years ago :-D

…and the core tech choices are now over 10 years old.

> 30 Oct, 20

...

Reply on news.ycombinator.com