holyjak

[holyjak]

Rust edition 2024. Use the side menu or next arrow to actually see what it contains. This seems to be gradual evolution, with various developer experience improvements. According to Gemini (checked against the docs):

The Rust 2024 Edition brings several key changes, focusing on improving developer experience, code safety, and consistency. Here's a breakdown of the most significant updates: 1. Dropping Temporaries Earlier: In previous editions, temporary values created at the end of a block were dropped after local variables. This could lead to lifetime issues, forcing developers to use workarounds like assigning temporaries to explicit variables. The 2024 edition changes this behavior: temporaries from the end of a block are now dropped before local variables. This simplifies code and resolves lifetime-related inconveniences. 2. Enhanced Safety for Unsafe Code: The unsafe keyword in Rust serves two purposes: marking a function as unsafe to call and allowing unsafe operations within its body. This conflation can be problematic. The 2024 edition introduces a new warning for unsafe operations within unsafe functions that aren't explicitly marked with an unsafe block. This encourages developers to isolate unsafe code more precisely, improving safety. Additionally, the edition refines how extern blocks (used for declaring external functions) are handled, making them more aligned with the overall safety goals. 3. Streamlining impl Trait Types: impl Trait allows functions to return types that satisfy a specific trait without revealing the concrete type. The 2024 edition brings consistency to how lifetime parameters and generic type parameters are handled in impl Trait types. They are now implicitly captured by default, simplifying the syntax and making it more intuitive. 4. Cargo Enhancements: Cargo, Rust's package manager, receives a significant update with support for selecting dependencies based on compatible minimum-supported Rust versions. This helps maintainers avoid dependency conflicts and ensures compatibility across projects. 5. Other Notable Changes: Prelude Additions: The Future and IntoFuture traits are now included in the prelude, eliminating the need for manual imports. Macro Matching: The rules for how declarative macros match syntax are refined and made stricter, leading to more predictable behavior. Rustdoc Improvements: Rustdoc tests are expected to run faster, enhancing the documentation generation process. Code Formatting: Rust's code formatter will sort imports differently and support multiple editions, providing more flexibility. Language Evolution: The gen keyword (for generators) and unguarded prefixed string literals are reserved for future use, and the "never" type (!) becomes less special. Iterating Through Boxed Slices: Programmers will have the ability to iterate directly through boxed slices, simplifying common operations.

[holyjak]

"The Hydro Project at UC Berkeley is developing cloud-native programming models that allow anyone to develop scalable and resilient distributed applications. Our research spans across databases, distributed systems, and programming languages to deliver a modern, end-to-end stack for cloud programming." A part of that is the Rust Hydro library, for writing choreographed distributed dataflow programs. I.e. run it on a cluster or couple processes, with primitives for sending data etc.

They have also published a number of interesting-looking papers exploring topics such as defining the foundational semantic properties of streaming languages (streaming progress and eager execution) and rule-based rewriting of distributed algorithms, CRTDs and Byzantine Fault Tolerant protocols to make them more scalable without being error-prone. The 2021 New Directions in Cloud Programming sets the direction for the project (and I appreciate its decomplecting of the aspects of distributed systems :)), and the 2021 master thesis Hydroflow: A Model and Runtime for Distributed Systems Programming provides, I assume, background for Hydro. It states:

[..] Hydroflow new cloud programming model used to create constructively correct distributed systems. The model is a refinement and unification of the existing dataflow and reactive programming models. Like dataflow, Hydroflow is based on an algebra of operators which execute in streaming fashion across multiple nodes. [..] construct provably monotonic distributed programs which can always make forward progress without incurring the high cost of coordination. Hydroflow is primarily a low-level compilation target for future declarative cloud programming languages, [..]

More about the 2025 Hydro:

Hydro is a high-level distributed programming framework for Rust. Hydro can help you quickly write scalable distributed services that are correct by construction. Much like Rust helps with memory safety, Hydro helps with distributed safety. Hydro also makes it easy to get started by running your distributed programs in either testing or deployment modes.

Hydro is a distributed dataflow language, powered by the high-performance single-threaded DFIR runtime. Unlike traditional architectures such as actors or RPCs, Hydro offers choreographic APIs, where expressions and functions can describe computation that takes place across many locations. It also integrates with Hydro Deploy to make it easy to deploy and run distributed Hydro programs either locally or in the cloud.

[holyjak]

Fast, memory-saving headless browser made for web automation for AI agents, LLM training, scraping. Written in Zig. Support of Web APIs is work in progress, as is Chrome DevTools Protocol (used by Playwright, Puppeteer). Reportedly, 9x less memory than Chrome and 11x faster than Chrome, with an instant startup. Interesting project and technologies.

[holyjak]

An excellent article from Dan North. Do neither hack a quick solution nor build the perfect one - instead, build the Best Simple System for Now (BSSN, or "bison " :)). What is it?

The Best Simple System for Now is the simplest system that meets the needs of the product right now, written to an appropriate standard. It has no extraneous or over-engineered code, and any code it does have is exactly as robust and reliable as it needs to be, neither more nor less.

"Each part of the phrase Best Simple System for Now is deliberate and each part is mutually reinforcing. Any deviation in any of these means it is no longer the Best Simple System for Now, but something strictly weaker."

BSSN acknowledges that incurring tech debt is not sustainable (unless we take it on delibaretly) on the one hand, and that our guesses about what the future will need are mostly wrong, on the other hand.

A BSSN does not achieve ‘future-proofing’, ‘scalability’, or ‘flexibility’ by catering for all possible futures, but by being so simple that it can flex in any direction we want.

