Developer Voices – Details, episodes & analysis

OCaml has one of the best-loved compilers available, and parts of it are surprisingly pluggable, so it’s not surprising that someone would eventually try to wed OCaml with JavaScript and the web browser. In fact, the ecosystem has gone further, and there are now a bevvy of options for people who want to write OCaml and run it in the browser, or want to write OCaml in the browser, or want to write something that looks like JavaScript but runs OCaml on the backend.

Joining me to explore the OCaml-meets-JavaScript world is Antonio Montiero. He’s a key maintainer/contributor for Melange and ReasonML, as well as several other interesting OCaml web projects.

We kick off by discussing the benefits of OCaml and how it clicked with him personally, before we dive into how and why the compiler is being adapted and tweaked to take it to a whole new audience of web-hungry developers.

–

Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices

Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join

Sponsor Antonio’s Work: https://github.com/sponsors/anmonteiro/

–

The OCaml Platform: https://ocaml.org/platform

OCaml on Discord: https://discuss.ocaml.org/t/ocaml-discord-server/1884

ReasonML: https://reasonml.github.io/en/

What is Melange? https://melange.re/v4.0.0/what-is-melange.html

Melange for React Devs: https://react-book.melange.re/

The Melange Playground: https://melange.re/v4.0.0/playground/

js_of_ocaml: https://github.com/ocsigen/js_of_ocaml

FUN OCaml Conference: https://fun-ocaml.com/

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

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

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

Mapping is a hugely complex task to take on. Even if you moved as much of the data-management as you can out to 3rd-party services, you’d still have a tonne of work to do weaving together map tiles, routing information, GPS data, points of interest, search and more. And as if that wasn’t enough, you’d probably want that software to work on a whole range of platforms, so you have to build something that works on iOS, Android and more. It’s little wonder that the space is dominated by a few closed-source projects owned by huge companies with near-limitless resources.

But that doesn’t mean the problem can’t be cracked as an open-source project. This week we look at the open source map library Ferrostar. Joining me to discuss it is the project’s lead developer, Ian Wagner, as we explore the problem space and dive down into Ferrostar’s architecture: A core Rust library serving a suite of custom UI shells written in Kotlin, Swift, WASM and TypeScript.

Along the way there are tips for anyone attempting to build a map, or wanting to interop Rust with other languages.

–

Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices

Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join

Ferrostar on Github: https://github.com/stadiamaps/ferrostar

Ferrostar user guide: https://stadiamaps.github.io/ferrostar/

MapLibre: https://maplibre.org/

Project OSRM: https://project-osrm.org/

Dioxus (Rust UI framework): https://dioxuslabs.com/

Slint: https://slint.dev/

UniFFI (repo): https://github.com/mozilla/uniffi-rs

UniFFI (user guide): https://mozilla.github.io/uniffi-rs/latest/

Beeline (navigation device): https://beeline.co/

Ian on Mastodon: https://fosstodon.org/@ianthetechie

Ian on Twitter: https://x.com/ianthetechie

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

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

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

Smalltalk is one of those programming languages that’s lived out of the mainstream, but often referenced as an influence and an important part of programming history. It’s the cornerstone of object-oriented programming, it was into message passing before actors were cool, and it blurs the line between operating system, programming language and personal notebook. But what is it?

Joining us to discuss it is Juan Vuletich, the creator of one of Smalltalk’s latest incarnations, Cuis. In this episode we cover Smalltalk’s history, its design ideas, Cuis’s unique implementation and what makes this modern implementation something special.

Smalltalk is over 50 years old, but its vision of how computing could work has only begun. Let’s see if we can mine some ideas from it to take us into the next generation of computing...

--

The Cuis Smalltalk Book: https://cuis-Smalltalk.github.io/TheCuisBook/Preface.html

Cuis on Github: https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev

The Cuis Community: https://cuis.st/community

A Short History of Cuis: https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/CuisHistory.md

Monticello VCS: https://wiki.squeak.org/squeak/1287

Juan’s Music Research: https://www.jvuletich.org/research.html

Back to the Future - The Story of Squeak (pdf): https://dl.acm.org/doi/pdf/10.1145/263700.263754

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

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

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

This week we take a close look at the language Inko from two perspectives: The language design features that make it special, and the realities of being a language developer.

Yorick Peterse joins us to discuss why he’s building Inko, and which design sweetspots he’s looking for. We begin with memory management, aiming for the kind of developer who wants control, but without the complexities of Rust. Then we look at the designing for concurrency with typed channels, and handling exceptions by removing them and leaning heavily into ADTs and pattern matching.

Mixed in with all that is a discussion on the realities of being a programming language developer. How do you figure out how to implement your ideas? What tradeoffs do you make and what kind of programmer do you want to be most useful to? How do you teach people new ideas in programming, and how “different” can you make a language before it feels weird? And perhaps the hardest question of all: How do you fund a new programming language in 2024?

–

Inko’s Homepage: https://inko-lang.org/

Yorick’s Homepage: https://yorickpeterse.com/

Ownership You Can Count On (paper): https://inko-lang.org/papers/ownership.pdf

“The Error Model”: https://joeduffyblog.com/2016/02/07/the-error-model/

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

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

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

I’ve often wondered how you build a text editor. Like many software projects, it’s a simple idea at the core with an almost infinite scope for features. How do you build a solid foundation to expand on? Which features matter for launch? And how do you hope to satisfy the needs of every programmer, working in every language?

My guest for this episode is Nathan Sobo. He’s tackled this problem once before with the Atom editor, and he’s back older & wiser with Zed - a new editor written completely from scratch in Rust. It has a modern UI, a wide spread of language support, and a completely different way of looking at team collaboration. But with so much ambition, what are Zed’s priorities, and what’s been left for a future version?

--

Zed Homepage: https://zed.dev/

Segment Trees: https://en.wikipedia.org/wiki/Segment_tree

Ropes: https://en.wikipedia.org/wiki/Rope_(data_structure)

Rust Executors: https://rust-lang.github.io/async-book/02_execution/04_executor.html

More about Roc: https://youtu.be/DzhIprQan68

More about TigerBeetle: https://youtu.be/ayG7ltGRRHs

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

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

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

This week on Developer Voices we’re talking to Ryan Worl, whose career in big data engineering has taken him from DataDog to Co-Founding WarpStream, an Apache Kafka-compatible streaming system that uses Golang for the brains and S3 for the storage.

Ryan tells us about his time at DataDog, along with the things he learnt from doing large-scale systems migration bit-by-bit, before we discuss how and why he started WarpStream. Why re-implement Kafka? What are the practical challenges and cost benefits of moving all your storage to S3? And would he choose Go a second time around?

--

WarpStream: https://www.warpstream.com/

DataDog: https://www.datadoghq.com/

Ryan on Twitter: https://x.com/ryanworl 

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

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

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

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