And also it has inspired a few other clojure datalog databases, so there is much more choice: * https://github.com/datalevin/datalevin * https://github.com/replikativ/datahike * https://github.com/threatgrid/asami

There is also xtdb, but it abandoned datalog and is going in another (albeit interesting direction) https://xtdb.com/

here is a comparison website, but it is somewhat out of date: https://clojurelog.github.io/

Comments URL: https://news.ycombinator.com/item?id=46807073

Points: 4

# Comments: 0

So it must have tools save, manipulate and visualize conveniently (pretty printing, folding etc) the values of vars that contain nested maps, sequences, sets, etc.

Existing clojure IDEs like CIDER for emacs or Calva for VSCode do that too, and it is a must have to have a nice experience with the language

For me the best textual interface I've ever used remains Magit in Emacs: https://magit.vc/ I wish more of Emacs was like it.

I actually use emacs as my git clients even when I'm using a different IDE for whatever reason.

Comments URL: https://news.ycombinator.com/item?id=45013356

Points: 1

# Comments: 0

https://lispcookbook.github.io/cl-cookbook/strings.html

https://clojuredocs.org/clojure.string

For our team, it is very simple:

* we use a library send traces and traces only[0]. They bring the most value for observing applications and can contain all the data the other types can contain. Basically hash-maps vs strings and floats.

* we use manual instrumentation as opposed to automatic - we are deliberate in what we observe and have great understand of what emits the spans. We have naming conventions that match our code organization.

* we use two different backends - an affordable 3rd party service and an all-on-one Jaeger install (just run 1 executable or docker container) that doesn't save the spans on disk for local development. The second is mostly for piece of mind of team members that they are not going to flood the third party service.

[0] We have a previous setup to monitor infrastructure and in our case we don't see a lot of value of ingesting all the infrastructure logs and metrics. I think it is early days for OTEL metrics and logs, but the vendors don't tell you this.

* I can comfortably read any PDF; I don't think the font is too tiny. This is the main reason I bought it for.

* Android means great data support, I can open any format and I can even install the kindle app and read the books I purchased there.

* Using the pen seems nice enough, I started doing some annotations although I didn't buy this device for that.

* Nice way to sort of "airdrop" files from devices on the same network

The bad:

* I am a bit unhappy with the battery life; I hope I will tune it at some point.

* the screen is a little dark, so the "frontlight" needs to be on more often than a black and white e-ink device

The weird:

* the built-in AI assistant is trained in the PRC and has quite interesting opinions on current events and recent history.

So clothing can be more fun, if people want to of course - look at how music subcultures have incredibly varied ways of expression through clothing - metalheads, hiphopheads, punks etc.

It might be slightly harder to get started with, but then the simplicity comes in when it is time to solve common business problems. A trivial example would be - we have this nice db, now our clients want reports. You run your reporting as a separate clojure process, it doesn't impact production at all, without needing to setup reporting databases and log-shipping.

Rachel is spot on about what is often wrong with IT culture; "typecasting" people for someone's convenience or to get a fancy title leads to learned helplessness and dissmissing other people's expertise and interests. I rather we all try to keep things simple and encourage people to be well-rounded engineers.