Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Datomic is Free

blog.datomic.com

Post reply on HN
Print view View original

251–260 of 436 posts

Re: Datomic is Free

#251

Post by JulianWasTaken »

ithrow wrote: post #249
JulianWasTaken wrote: post #233

Earlier quoted context omitted.

I don't doubt your story of course, and I love Postgres, but comparing apples to oranges no? Datomic's killer feature is time travel. Did you simply not use that feature once you moved off Datomic (and if so why'd you pick Datomic in the first place)? Or are you using Postgres using some extension to add in?

Datomic's 'time travel' is an audit feature, not something for your application/business logic to depend on. Performance reasons make it impractical, unless you only have like 10 users and very little data.

That's certainly not how it sells and markets itself.

The first feature on benefits (and the only reason I've ever heard Datomic brought up and/or considered it myself for production workflows) is using that stuff in application workflows: https://docs.datomic.com/pro/time/filters.html#history

Could be you're saying it in fact doesn't work well performance-wise, that'd (surprise me but) certainly explain why it's not more popular -- but I think it's clear it wants you to use this as an application feature.

Re: Datomic is Free

#252

Post by ithrow »

erichocean wrote: post #165
jchw wrote: post #30

Not complaining about the actual announcement itself here: seems pretty sweet all things considered, But: the "Is it Open Source?" section should lead with "No." It's not a complicated question, and it's not a complicated answer. I think it's weird to talk about having "all the same rights" without explaining why that matters particularly (it does matter, it's just not explained much!) but it is somewhat tangential t…

Eh, it's Java bytecode and it's Apache 2. So you can patch Datomic and extend it without breaking the license.

I wonder if public benchmarks are now allowed with the binaries.

Re: Datomic is Free

#253

Post by PreachSoup »

gleenn wrote: post #193
PreachSoup wrote: post #187

Earlier quoted context omitted.

Question: What's the difference between nested oop objects (composition over inheiritance) vs maps of nested structures?

Rich Hickey has a great talk about how Objects are data structures with unique interfaces that are unnecessary complexity. He showed and example of a web server with a web request object with request headers etc etc. Doing simple things like collecting information out of that nested object structure is bespoke and harder than it should be for no real gain. If everything is a map or list or set, it becomes completely…

Most of the time, the class name is used just as a nominal type identifier. That's what we do at least

Re: Datomic is Free

#254

Post by rehevkor5 »

wwweston wrote: post #241
bvanderveen wrote: post #236

Earlier quoted context omitted.

We implemented it in Postgres with 'created_at' and 'deleted_at' columns on everything and filtering to make sure that the object 'exists' at the time the query is concerned with. Changes in relationships between objects are modeled as join tables with a boolean indicating whether the relationship is made or broken and at what time. Our data model is not large and we had a very complete test suite already, so it was…

Yeah, it seems you could be able to substitute thoughtful schema design avoiding updates/deletes for time-travel as a feature. I wonder if anyone has made a collection of reference examples implemented this way (and in general think that a substantial compendium good examples of DB schema and thinking behind them could be worthwhile).

Maybe search around on bitemporal database table modeling.

Re: Datomic is Free

#255

Post by [deleted] »

gleenn wrote: post #193
PreachSoup wrote: post #187

Earlier quoted context omitted.

Question: What's the difference between nested oop objects (composition over inheiritance) vs maps of nested structures?

Rich Hickey has a great talk about how Objects are data structures with unique interfaces that are unnecessary complexity. He showed and example of a web server with a web request object with request headers etc etc. Doing simple things like collecting information out of that nested object structure is bespoke and harder than it should be for no real gain. If everything is a map or list or set, it becomes completely…

[deleted]

Re: Datomic is Free

#256

Post by newlisp »

JulianWasTaken wrote: post #251
ithrow wrote: post #249

Earlier quoted context omitted.

Datomic's 'time travel' is an audit feature, not something for your application/business logic to depend on. Performance reasons make it impractical, unless you only have like 10 users and very little data.

That's certainly not how it sells and markets itself. The first feature on benefits (and the only reason I've ever heard Datomic brought up and/or considered it myself for production workflows) is using that stuff in application workflows: https://docs.datomic.com/pro/time/filters.html#history Could be you're saying it in fact doesn't work well performance-wise, that'd (surprise me but) certainly explain why it's not…

Welcome to sales tactics ;)

Datomic is great but as another commenter said, is good for "small-ish backoffice systems that never has to be web scale". You almost probably can rely on querying history for internal applications. I think their primary market was for companies to use it internally but they never made this clear.

