Developer Voices Kris Jenkins

PostgreSQL is an incredible general-purpose database, but it can't do everything. Every design decision is a tradeoff, and inevitably some of those tradeoffs get fundamentally baked into the way it's built. Take storage for instance - Postgres tables are row-oriented; great for row-by-row access, but when it comes to analytics, it can't compete with a dedicated OLAP database that uses column-oriented storage. Or can it?

Joining me this week is Philippe Noël of ParadeDB, who's going to take us on a tour of Postgres' extension mechanism, from creating custom functions and indexes to Rust code that changes the way Postgres stores data on disk. In his journey to bring Elasticsearch's strengths to Postgres, he's gone all the way down to raw datafiles and back through the optimiser to teach a venerable old dog some new data-access tricks. 

–

ParadeDB: https://paradedb.com

ParadeDB on Twitter: https://twitter.com/paradedb

ParadeDB on Github: https://github.com/paradedb/paradedb

pgrx (Postgres with Rust): https://github.com/pgcentralfoundation/pgrx

Tantivy (Rust FTS library): https://github.com/quickwit-oss/tantivy

PgMQ (Queues in Postgres): https://tembo.io/blog/introducing-pgmq

Apache Datafusion: https://datafusion.apache.org/

Lucene: https://lucene.apache.org/



Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Kris on Twitter: https://twitter.com/krisajenkins

The actor model is a popular approach to building scalable software systems. And isn't hard to understand when you're just reading about the beginner's examples. But how do you architect a complex design using the actor model? Which patterns work well? How do you think through it?

Joining me to take us through it is Hugh McKee. Hugh's a total actor-model fan, and a Developer Advocate for Lightbend (the company that created the popular actor framework Akka). He takes us from his definition of actors to the designs he's worked on, the patterns he's found most useful, and the interesting meeting-point between actor-based designs and event-based ones.

—

Wikipedia - Actor Model: https://en.wikipedia.org/wiki/Actor_model

Hugh's book, Designing Reactive Systems: https://go.lightbend.com/designing-reactive-systems-role-of-actor-model

Hugh on Twitter: https://twitter.com/mckeeh3

Hugh on LinkedIn: https://www.linkedin.com/in/mckeehugh

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Kris on Twitter: https://twitter.com/krisajenkins

Bytewax is a curious stream processing tool that blends a Python surface with a Rust core to produce something that's in a similar vein to Kafka Streams or Apache Flink, but with a fundamentally different implementation. This week we're going to take a look at what it does, how it works in theory, and how the marriage of Python and Rust works in practice…

–

The original Naiad Paper: https://dl.acm.org/doi/10.1145/2517349.2522738

Timely Dataflow: https://github.com/TimelyDataflow/timely-dataflow

Bytewax the Library: https://github.com/bytewax/bytewax

Bytewax the Service: https://bytewax.io/

PyO3, for calling Rust from Python: https://pyo3.rs/v0.21.2/

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Kris on Twitter: https://twitter.com/krisajenkins

--

#softwaredevelopment #dataengineering #apachekafka #timelydataflow

Mojo is the latest language from the creator of Swift and LLVM. It's an attempt to take some of the best techniques from CPU/GPU-level programming and package them up in a Python-compatible syntax.

In this episode we explore why Mojo was created, and what it offers to Python programmers and non-Python programmers alike. How is it built for performance, and which performance features matter? What's its take on functional programming and type systems? And can it marry the high-level programming of Python with the low-level programming of LLVM/MLIR?

If you're a Python programmer who needs better performance, a C programmer who expects more from a 'scripting language', or just someone who'd be happier if Python had a first-class type system, Mojo might well be for you…

–

Mojo: https://www.modular.com/max/mojo

Mojo's Roadmap: https://docs.modular.com/mojo/roadmap.html

The Mojo Discord: https://discord.com/invite/modular

MLIR: https://mlir.llvm.org/

Chris's Talks: https://nondot.org/sabre/Resume.html#talks

Chris on Twitter: https://twitter.com/clattner_llvm

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Kris on Twitter: https://twitter.com/krisajenkins

–

#software #podcast #mojolang #ml #pythonml

Every database has to juggle the need to process new data and to query old data. That task falls to any system that "does stuff and remembers stuff". But it's quite hard to really optimise one system for both use cases. There are different constraints on new and old data, and as a system gets larger and larger, those differences multiply to breaking point. That's something Twitter's engineers were figuring out in the 2010s.

One solution that came up in those years was the Lambda Architecture. A two-pronged approach that recognises the divide between new and old data, and works hard to blend the two together seamlessly in userspace. But that seamless blending is easier said than done. It's nearly all bespoke work.

What if you could get it off the shelf? Let someone else do the work of combining two different kinds of database into one neat package? That's the question of the week as we look at the recently open-sourced project Proton, and its attempt to be the Lambda Architecture in a box…

–

Proton Docs: https://docs.timeplus.com/proton

Proton Source: https://github.com/timeplus-io/proton

Timeplus: https://www.timeplus.com/

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Kris on Twitter: https://twitter.com/krisajenkins

–

#podcast #softwareengineering #databases #dataengineering 

Rust changed the discussion around memory management - this week's guest hopes to push that discussion even further.

This week we're joined by Evan Ovadia, creator of the Vale programming language and collector of memory management techniques from far and wide. He takes us through his most important ones, including linear types, generation references and regions, to see what Evan hopes the future of memory management will look like.

If you've been interested in Rust's borrow-check and want more (or want different!) then Evan has some big ideas for you to sink your teeth into.

–

Vale: https://vale.dev/

The Vale Discord: https://discord.com/invite/SNB8yGH

Evan's Blog: https://verdagon.dev/home

Evan's 7DRL Entry: https://verdagon.dev/blog/higher-raii-7drl

7DRL: https://7drl.com/

https://verdagon.dev/grimoire/grimoire

What Colour Is Your Function?: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

42, the language: https://forty2.is/

Verona Language: https://www.microsoft.com/en-us/research/project/project-verona/

Austral language: https://austral-lang.org/

Surely You're Joking, Mr Feynman! (book): https://www.goodreads.com/book/show/35167685-surely-you-re-joking-mr-feynman



Evan on Twitter: https://twitter.com/verdagon

Find Evan in the Vale Discord: https://discord.com/invite/SNB8yGH



Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Kris on Twitter: https://twitter.com/krisajenkins

–

#software #programming #podcast #valelang