Plugawy's comments

In my experience (7+ years of using Clojure) this is caused by the misunderstanding of what Clojure actually is: it's a LISP designed for the JVM, you cannot escape the host and pretend it's not there. In return you get access to one of the biggest software ecosystems and pull any library from Maven Central etc.

Coming from Ruby/Go/JS to Clojure was definitely harder than I expected but rather than fighting "this stupid JVM" it made more sense to buy into the idea of how Clojure is built and used.

Same! Never bothered with the so-called HA setup after running a cluster for few months. Making all messages durable + backups of underlying storage are sufficient, while the do not prevent an outage, at least bringing the system back to an operational state is fairly straightforward

I recommend reading this 3-part series on Mongo's marketing - it goes into a lot of detail why Mongo "won". https://www.nemil.com/mongo/1.html

As a former RethinkDB user (we have migrated to Postgres) I actually don't miss it as much as I would - JSONB in PG does what we need, and the real-time features of RethinkDB never really delivered because of various performance issues in the database itself.

ECS can be simpler if you stick to the default and use something like copilot - it effectively turns your compose file into a cluster with all of the networking etc

We've came around full circle - I made this few years ago https://github.com/lukaszkorecki/workflowish

TIL, will check it out - thanks!

EnvKey user here - it looks exactly like EnvKey. Not sure what the underlying crypto primitives are - EnvKey relies on PGP/GPG style stuff and have a lot of documentation about it.

AFAIK there's no RabbitMQ-compatible broker, unless you use AMQP 1.0 in RabbitMQ right now. Their AMQP 0.9 implementation has a lot of RMQ-specific stuff and there's no equivalent.

One is fantastic but you have to be aware of it’s limitations - particularly around network connectivity, something that even OG MPC Live is better at.

Of course if it’s not a factor for you (it’s not for me, I like my One) - then it’s indeed amazing.

Not quite: they acquired the consulting part of Plataformatec, the core Elixir folks are running a new venture: https://changelog.com/podcast/402

The closest thing you can get in irb, is to use Rails' `reload!` after making changes to your files. I don't remember if irb supports this kind of stuff out of the box, perhaps good old `require` works.

Differences:

- Clojure has namespaces, so you can reload just one unit rather than the whole code - I guess load/require would be closest - You can also just evaluate a single form (e.g. a function definition) leaving everything else intact - if you're using something like Component for state management, then you never restart the repl, just stop the system, refresh your repl state and start the system again - closest thing to 'refresh on request' from Rails' dev mode or PHP, but without the nasty surprises

The drawback is that restarting a repl is a slow process, but it's something you do very rarely. Some folks keep their repl process around for weeks.

I'd disagree - my team migrated from running containers on VMs (managed via Ansible) to ECS + Fargate (managed by Terraform and a simple bash script). It wasn't a simple transition by any means, but one person wrapped it up in 4 weeks - now we have 0 downtime deployments, scaling up/down in matter of seconds, and ECS babysits the containers.

Previously we had to deploy a lot of monitoring on each VM to ensure that containers are running, we get alerted when one of the application crashed and didn't restart because Docker daemon didn't handle it etc etc.

Now, we only run stateless services, in a private VPC subnet, Load balancing is delegated to ALB, we don't need service discovery, meshes etc. Configuration is declarative, but written in much friendlier HCL (I'm ok with YAML, but to a degree). ECS just works for us.

Just like K8S might work for a bigger team, but I wouldn't adopt it at our shop, simply because of all of the complexity and huge surface area.

An application usually has one connection, and many channels. Our pattern is to dedicate one channel for all publishing and then N channels mapped to consumer threads.

You don't have to pool connections as channels are multiplexed by them.

Things to watch out for:

- opening too many channels - these map to Erlang processes and can overwhelm your server if you go over ulimits - sharing consumer channels between threads - you might see weird behavior (e.g. acking wrong messages etc)

We've built own library/framework for creating resilient consumers, and it enforces mapping 1:1 channels and consumer threads, as well as automatic reconnections and channel clean ups.

C-r for interactive history search

> Sometimes it requires a lot of thinking to come up with simple solutions.

Author here - I should have tweeted that instead of writing a blog post

Almost nobody uses refs in production code ;-)

I'm not sure to be honest, I've been working with Clojure for 5 years now, and the only "help" I get from the editor I get is "highlight matching pair". I never got used to automatic paren insertion or things like paredit.

Sounds like a bad idea, no? Last ting you want is whole cluster going down because Kafka is misbehaving

The document mentions using Raft for consensus and coordination - it's the same approach used by Etcd, Consul, Serf, RethinkDB and other systems. AFAIK it's easier to implement and understand than Zookeeper's consensus solution.

https://raft.github.io