Re: Datomic is Free

#257

Post by askonomm »

stonemetal12 wrote: post #99
hombre_fatal wrote: post #14

Aside, I remember HN in 2009 or so where Clojure was a daily homepage staple and Rich Hickey was putting out his talks about Clojure and code design. I watched a lot of that and used Clojure fulltime for five years. Wonder what he's up to these days.

>used Clojure fulltime for five years. How did that work out for you? Usually following a hype cycle, there is a negative hype cycle i.e. Mongo is webscale, then Mongo is a buggy mess. Clojure seemed to just fade away. Did it turn out well or are there interesting pitfalls that make it not as great as advertised?

As far as the metrics state, Clojure never faded away. It's on an upward trajectory still, albeit slowly. Perhaps it faded away in terms of "HN hype of the day".

That said, I've been (and currently am) a Clojure engineer for the past 5 years and loving it. Quite a lot of jobs out there, more and more each time I look, healthy ecosystem and friendly community. It doesn't hurt that it's the most paid programming language as well.

Re: Datomic is Free

#258

Post by ledauphin »

kaba0 wrote: post #240
gleenn wrote: post #226

Earlier quoted context omitted.

Clojure uses objects for connections and things, but POJOs are harmful IMHO because it makes manipulation and collecting data a bespoke task every time. Every time you change the data, you have to change a class to represent the JSON and the ORM class and .... this is all just data

Well, that’s what Java records are for. As for having to change the type description, that’s more of a static typing discussion, though it can be generated — having a single source of truth and generating others is imo the best approach.

Java records weren't even a gleam in the eye of James Gosling when Clojure was solving these problems at its inception.

Re: Datomic is Free

#260

Post by mschaef »

stonemetal12 wrote: post #99
hombre_fatal wrote: post #14

Aside, I remember HN in 2009 or so where Clojure was a daily homepage staple and Rich Hickey was putting out his talks about Clojure and code design. I watched a lot of that and used Clojure fulltime for five years. Wonder what he's up to these days.

>used Clojure fulltime for five years. How did that work out for you? Usually following a hype cycle, there is a negative hype cycle i.e. Mongo is webscale, then Mongo is a buggy mess. Clojure seemed to just fade away. Did it turn out well or are there interesting pitfalls that make it not as great as advertised?

I've used Clojure personally for >10 years and done a bit with it commercially along the way. (I also have a personal affection for Lisp-like languages that goes back to at least the mid-90's.)

> How did that work out for you?

For the personal projects, it's been incredibly useful. The language fits the way I think, and being built on the JVM, it has both a performant runtime and lots of access to a wide ecosystem of libraries.

The Clojure-specific ecosystem library has been accused of being stagnant. I tend to take a more charitable view. The libraries I've used have tended to be smaller in scope and more well defined in terms of feature set. This makes it easier for them to converge on a feature-complete state, and many of them have done just that. If you don't mind assembling multiple smaller libraries into the useful whole you need, this can provide a stable platform on which to build and develop expertise and higher level libraries.

For larger scale commercial work, it's a harder sell. As you've pointed out, Clojure is not hugely popular, so it's fundamentally a minority language. This can make VC's touchy about funding. This is true to the extent I'm aware of at least one organization that started moving away from Clojure for that reason.

There's also the shape of the learning curve. It can be hard to get started with Clojure because of the issues around the syntax and associated tooling. The more piecemeal aspect of the library ecosystem can then make it harder to get to hit the early successes a larger framework-oriented approach can give you out of the box. You can get there, but it at least takes more initial effort. The same is true for all the abstractive power of Clojure (and other Lisps). Abstractions are nice, but they take time to develop and the payoff is on a considerable lag. The useful rule about waiting to abstract until after you see 2 or 3 instances of a pattern means you need to at least have spent enough time to see those 2 or 3 instances (and maybe a few more) before you really start to see the payoff in your own code.

The net of all this is that it's a language that may make it more difficult to get funding, will be initially somewhat confusing to most developers, and the payoff may well be deferred to the point you don't see it before you give up (either out of frustration or due to external factors). All in all, a considerable set of headwinds.

So what does that mean? It's probably better for projects on a longer time horizon that have a team willing and able to put in extended effort to effectively use the language. (And if the team is not self-funded, good to have a funder with some ability to accept the risk of a non-conventional solution). Not saying these projects don't exist, just that they're not common enough to build a 'popular/mass-market' ecosystem on.

Post reply on HN