crad

Looks like it's a thin wrapper on top of boto3 that removes some of the boto-isms.

Scaling for one. If 95% of your workload is non-transactional reads, why introduce transactions?

If your writes are single table and don't require transactional safety, why introduce transactions?

If you need complex, multiple-insert or update writes, transactions are great, but that can also be accomplished in a stored proc.

In a high-velocity environment, avoiding transactions are a great way to get more throughput out of your database server with lower latencies.

Combine Postgres with pgBouncer in statement mode and you can scale it pretty dramatically.

Anecdotes obviously don't validate data models, but I do wonder if my personal experience was common.

My mother-in-law passed last summer, alone in her apartment. She was sick beforehand, quarantined, and living in a senior living community. When she was discovered the coroner did not come and investigate because it appears of natural causes, based on the observations of the local police officer. Her body was transported directly to the funeral home.

I insisted they do a COVID-19 test, which the coroner did at the funeral home. The results came back as positive. Had I not pushed them to actually test, it would have been misreported and her death mis-attributed.

It left me wondering if this was common and how many people may have passed in similar circumstances, without family pushing for testing.

I think you missed the point as an opportunity to pitch your project.

Same here :)

I read pgRouting as focusing on Geospacial routing to get from point A to point B. Is there more to it than that?

A graph database is about storing data that the relationships between pieces of data, like a social graph as an example. You'd have a people and the relationships between them in the database.

I get much higher request throughput in my Tornado applications, with very low response latencies, strange.

Well known in the NodeJS community perhaps - outside of that?

The push for Python 3 has been happening for over 10 years at this point. At what point do you expect people to be able to stop supporting a very outdated distribution of any software?

6 years ago my company switched to Python 3.5 and there was a big push in the community at that point to move away from Python 2. I mean Python 3 came out around the same time as Windows Vista, which has been unsupported since 2017.

Great Post José!

I remember early presentations on Elixir (I think first at Erlang DC in 2011 or 12?) and it's been great to watch Elixir mature and develop.

While I'm strongly in the Erlang camp, I do appreciate the work you and the contributors to Elixir have done for the ecosystem as a whole.

I could see that, my biggest gripe with Erlang has always been around the "softer edges" - easy to grok tooling, easy to read documentation, etc.

And something to work on for sure.

Great post, though as a disclaimer, it mirrors my own biases and thoughts on Elixir. I'm happy for its success, but I too find it a step backward.

On the positive side, I don't think we'd have gotten rebar3 without hex guiding the way.

That being said, I wish hex.pm did a better job at distinguishing between elixir packages and erlang packages. It's always super disappointing when I try and stay pure Erlang to have to sift through Elixir packages for what I am looking for.

It's amazing how far Elixir has come in 10 years. I've always hoped it can become a gateway drug for Erlang. I don't think it will, and I guess that's okay, as it pushes Erlang forward in its own way.

I've been enjoying the game thus far, albeit on the PC. No issues, no bugs encountered. Granted I'm only 6 hours in, but still. I think people go out of their way to find things to complain and be negative about.

Frankly 1.0 releases of just about anything these days are buggy.

I don't expect initial releases of anything to be error free, and in a world of internet based distribution and continuous updates of games, I'm turned off by constant complaints about initial releases.

Cyberpunk 2077 was pushed back to address problems and people complained. They released with problems and people complain.

Game companies can't win in any scenario.

Announce too soon? Complain. Release when you say you will, but with bugs, complain. Release late to address bugs, complain.

Tangentially related, IMO the term "beta release" has evolved from being a true "help us test and find bugs" as a marketing tool to excuse negative feedback.

Personally I'm very disappointed that we keep inventing new standards, like pyproject.toml when other things have like setup.cfg, existed for an extended period of time, works well, and is supported for reading and writing by the stdlib.

Wasn't part of the MVP, will be in the next sprint.

Edit: should clarify, was making a joke.

Bought my wife the new M1 MBA as a replacement for her 3yo Macbook. She loves it. It's significantly faster for her applications, the keyboard is a return to one she likes, and she's not run into any issues with it thus far.

If the Docker issue is resolve, I'll likely jump on a M1 MBP when they're available.

It's evolved. There was a point that Tom Lane was the last line of defense against anything that strayed too far.

Heck at one of Postgres conferences there was a shirt that said something like "Tom Lane reviewed my patch and all I got was this stupid shirt."

While he was not a BDFL style person, in the past, if he didn't like a change, it didn't make it in.

In my org, I have created a process to clearly define what makes a prototype different from a MVP. It appears to be somewhat successful for what my goals were, which was to prevent prototypes from turning into long-term production code.

Prototypes have no restrictions that we would normally place on code (coverage %, automated pipelines, etc) and can only be created in a sandbox AWS account that has no access to our internal systems. It allows developers to prove out concepts or work with product to quickly iterate on PoC.

On the other side, PoC's have a limited lifespan and if successful, are expected to be re-implemented as an MVP, following our internal standards and guidelines.

This is so painful to me. So much of a reinventing the wheel for things that are not broken. :(

That's awesome! I'm glad it was useful!

Thank you!

Thank you!

Using the opportunity to pimp my book, RabbitMQ in Depth: https://www.manning.com/books/rabbitmq-in-depth

:)

1. There is a significant amount of improvement with regard to performance.

2. The partitioning improvements are tremendous and well worth the change if you're using trigger+constraint based partitioning.

3. Parallelization and the addition of concurrent reindexing

4. Built-In Logical Replication

5. JIT query optimization

Well that sucks. I'm glad they got an exit. I won't be using them moving forward due to trust issues with Zoom.

Looks like they got shutdown on Twitter as well:

https://twitter.com/popcorntimetv

Neat, but "instantly" is a bit much. How about quickly? :-p

While it appears that cg_clif is faster to compile, does it provide any performance benefit compared to cg_llvm? Are the compiled binaries as fast as llvm compiled binaries? If not is the use-case for development purposes only?

I sure enjoyed my copy of the Anarchist Cookbook as a teen. :)

I recently brought this up with my team. As an "old-school" web developer, I buy in to the whole CSS as design thing, while the front-end engineers @ work switched to using styled react components. As we look to make substantive design changes, now we have multiple places to make the CSS changes, only now it's the SASS project and all of the React components / projects. I must be missing something about how hip and cool styled components are, but they'll never be as cool as the CSS Zen Garden :)