Enter uv, a project from Astral, launched in 2025 and written in Rust. This post explores what uv brings to the table and why it’s a tool worth watching.

What’s the Big Deal? Speed & The uv Philosophy

Two core tenets define uv’s appeal: speed and a philosophy of unification.

The Need for Speed (Seriously, It’s Fast!) ⚡️

One of uv’s most attention-grabbing claims is its speed — reported to be 10 to 100 times faster than pip and related tools, especially with a “warm” cache (meaning dependencies have been downloaded previously). This isn’t just marketing hype; it stems from deliberate design choices.

Built in Rust, uv leverages performance advantages inherent in the language. It employs techniques like parallel downloads and efficient dependency resolution to minimize waiting times. A key architectural element is its advanced caching mechanism. Instead of just storing downloaded package archives (like zip files), uv unpacks these archives directly into a global cache upon download. When a package like NumPy is needed in multiple virtual environments, uv doesn’t repeatedly copy files. Instead, it creates hard links or reflinks (depending on the filesystem) from the virtual environment back to the single cached copy. This approach is not only significantly faster for subsequent installs but also remarkably disk-space efficient, reducing the redundant storage common in traditional workflows. If you work on large projects or in environments where quick setup is crucial (like CI/CD pipelines), these speed gains can translate into substantial time savings.

One Tool to Rule Them All? unifying the Workflow 🛠️

Beyond sheer speed, uv aims to consolidate the functionality of numerous separate tools into a single, cohesive command-line interface. The goal is to replace the common combination of pip, pip-tools, virtualenv, pipx, pyenv, and even twine.

This unification offers several potential benefits. It reduces the number of tools a developer needs to learn, install, and manage. It promotes a more consistent workflow across different aspects of project management, from initial setup and dependency handling to running tools and managing Python versions themselves. This simplification can lower the cognitive load and reduce the friction often associated with Python environment and package management.

Under the Hood: Project Management with pyproject.toml and uv.lock 🗂️

For managing projects, uv adopts modern Python standards, primarily using the pyproject.toml file. Similar to tools like Poetry or PDM, pyproject.toml serves as the central configuration file where you define core project metadata and direct dependencies.

When dependencies are resolved, uv generates a uv.lock file. This lock file captures the exact versions of all packages in the dependency tree (including transitive dependencies), ensuring reproducible builds across different machines and environments. A key feature is that uv.lock is cross-platform, storing information needed to reconstruct the environment consistently regardless of the operating system or Python version (within the project’s constraints). This contrasts with traditional requirements.txt files generated by pip freeze, which are often environment-specific. The combination of pyproject.toml for defining intent and uv.lock for ensuring reproducibility forms the backbone of uv’s project management capabilities. Furthermore, uv supports Cargo-style workspaces, enabling more scalable management of monorepos or projects composed of multiple related packages.

Beyond Installation: uv’s Expanding Capabilities

While fast installation and locking are major draws, uv’s capabilities extend further, integrating tasks often handled by separate utilities.

Comprehensive Project Management

uv provides a complete workflow for managing Python projects. The process typically starts with uv init <project-name>, which sets up a basic project structure including a pyproject.toml file. Dependencies are added using uv add <package-name>, which updates pyproject.toml, resolves dependencies, writes to uv.lock, and installs the package into a local virtual environment (usually .venv), creating the environment if it doesn’t exist.

The uv sync command ensures the virtual environment accurately reflects the state defined in uv.lock. To execute code within the project’s managed environment, uv run <command> can be used, automatically handling environment activation. This integrated approach streamlines the common cycle of defining, installing, and running project dependencies. uv also includes commands for building and publishing packages.

Even More Tricks: Scripts, Tools, and Python Versions

uv incorporates several other helpful features:

• Running Single-File Scripts: For simple scripts, uv offers a way to manage dependencies without a full project setup. Developers can add inline metadata comments (# /// script) within the Python file to declare dependencies (e.g., # /// requires = [“requests”]). Running the script with uv run example.py causes uv to automatically create a temporary, isolated environment, install the declared dependencies, and execute the script. This is particularly useful for utility scripts or quick experiments.
• Executing Tools with uvx: Similar to npx in Node.js or pipx in Python, uv provides uvx (an alias for uv tool run) to execute command-line tools distributed as Python packages in ephemeral environments. For instance, running uvx black . will download black (if needed), run it in a temporary environment, and then discard the environment. This avoids polluting the global or project environment with tools only needed occasionally.5 Specific versions or extras can be requested (e.g., uvx ruff@0.3.0 check or uvx — from ‘mypy[reports]’ mypy). Tools can also be installed persistently into a shared location (isolated from projects) using uv tool install <package-name>.
• Managing Python Versions: uv steps into the territory of tools like pyenv by offering capabilities to install and manage Python versions. The command uv python install <version> fetches and installs specified CPython versions (using builds from the python-build-standalone project) or even alternative implementations like PyPy (uv python install pypy@3.10). uv python list shows available and installed versions. While uv-installed Pythons aren’t automatically added to the global PATH by default (though this is in preview), they can be easily used for creating environments (uv venv --python 3.11) or running commands (uv run --python 3.12 python script.py). Crucially, uv can automatically download and install a required Python version if it’s not found when needed by a command, simplifying setup. Project-specific Python versions can also be pinned using a .python-version file.

These additional features underscore uv’s ambition to be a truly comprehensive tool, addressing multiple facets of the Python development lifecycle within a single interface.

Getting Started: Practical uv Examples

Reading about features is one thing; seeing them in action is another. Here are some practical examples to illustrate how uv can be used.

Super Simple Setup

Installation is designed to be straightforward.

• On macOS and Linux:
  curl -LsSf https://astral.sh/uv/install.sh | sh
• On Windows (using PowerShell as Administrator):
  powershell -ExecutionPolicy ByPass -c “irm https://astral.sh/uv/install.ps1 | iex”

Alternative methods like Homebrew (brew install uv) are also available. After installation, verify it with uv --version.

Zooming into 2025: Why uv Isn’t Just a Shooting Star

The problems uv aims to solve — slow installations, complex tooling, and environment inconsistencies — are likely to become more acute by 2025. As projects grow larger, incorporate more complex dependencies (especially in fields like AI/ML), and rely on faster, more efficient CI/CD pipelines, the need for speed and reliability in packaging tools will only increase. uv’s core strengths directly address these anticipated future needs. Its potential to significantly simplify and accelerate common Python development workflows positions it well for continued relevance and potentially widespread adoption in the coming years.

Conclusion: Ready to Give the Python Workflow a Turbo Boost?

If you are a Python developer looking to streamline your workflows and boost productivity, uv is undoubtedly a tool to investigate. Consider trying its pip-compatible interface in an existing project for an instant speed boost, or initialize a new project with uv init to explore its full potential. The journey towards a faster, simpler Python development experience might just start with uv.

Further Resources:

• Official Documentation: https://docs.astral.sh/uv/
• GitHub Repository: https://github.com/astral-sh/uv

Help others find this article by clapping.

Python Packaging in 2025: Introducing uv, A Speedy New Contender 🚀 was originally published in Fhinkel on Medium, where people are continuing the conversation by highlighting and responding to this story.

A standardized way for AI agents, regardless of the framework they’re built on or the vendor who created them, to discover each other, communicate securely, exchange information, and coordinate actions.

The absence of a common communication standard acts as a major bottleneck. Building custom “glue code” between every pair of agents is inefficient, doesn’t scale, and breaks easily when components are updated. This mirrors the early days of the internet before standardized protocols like HTTP enabled seamless web communication. Without a standard, we risk creating fragmented “mini-internets” of AI agents unable to harness collective intelligence.

Enter Google’s Agent-to-Agent (A2A) protocol. Launched in April 2025 with backing from over 50 technology and service partners, A2A is an open protocol designed to be a “universal handshake” or the “HTTP for AI agents”. It aims to provide a standardized way for AI agents, regardless of the framework they’re built on or the vendor who created them, to discover each other, communicate securely, exchange information, and coordinate actions.

What is Google’s A2A Protocol? Diving into the Core Concepts

At its heart, Google’s A2A is a specification — a set of rules and formats — defining how independent AI agents interact at a messaging level. It’s designed explicitly for agent-to-agent communication, enabling collaboration between autonomous, potentially “opaque” agents (meaning their internal workings don’t need to be exposed) built using different technologies.

The overarching goal is to establish a common language, breaking down the communication silos that currently hinder multi-agent systems. By providing this standard, we aim to democratize advanced agent interactions and, crucially, enable true multi-agent scenarios where agents collaborate as peers, rather than simply being treated as callable “tools” by a central orchestrator.

We designed A2A around five key principles :

1. Embrace agentic capabilities: The protocol focuses on allowing agents to interact using their natural, often unstructured modalities (like text, potentially evolving to voice or video), preserving their autonomy even if they don’t share memory or internal tools.
2. Build on existing standards: A2A leverages familiar web technologies like HTTP/HTTPS, JSON-RPC, and Server-Sent Events (SSE). This pragmatic choice significantly lowers the barrier to adoption for developers and allows easier integration into existing enterprise IT infrastructure, avoiding the need to learn entirely new transport mechanisms.
3. Secure by default: Enterprise-grade security is a core tenet, with support for authentication and authorization mechanisms comparable to OpenAPI standards.
4. Support for long-running tasks: A2A is designed to handle interactions that might take minutes, hours, or even days, potentially involving human-in-the-loop scenarios, providing mechanisms for status updates and feedback.
5. Modality agnostic: Recognizing that agent interactions aren’t limited to text, A2A supports various data types, including audio and video streaming.

Technical Deep Dive: How A2A Works

A2A employs a client-server architecture. An “A2A Client” (which could be an application or another agent) initiates requests, formulating tasks it needs help with. An “A2A Server” (a remote agent exposing an A2A endpoint) receives these requests and acts upon them. An agent can act as both a client and a server depending on the interaction. The protocol allows these agents to remain “opaque,” meaning they collaborate based on declared capabilities without revealing their internal implementation details.

The protocol is built around several core components:

• Agent Card: This is a public JSON metadata file, typically found at /.well-known/agent.json relative to the agent's base URL. It serves as a digital business card, allowing agents to discover each other and understand their capabilities. Key fields include the agent's name, description, endpoint URL, protocol version, authentication requirements, capability flags (like support for streaming or push notifications), and a list of specific skills offered.
• Task: The central unit of work or conversation within A2A. Each task has a unique ID generated by the client and progresses through a defined lifecycle with states like submitted, working, input-required, completed, failed, canceled, and unknown. This stateful task abstraction is fundamental to managing potentially complex, long-running, and interactive collaborations, distinguishing A2A from simple, stateless API calls and enabling more sophisticated delegation scenarios.
• Message: Represents a single turn in the conversation between the client (role: “user”) and the server agent (role: “agent”). Messages contain one or more Parts.
• Part: The basic unit of content within a Message or Artifact. A2A defines standard part types: TextPart for plain text, FilePart for binary data (either inline base64-encoded bytes or a URI pointing to the file), and DataPart for structured JSON data (e.g., for forms).
• Artifact: Represents the final outputs or deliverables generated by the agent during a task, such as generated files or structured data results. Artifacts also contain Parts.

The typical communication flow involves:

1. Discovery: The client agent fetches the remote agent’s Agent Card from its well-known URL to learn its capabilities and endpoint.
2. Initiation: The client generates a unique Task ID and sends an initial message to the server agent’s endpoint using either the tasks/send or tasks/sendSubscribe method.
3. Processing:

• For tasks/send (synchronous), the server processes the task and returns the final Task object, including any artifacts, in the HTTP response. This is suitable for quick tasks.
• For tasks/sendSubscribe (streaming), the server keeps the connection open and sends real-time updates back to the client using Server-Sent Events (SSE). These events can be TaskStatusUpdateEvent (indicating changes in the task's state) or TaskArtifactUpdateEvent (delivering partial or complete results). This is ideal for long-running tasks or interactive sessions.

4. Interaction (Optional): If a task enters the input-required state, the server agent is waiting for more information. The client can send subsequent messages using the same Task ID via tasks/send or tasks/sendSubscribe to provide the needed input.

5. Push Notifications (Optional): Servers supporting this capability can proactively send task updates to a webhook URL provided by the client (configured via tasks/pushNotification/set), avoiding the need for the client to maintain an open connection or poll for updates.

Under the hood, A2A relies on standard HTTP/HTTPS (HTTPS is required for production deployments) as the transport layer, JSON-RPC 2.0 for structuring requests and responses, and Server-Sent Events (SSE) for streaming capabilities. Security is handled through standard enterprise-grade authentication and authorization methods (specified in the Agent Card), with TLS encryption being mandatory for secure communication. Detailed structures for the JSON objects like AgentCard, Task, Message, Part, and Artifact are defined in the official JSON specification.

A2A vs. The World: Comparisons with Other Frameworks

How does A2A stack up against existing approaches for connecting AI systems?

Traditional AI Integration (REST/GraphQL APIs)

Before protocols like A2A, integrating different AI services typically involved creating custom REST or GraphQL APIs for each component. This leads to an “API explosion,” where developers must manage numerous unique endpoints, each with its own request/response structure. This approach creates tight coupling — systems become directly dependent on the specific interfaces of the services they call, making the overall architecture brittle. Swapping out a model or adding a step often requires significant code changes and risks breaking existing integrations.

A2A aims to solve this by providing a standardized messaging layer. Instead of custom endpoints, agents communicate using a shared schema and protocol. This promotes modularity (agents can be developed independently) and loose coupling, making the system more scalable and resilient to change. A2A facilitates a more adaptive, context-aware interaction model compared to the rigid request-response pattern of traditional APIs.

Anthropic’s Model Context Protocol (MCP)

Perhaps the most discussed comparison is with Anthropic’s Model Context Protocol (MCP). A2A is complementary to MCP, we like to say “A2A ❤️ MCP”.

The protocols serve distinct roles:

• MCP focuses on Agent-to-Tool/Resource communication. It provides a standard way for an AI model (or agent) to access external tools, APIs, databases, or other resources, often involving structured inputs and outputs. Think of it as standardizing how an agent uses its tools.
• A2A focuses on Agent-to-Agent collaboration. It standardizes how independent, autonomous agents discover each other and engage in potentially dynamic, multi-turn, and multimodal conversations to achieve a shared goal. Think of it as standardizing how agents talk to each other.

A common analogy used is that MCP provides the “wrench” (tool access), while A2A facilitates the “dialogue between mechanics” (agent collaboration). A travel agent might use A2A to coordinate with separate flight and hotel booking agents, and those agents might internally use MCP to interact with the actual booking APIs or databases.

Both protocols aim to help developers build complex AI applications leveraging multiple components. The line between a sophisticated “tool” and a simple “agent” can be blurry. Could MCP, with its ability to stream responses, be adapted for agent-like communication? Could A2A be used to interact with agents that primarily act as wrappers around tools? Ultimately, developer preference and which protocol proves simpler and more effective in practice may determine the outcome.

gRPC-based Multi-Agent Systems

Before A2A, some multi-agent systems used frameworks like gRPC for communication. gRPC is known for high performance, leveraging protocol buffers for efficient serialization. A2A, relying on HTTP and JSON-RPC/SSE, might offer easier integration with standard web infrastructure and simpler firewall traversal. More importantly, A2A provides not just a transport mechanism but a specific application-level protocol defining agent discovery (Agent Cards), task lifecycles, standardized message parts, etc., aimed at facilitating agentic collaboration beyond basic RPC calls. While gRPC focuses on efficient RPC, A2A focuses on standardizing the semantics of agent interaction across different implementations.

Workflow Orchestration (e.g., AWS Step Functions)

Workflow orchestration tools like AWS Step Functions excel at defining and executing structured workflows, often involving sequences of serverless functions or managed services. They typically involve a central definition of states and transitions. A2A, in contrast, is designed for potentially more dynamic and decentralized communication between autonomous agents. The interaction flow in A2A isn’t necessarily predefined in a central workflow but emerges from the agents discovering capabilities and collaborating on tasks. While distinct, they aren’t mutually exclusive; an agent whose internal logic is orchestrated by Step Functions could still use A2A to communicate with external agents. A2A provides the protocol for interaction, whereas Step Functions provides the service for executing a defined workflow.

Developer Resources and Community

Here’s a list of resources to help developers get started with A2A:

• Official Documentation: includes technical documentation, key topic explanations (like A2A vs. MCP, discovery, security), and the JSON specification.
• GitHub Repository: specification source, documentation, and official code samples.
• GitHub Issues (for bugs and protocol suggestions) and Discussions (for general questions and ideas) on the repository. Broader developer forums on Reddit, such as r/AI_Agents.

Conclusion: The Road Ahead for Agent Collaboration

Google’s Agent2Agent protocol represents a significant and ambitious effort to establish a much-needed standard for interoperability in the rapidly expanding world of AI agents. By providing an open, common language built on familiar web standards, A2A aims to break down the silos that currently limit the potential of multi-agent systems, particularly within complex enterprise environments.

The potential benefits are substantial: unlocking synergistic effects where specialized agents collaborate dynamically, simplifying the integration of diverse AI capabilities into cohesive workflows, reducing custom development overhead, and fostering innovation through a more open and composable ecosystem. Visions of agent marketplaces and plug-and-play AI components become more tangible with such a standard.

A2A offers developers and enterprises a compelling vision and a concrete set of tools to start building the next generation of interconnected AI systems. The ongoing evolution and adoption of A2A will be a critical space to watch in the coming years.

If you found this helpful, show your appreciation by clapping.

Google’s A2A Protocol: Enabling the Conversation Between AI Agents was originally published in Fhinkel on Medium, where people are continuing the conversation by highlighting and responding to this story.

Knowing your way around the commnand line has many benefits. With a bit of practice, you can accomplish many tasks much faster on the command line than using any other tool.

The command line is almost always available, unlike some GUI tools that must be installed. You can save frequently-used commands as aliases and save time. Your bash history will save your bacon at least once when you forget how to do something. When you ssh into a remote machine, such as your work station or a virtual machine in the cloud, you can use the command line instead of a slow GUI.

Here are some tips that’ll make working on the command line much easier.

Shortcuts instead of typing full commands

Use the arrow up and arrow down keys to iterate over the last used commands.

Use tab completion to complete commands, directories and files, and even some parameters. Start typing one or two characters of a command. Then hit tab twice. If that gives you several options, type a few more letters and then hit tab again. You should never type out a full filename. Use tab aggressivly. It’s muscle memory you need to build if you want to be fast on the command line.

If you remember part of a command, but not necessarily the beginning, you can search for that command using reverse-i-search. To use reverse-i-search, press Ctrl+R, then start typing the command. If there are commands that match what you’ve typed, you’ll see a suggestion. You can keep typing to further refine your search results or press Ctrl+R again to cycle through the commands that match your search query in reverse order.

Navigate around

Use cd .. to navigate up one directory. Use cd to jump to your home directory. This is the same as cd ~/. Use cd / to jump to the root directory and cd - to go back to the last directory.

Jump to the beginning and end of the line with Ctrl A and Ctrl E. You can move word by word with option arrow left and option arrow right.

When you realize that you’re typing the wrong command, use Ctrl C to start over. This is faster than deleting the command character by character.

Hidden config files

To see hidden files, i.e., filenames that start with a dot, use ls -la. Check out the hidden .gitconfig in your home directory. Or edit the .gitignore file in a git project to exclude files from source control. You can configure a lot of tools via a dot file. Many follow the convention of the config file name ending in rc ("run command"), like .npmrc for npm config settings.

Configure your terminal

The config file .bash_profile determines how your terminal, more specifically bash, behaves¹. The .bash_profile file is in your home directory (~/) . In this file you can do things like

• specify shortcuts with alias
• configure your prompt
• set environment variables.

Git on the command line

If you use git on the command line, there are a few tricks to make your life easier. You can enable tab completion for git and configure custom shortcuts like git co for git checkout. For me, the most important feature is to always see what branch I'm on.

My bash shows the current directory and the branch I’m on if I’m in a git directory. I configure this behavior in my .bash_profile with the following lines:

# The next line enables git autocompletion
. ~/.git-completion.bash

# The next lines configures a fancy prompt
. ~/.git-prompt.sh
export GIT_PS1_SHOWDIRTYSTATE=1
export PS1='\[\e[35m\]\w$(__git_ps1 " (%s)")\$\[\e[0m\] '

Download the scripts from the git source code mirror and follow the instructions: .git-prompt.sh and .git-completion.bash. You can customize the color of the prompt. I use different colors on different machines to easily see what machine I’m ssh’ed into.

Most importantly

Be adventurous. Don’t let the terminal intimidate you! Once you know some basics, it’s easy to work efficiently with the command line. Search StackOverflow for tips to make things even easier. Read through other people’s config files (mine are here). Go explore and try a few things. Lots of tips are really helpful, you just need to find those that work for you.

¹ .bash_profile is the default config for bash on MacOS. On Linux, use .bashrc.

Many thanks to Amy Unruh, Sofia Leon, ErinMcKean, Sandra Friesen, and Sarah Clark for their thoughtful reviews and comments.

How I learned to love the terminal was originally published in Fhinkel on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why do we sometimes use bare double dashes in commands like git checkout -- file.txt? Isn’t git checkout file.txt just as good?

Bare double dashes signify the end of options. Anything after -- is a parameter. For example in git, you can checkout a file named master:

git checkout master     # Checkout the master branch
git checkout -- master  # Checkout the file named master

In proper documentation, we see git checkout -- file.txt when git checkout file.txt would work, too. -- safeguards against checking out branches when files have the same name as branches.

POSIX.1–2017 standard

12.2 Utility Syntax Guidelines

Guideline 10:

The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the ‘-’ character.

Use case: rm

When you need to delete an oddly named filed like -file.txt, rm treats -f as an option. Use bare double dashes to delete the file. This works for many bash commands that work with files like cat, mv, or touch.

rm -file.txt          # rm: illegal option -- l
rm -- -file.txt 

Use case: grep

You can use double dashes in grep when the search term starts with a dash:

grep -- -v *

This searches for the string ‘-v’ rather than interpreting it as the option for inverse matches.

Use case: npm scripts

Double dashes are incredibly useful for npm scripts. Anything after the double dashes is not an option of npm, but a parameter for the script that npm executes.

If we want to fix linter errors, we do not need to look up which linter is specified in package.json. As long as the linter understands --fix, we simply run

npm run lint -- --fix

Franziska Hinkelmann, Ph.D. on Twitter

TIL, you can pass parameters with -- to an npm script, like `npm run lint -- --fix` 🤯

What can you do with --?

I hope this shed some light on why we sometimes have bare double dashes in our commands. Where do you use --? I would love to hear your tips in the comment section.

The Curious Case of Double Dashes was originally published in Fhinkel on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article is available in Chinese.

V8 is Google’s open source JavaScript engine. Chrome, Node.js, and many other applications embed V8. If you have heard any talks about V8 or read any blogposts, you have surely heard about Smis, small integers. This article digs into V8’s source code to discover how large Smis actually are.

JavaScript, by specification, does not know about integers (with the exception of recently introduced BigInts). It only knows IEEE doubles. But many operations are based on integers, just think of for loops. All JavaScript engines have a special representation for integers. V8 has so called Smis, small integers.

The range for Smis on 64-bit platforms is -2³¹ to 2³¹-1 (2³¹≈ 2*10⁹). That might not be immediately obvious when you look at V8’s source code. kSmiMinValue and kSmiMaxValue are defined in include/v8.h as follows:

static const int kSmiMinValue = 
  (static_cast<unsigned int>(-1)) << (kSmiValueSize — 1);

static const int kSmiMaxValue = -(kSmiMinValue + 1);

How is that equal to -2³¹ and 2³¹-1? Let’s dissect the C++ code into smaller chunks.

Left Shift

<< is a bitwise left shift. Left shift means that we shift the binary representation of a number to the left by filling up the right side with zeros. For example, 5 << 3 = 40.

You might notice that left shift for positive numbers is the same as multiplication by 2.

Static Cast to an Unsigned Integer

static_cast<unsigned int>(-1)

What happens when we cast a negative value to an unsigned integer, i.e., a positive number? The bits stay the same but the value is interpreted differently. Casting to an unsigned integer allows us to use left shift because it is only defined for positive numbers in C++.

What is the binary representation of -1? In Two’s complement, -1 is represented as (111...111)_2 because 2⁶³-2⁶²-2⁶¹- … -2²-2¹–1 = 1.

Putting it All Together

If you follow the definitions in V8’s source code, you will find that kSmiValueSize is defined as 32 on 64-bit machines, resulting in:

kSmiMinValue =(static_cast<unsigned int>(-1)) << (kSmiValueSize — 1)
             = (111...111)_2 << (32-1) 
             = (111...111)_2 << 31
             = (11...1100...00)_2  // 31 zeros
             = -2^31

Now we use this result in the initial definition of kMaxValue.

int kSmiMaxValue = -(kSmiMinValue + 1);

That is easy, kSmiMaxValue = -(-2^31+1) = 2^31-1. The range for Smis in V8 on 64-bit platforms is [-2³¹, 2³¹-1].

32-Bit Platforms

On 32-bit platforms, kSmiValueSize = 31. So we shift by 30, and end up with kMinValue = -2^30. Note, 2³⁰≈ 10⁹.

Why is the range for Smis one bit smaller on 32-bit platforms? Internally, V8 tags all JavaScript values as either Smis or heap objects using the least significant bit. If it is1, it is a pointer. If the least significant bit is a 0, it is a Smi. That means that 32-bit integers can use only 31 bits for the Smi value, because one bit is used as the tag.

V8 tags all values as either Smis or heap pointers using the least significant bit.

Smis are not as small as you might have thought, but they easily fit into a 32-bit or 64-bit integer together with their encoding bit.

Bonus question: Given a non-empty array of integers, every element appears twice except for one. Find that single one. Can you use binary representation for a linear time, constant space solution?

I like to use a dotted Leuchturm1917 and Pigma Microns for my notes.

V8 Internals: How Small is a “Small Integer?” was originally published in Fhinkel on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nothing to do over the holidays? Read these inspiring blogs about software development. Listed in alphabetical order.

Amy Nguyen

amy nguyen | writing, computer science, feminism, and excessive introspection

Amy Nguyen writes about software engineering, e.g., how she hacked Ticketmaster with DevTools to get Taylor Swift tickets, interviewing, and speaking at tech conferences: blog.amynguyen.net

Erica Sadun

Erica Sadun

Author of Swift Style, Erica Sadun writes about Swift and news from the Apple ecosystem. Check her out at ericasadun.com.

Jessie Frazelle

Jessie Frazelle's Blog

Jessie Frazelle writes about containers and Linux and anything cool. Have a look at her blog at blog.jessfraz.com.

Julia Evans

Julia Evans writes about Linux and How to teach technical concepts with cartoons. If anybody knows how to do that, it’s her, because she has published eight zines about systems and debugging tools. Read her posts at jvns.ca.

⚡Julia Evans⚡ on Twitter

how to be a wizard programmer

Kara Carrell

Kara.Codes

Kara Carrell is a web developer who makes the prettiest slides. She has a series of Today I Learned posts on her blog https://kara.codes with topics ranging from hexadecimal to REST to chown. Totally fun to read.

Preethi Kasireddy

Preethi Kasireddy - Medium

Preethi Kasireddy is a Blockchain Engineer and her writing is entertaining and so personal. Check out her Medium posts about the blockchain and career advice.

Sarah Drasner

Sarah Drasner's bomb site

Sarah Drasner is an authority on all things Vue.js and SVG. She’s a member of the Vue.js core team and author of SVG Animations. Check out the posts under Writing on her website that link to her articles in CSS-Tricks and other publications.

Shirley Wu

Shirley Wu - Medium

Shirley Wu makes the prettiest data visualizations. Just have a look at her beautiful Film Flowers. Oh, and do you know her #shirleychats on YouTube?

Suz Hinton

meow machine

Suz Hinton aka Noopkat writes about hardware hacking with Node.js and she is so kind to share some of her work setup. Confession: I just ordered something she recommends on Amazon. I adore her live coding stream on Twitch.

Vaidehi Joshi

www.vaidehi.com

Vaidehi Joshi started her journey as a software engineer three years ago. She writes the series BaseCS where she explains computer science concepts in a very approachable way. If you want to brush up on trees, dynamics programming, or Dijkstra, you should definitely check out her blog www.vaidehi.com.

Enjoy reading and Happy Holidays! ⛄️

Here is a Twitter list so you can easily follow all ten authors.

Check out my blog for more things V8 and Node.js ✨🐢🚀✨

🎁☕️👓 My Holiday Reading List was originally published in Fhinkel on Medium, where people are continuing the conversation by highlighting and responding to this story.

Since VS Code 1.18, you can expand the little Git annotations in the gutter like in WebStorm. They show the diff inline in the editor and make individual reverts easy.

The Git annotations in the gutter are subtle yet helpful. They instantly draw my eyes to the lines that I changed. Together with the inline view of the diff and the revert button, they are invaluable to me.

I need the inline change review when I delete too many lines or type in the wrong window. I need it when I make multiple changes and realize one of them doesn’t work. I need it when I refactor and want to compare to the previous version. I’m so happy this feature is in VS Code now ❤️. I could do all of this on the command line, but inline is clearer because I don’t have to adjust to a different view or sort through all the other changes.

A blue bar in the gutter indicates that the line was changed. For new lines, the bar is green. A little red triangle symbolizes deleted lines.

Click on a gutter annotation to see the changes. I often find this more convenient than looking at the diff in other views. There is a revert button next to every change. In many cases, clicking the button is much quicker than using git checkout --patch (tough git commit -p is one of my favorite tools).

If you are switching over from WebStorm to VS Code, Asim Hussain has a video with great tips for converts.

Check out my blog for more things V8 and Node.js ✨🐢🚀✨

New in VS Code: Inline Change Review was originally published in Fhinkel on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s hard to find places in Munich where you can take out your laptop and work for a while. Here are my finds. I hope this helps you if you visit Munich or if you’re a local like me and want a change of scenery.

“Papa, was machen die Leute da?”

“Die spielen Büro.” — Father and son in German coffee shop.

Lost Weekend

Vegan coffee shop located next to the subway station Universität in Maxvorstadt. Mostly students, working by themselves or on group assignments. Usually quite busy, be prepared to share your table. Free wifi and lots of power plugs. Selection of cakes and vegan sandwiches. Delicious soy milk latte!

Stadtbibliothek am Gasteig (Library)

Very quiet. Good wifi. They have armchairs hidden between the bookshelves and lots of desks and larger tables. I’d say most people there are students. As far as I know it’s OK to bring drinks into the library. I’ve seen lots of bottles and snack boxes on the tables. There’s a coffee shop downstairs or you can bring your own.

Free for anybody. Just walk in, there are no id checks or anything like that. No bag check either. Centrally located at the S-Bahn station Rosenheimer Platz, follow the signs underground for Gasteig. The library entrance is on the second floor of the main building. Downstairs, they sell concert tickets and there’s a coffee shop. Take the escalators upstairs. Open on weekdays from 10 am — 7 pm and on Saturdays from 11 am — 4 pm. Closed on Sundays.

Café Lotti

It’s pink and the audience is 90% female. It’s also quite busy, but there’s a hidden nook in the back with two sofas. Every time I’ve been there we were lucky and the sofas were free. You’re so hidden back there that you have to go to the counter and order. They have wifi, coffee, and tasty cakes.

Black Bean at Münchner Freiheit

I’ve worked here a few times but the wifi didn’t work and the coffee isn’t great. The location is convenient though and the seats comfortable.

My favorite place is definitely the library. Can’t beat being around so many books. Only drawback, it’s closed on Sundays.

Can you recommend any other places in Munich? Please tell me in the comments I would love to check them out. Thank you 🙏.

Check out my blog for more things V8 and Node.js ✨🐢🚀✨

Co-Working and Coffee Shops in Munich for Digital Nomads was originally published in Fhinkel on Medium, where people are continuing the conversation by highlighting and responding to this story.

In Java or C#, value types (primitives) are stored on the stack, reference types on the heap. Memory allocation in terms of stack and heap is not specified in the C++ standard. Instead, the standard distinguishes automatic and dynamic storage duration. Local variables have automatic storage duration and compilers store them on the stack. Objects with dynamic memory allocation (created with new) are stored on the free store, conventionally referred to as the heap. In languages that are not garbage-collected, objects on the heap lead to memory leaks if they are not freed.

When can we allocate objects on the stack? One important detail is that the stack for storing objects is the same as the run-time call stack. The run-time stack, consisting of stack frames, is responsible for program execution and function calls. A stack frame contains all the data for one function call: its parameters, the return address, and its local variables. Stack-allocated objects are part of these local variables. The return address determines which code is executed after the function returns.

The stack frame only exists during the execution time of a function, and so do the objects on the stack frame. That has the advantage that we do not need to worry about memory leaks caused by stack-allocated objects — but the objects are also not available anymore once we return from the function.

Only objects of fixed size known at compile time can be allocated on the stack*. This way we know the size of a stack frame at compile time, and can access objects on the stack with fixed offsets relative to the stack pointer.

When can we allocate objects on the heap? You can think of the heap as extra storage completely independent of the run-time stack. It’s memory with no particular layout. Independent of program execution, we can ask for memory in this heap. When we allocate memory, the system makes sure that nothing else can use that same memory and invalidate our data. Objects on the heap live on after we exit the function that allocated the memory. This is good — but now it’s our responsibility to free memory on the heap, or we end up with memory leaks. In garbage-collected languages, the garbage collector frees memory on the heap and prevents memory leaks.

Stack and heap in the context of memory management have always been nebulous concepts to me. Understanding the run-time stack finally made it click.

Stack and heap became clear to me when I read Computer Systems: A Programmer’s Perspective (3rd Edition). Now it seems kind of obvious, but once you understand something it’s always obvious.

The book has several chapters on machine-level representation of programs. These chapters are about assembly code. One has a subsection The Run-Time Stack.

That section explains how passing control between functions affects the run-time stack. It details where parameters and return values are stored so they’re available in the called or calling function. Allocating and deallocating memory is simply decrementing and incrementing the stack pointer by an appropriate amount. If you’re interested and want to know more, the book is really helpful.

Learned something? Clap your 👏 to say “thanks!” and help others find this article.

(*) Only objects of fixed size known at compile time can be allocated on the stack. Except for funny things like Variable-Length Arrays in C99. GCC allocates them on the stack.

Check out my blog for more things V8 and Node.js ✨🐢🚀✨

Confused about Stack and Heap? was originally published in Fhinkel on Medium, where people are continuing the conversation by highlighting and responding to this story.

Get types like string, number, null, or custom classes at runtime. V8 can now collect type information. V8 is Google’s open source JavaScript engine. Chrome, Node.js, and many other applications use V8. This type profiler is built into the engine, the information is not statically inferred.

JavaScript is a dynamically typed language. But most code is written with fixed types in mind. When debugging JavaScript, it is helpful to know the types of variables and parameters at runtime. It is often hard to infer types for complex code. Type profiling provides this information at runtime.

function foo(x) {
    if (x < 2) {
      return 42;
    }
    return "What are the return types of foo?";
  }

The static definition of foo() does not hold any information about the parameters with which foo is called. In this simple case, we can deduct the return types, number and string. For more complex cases that is often impossible, though. But at runtime, it is clear with which types foo is being called. Runtime type information collects exactly this information.

Type profiling is implemented in V8 and can be used via the V8 inspector protocol. If you get Node.js with the newest V8, you can test it yourself. In a few weeks a newer V8 will land in Node and type profile will be available in regular Node releases.

One of the intended use cases is to auto-generate JSDoc, TypeScript, or Flow annotations. As type profiling is available via Node’s inspector, you can build your own tools with it to fit your needs. Here’s a demo to show some basic usage.

I look forward to all the tools the community will come up with that use type profile.

I look forward to all the tools the community will come up with that use type profile. I’m sure there are many use cases that I haven’t even considered yet. If you are already working on a prototype, please share!

Excited about runtime type profile in JavaScript? Clap your 👏 to say “thanks!” and help others find this article.

Check out my blog for more things V8 and Node.js ✨🐢🚀✨

Runtime type information for JavaScript was originally published in Fhinkel on Medium, where people are continuing the conversation by highlighting and responding to this story.