Bonus - Gall’s law:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

BSSN's "Best": "Simple" does not mean cutting corner. The ‘right way’ is contextual (i.e. how important is this piece of code?). Underinvesting = loosing stability and resilience, overinvesting = ignoring opportunity cost. "Sketching [code] is about providing just enough quality that you can sustain a direction, knowing you can go back and fill in the blanks later on (or throw away the sketch with minimal investment lost). Hacked code quickly becomes unmanageable. Well-sketched code is just a lighter-weight version of the real thing."

"The best code is intention-revealing; it strikes a balance between cohesion and coupling, making it easy to navigate, easy to reason about, easy to change." "If the code does not have domain terms front and centre, mapping directly to your real-world use case, then this is not the best code." (Good code is CUPID: Composable, Unix philosophy[ed], Predictable, Idiomatic, Domain-based.)

"n short, iterative delivery tends to offer worse ROI [provided you got it right 😅] – once you factor in all those releases and continual planning activities, as well as all that churning code–but better RAROC [Risk-Adjusted Return on Capital, i.e. minimazing the value at risk], which it turns out is what matters."

[holyjak]

Our UX researcher recommened UMUX-Lite, a brief 2-question survey to collect data about the usefulness and usability our product. UX-Lite builds on it, providing alternative wordings that may work better in some context and a more practical 5-point scale. (The original questions are {Product}’s capabilities meet my requirements and {Product} is easy to use.)

[holyjak]

A good, brief "manual" for running a coding dojo with low effort and great satisfaction.

[holyjak]

CLI tool to easily find the dependency sub-tree a Clojure library comes from (for tools-deps). Easier then processing clojure -Stree manually.

[holyjak]

How to maintain global (app) state while ensuring invariants are preserved? You make a core business ns with primitive operations to operate on the state, and transact (submit) operations-as-data. This namespace is kept small, with well-designed building blocks, but you can also create custom operations as compositions of the primitive ones. A custom operation is a function returning a list of primitive or other custom operations. The core transact fn then expands these until it only has primitive operations, which are then applied to the state.

[holyjak]

1h podcast episode with Nathan Marz, digging into Rama and its use of Clojure. We learn about what is great with Clojure (immutable = less complexity, can build flexible abstractions), what you need to be aware of w.r.t. performance (avoid laziness [Rama internally uses only at 2 places], inefficient fns such as last) and the open world assumption, which may lead to undiscovered errors (such as asking a record for a mistyped keyword). We learn about some internals of Rama, about their beta customers (one processing 1M events / second) and much more.

[holyjak]

Looking at demographics and data about users may be misleading. You need to know what the customer is trying to accomplish in a given circumstance - their "job to be done." When we buy a product, we essentially “hire” it to help us do a job. Understand the timeline of events that led up to a purchasing decision and the “forces” that ultimately pushe people into that decision.

Quote: “I went in thinking we were in the business of new-home construction. But I realized we were in the business of moving lives.” => The developer provided moving services, two years’ worth of storage, and a sorting room within the condo development where new owners could take their time making decisions about what to discard.

The circumstances are more important than customer characteristics, product attributes, new technologies, or trends. Jobs are never simply about function—they have powerful social and emotional dimensions.

[holyjak]

A demo web app from an experienced developer. Highlights: somplicty (routing - cond, minimal middleware, no component framework), 1st class DB queries.

[holyjak]

Assertions micro-library for Clojure/Script:

Tiny cross-platform Clj/s codebase with zero dependencies

Trivially easy to learn, use, and understand

Terrific error messages for quick+easy debugging

Terrific performance: miniscule (!) runtime cost

Easy elision for zero runtime cost

No commitment or costly buy-in: use it just when+where needed

Perfect for library authors: no bulky dependencies

Ex.: ...(have? integer? n).... Error contains place, predicate, actual value, its type, ... .

[holyjak]

"Drop-in replacement for clojure.edn that is 6 times faster."

[holyjak]

A year ago, Linux Foundation has formed OpenTofu, an open source alternative to Terraform's widely used infrastructure as code provisioning tool. OpenTofu is an open and community-driven response to Terraform's recently announced license change from a Mozilla Public License v2.0 (MPLv2) to a Business Source License v1.1, providing everyone with a reliable, open source alternative under a neutral governance model. Started as a fork of Terraform.

[holyjak]

Essentially a tutorial of building and deploying a minimal, production-like Clojure web app with server-side rendering for managing bookmarks. Featuring Aero, Integrant, Reitit, next.jdbc, Hiccup, Fly.io. Uses tools.build to create an uberjar in a multi-stage Dockerfile. Socket REP in prod, accessible via VPN (fly proxy). GithubActions for deployment.

[holyjak]

T. Heller's answer to how to use shadow-cljs in a fullstack setup with a CLJ backend. Some good productivity tips, such as adding a Cursive restart shortcut, which also syncs all modified files into the REPL, and simplifying shadow invocation with handy metadata (:shadow/requires-server). Check out also the follow-up, Supercharging the REPL Workflow (building css, leveraging shadow's fs-watch

[holyjak]

Choices made by a Clojure SaaS support thingy for system components: Jetty 12 (websockets) with Ring, Reitit, PostgreSQL (with next.jdbc and HoneySQL), Integrant for component system, Aero for config, transactional emails via Resend (a service), deployment via fly.io. Frontend: UIx (a React wrapper) with re-frame, tailwind-css, DaisyUI (a comprehensive CSS component library built on top of tailwind), Portfolio 🇳🇴 for UI component documentation, shadow-cljs.