ryanbrush

It seems like a stretch to classify Julia as Object Oriented. It has types and record structures, but these aren't strongly coupled to functions like you'd see in most OO-style approaches. It also doesn't encourage hiding data behind a bunch of "accessor" methods on objects.

There also isn't OO-style inheritance and polymorphism. Julia's multi dispatch reminds me most of Clojure's protocols, which is a great feature. It achieves polymorphic behavior of functions without having to do ugly things to the objects. That Julia can make this fast and ubiquitous in the language is pretty awesome.

I'm also new to Julia, but I really like the above design decisions, among others features.

Were any issues logged, or these problems otherwise addressed, in the ten+ months since this was posted?

I wasn't able to find anything with some quick searches but hopefully others on this thread are more familiar with these projects.

I believe the ability to configure this behavior is being tracked at the link below. It seems like it's a switch between consistency and availability. By default Kafka prefers availability, and the possible inconsistency results in data loss (because Kafka just discards some inconsistent data it can't resolve). But the JIRA linked below should make that behavior optional, so if a majority of machines fail the cluster will become unavailable rather than inconsistent.

https://issues.apache.org/jira/browse/KAFKA-1028

Whether through Datomic or something else, it seems like some version of "database-as-a-value" (as described by Rich Hickey) is bound to happen. We're keeping immutable version histories of as much as our hardware and systems will allow, from source code management through other types of media. Why in the world wouldn't we do this with our data if we could?

It'll be interesting to see how this plays out. Widespread adoption of technology tends to follow a path of least resistance. Does Datomic offer a simple enough path to pull many people over? I also know many of us have a preference for building on open source systems; will this be an obstacle for Datomic?

Yes, these are excellent, and goes into much more depth than the brief article I wrote.

Very kind of you to say! I came up with the metaphor when needing to explain this to a semi-technical person as well, so we've had similar needs there.

Using that cache is a good idea. The site linked to was used to gather the original content rather than broad consumption. (I wrote two of the chapters in this book, and this was where we revised them.)

Lots of good articles in there, though.

Sounds great. I'm glad to know something like that's in progress, and many thanks for your efforts on this project!

Understanding that core.async is new and evolving, but is there a reference or an idiomatic way to work with blocking operations, beyond the general advice of separate threads as an exercise for the reader?

EDIT: I bring this up because this seems like a common misstep for users of core.async, and a simple pattern for blocking IO might help people avoid it.

core.async really looks awesome...if we can create simple patterns for working with blocking operations, it would be a compelling model for a lot of use cases.

(Also, hats off to the core.async developers; it seems like the reward for creating something great is just demand for more. ;)

Ah, I didn't realize that core.typed could deal with rich data structures like that. That's actually pretty amazing.

A perhaps naive question: could this sort of thing tap into Clojure's type hints rather than using external annotations? So rather than writing the example in the post:

(ann my-inc [Number -> Number])

(defn my-inc [n] (let [internal-number (Integer/parseInt "1")] (+ n internal-number)))

one could write this:

(defn ^Number my-inc [^Number n] (let [internal-number (Integer/parseInt "1")] (+ n internal-number)))

...and then run a type checker that reads and analyzes the hints?

Of course, the core.typed annotations could preserve whatever information they need in the compiled output, whereas the type hints aren't preserved past the compile phase (as far as I can tell.) Is that the limitation that requires defining type information in separate annotations?

Not to mention the operational costs of a small navy to recover the rocket and transport it to a launch site.

Funny to see this here. That wiki was used to put together the contributions for the book, and the fact it wasn't planned as a high-volume site is pretty obvious right now.

There are a number of items worth reading from some pretty good writers in there (Verity Stob, Michael Feathers, Scott Meyers, Uncle Bob, to name a few.) Mostly short vignettes but I enjoyed them.

(Disclosure: I wrote 2/97 of that book, but there are many chapters in there better than mine).

The desire for an open source app top-to-bottom or the need to use existing databases or tooling would be a good reason.

(However, I do think this question is a bit of a red herring: I don't see any obstacles to pulling in a different database in Pedestal.)

I wish the post had gone into depth on _why_ Redshift was significantly faster, but I'm betting it uses in-memory joins whereas (hence the size limitations it mentions) whereas Hive joins are just MapReduce jobs that keep only minimal subsets of data in memory at a given point. The upshot is the Hive/MapReduce strategy isn't limited by physical memory.

Of course, if your data set can fit in memory, then Redshift or similar technologies probably is a better choice than Hive. But it's important to remember that the performance gains here come as the result of a tradeoff.