Tag: exceptions

Porting from Perl to Go: Simplifying for Platform Engineering
Rewriting a script for the Homebrew package manager taught me how the Go programming language’s design choices align with platform-ready tools.

The problem with brew upgrade

By default, the brew upgrade command updates every formula (terminal utility or library). It also updates every cask (GUI application) it manages. All are upgraded to the latest version — major, minor, and patch. That’s convenient when you want the newest features, but disruptive when you only want quiet patch-level fixes.

Last week I solved this in Perl with brew-patch-upgrade.pl, a script that parsed brew upgrade’s JSON output, compared semantic versions, and upgraded only when the patch number changed. It worked, but it also reminded me how much Perl leans on implicit structures and runtime flexibility.

This week I ported the script to Go, the lingua franca of DevOps. The goal wasn’t feature parity — it was to see how Go’s design choices map onto platform engineering concerns.

Why port to Go?
- Portfolio practice: I’m building a body of work that demonstrates platform engineering skills.
- Operational focus: Go is widely used for tooling in infrastructure and cloud environments.
- Learning by contrast: Rewriting a working Perl script in Go forces me to confront differences in error handling, type safety, and distribution.
The journey

Error handling philosophy

Perl gave me try/catch (experimental in the Perl v5.34.1 that ships with macOS, but since accepted into the language in v5.40). Go, famously, does not. Instead, every function returns an error explicitly.

Perl:
```
use v5.34;
use warnings;
use experimental qw(try);
use Carp;
use autodie;

...

try {
  system 'brew', 'upgrade', $name;
  $result = 'upgraded';
}
catch ($e) {
  $result = 'failed';
  carp $e;
}
```
Go:
```
package main

import (
  "os/exec"
  "log"
)

...

cmd := exec.Command("brew", "upgrade", name)
if output, err := cmd.CombinedOutput(); err != nil {
  log.Printf("failed to upgrade %s: %v\n%s",
    name,
    err,
    output)
}
```
The Go version is noisier, but it forces explicit decisions. That’s a feature in production tooling: no silent failures.

Dependency management
- Perl: cpanfile + CPAN modules. Distribution means “install Perl (if it’s not already), install modules, run script.” Tools like carton and the cpan or cpanm commands help automate this. Additionally, one can use further tooling like fatpack and pp to build more self-contained packages. But those are neither common nor (except for cpan) distributed with Perl.
- Go: go.mod + go build. Distribution is a single (platform-specific) binary.
For operational tools, that’s a massive simplification. No runtime interpreter, no dependency dance.

Type safety

Perl let me parse JSON into hashrefs and trust the keys exist. Go required a struct:
```
type Formula struct {
  Name              string   `json:"name"`
  CurrentVersion    string   `json:"current_version"`
  InstalledVersions []string `json:"installed_versions"`
}
```
The compiler enforces assumptions that Perl left implicit. That friction is valuable — it surfaces errors early.

Binary distribution

This is where Go shines. Instead of telling colleagues “install Perl v5.34 and CPAN modules,” I can hand them a binary. No need to worry about scripting runtime environments — just grab the right file for your system.
- homebrew-semver-guard-darwin (Universal Binary for macOS)
- homebrew-semver-guard-linux-amd64 (Intel/AMD 64-bit binary for Linux)
- homebrew-semver-guard-linux-arm64 (Arm 64-bit binary for Linux)
Available on the release page. Download, run, done.

Semantic versioning logic

In Perl, I manually compared arrays of version numbers. In Go, I imported golang.org/x/mod/semver:
```
import (
  golang.org/x/mod/semver
)

...

if semver.MajorMinor(toSemver(formula.InstalledVersions[0])) !=
  semver.MajorMinor(toSemver(formula.CurrentVersion)) {
  log.Printf("%s is not a patch upgrade", formula.Name)
  results.skipped++
  continue
}
```
Cleaner, more legible, and less error-prone. The library encodes the convention, so I don’t have to.

Deliberate simplification

I didn’t port every feature. Logging adapters, signal handlers, and edge-case diagnostics remained in Perl. The Go version focuses on the core logic: parse JSON, compare versions, run upgrades. That restraint was intentional — I wanted to learn Go’s idioms, not replicate every Perl flourish.
Platform engineering insights

Three lessons stood out:
1. Binary distribution matters. Operational tools should be installable with a single copy step. Go makes that trivial.
2. Semantic versioning is an operational practice. It’s not just a convention for library authors — it’s a contract that tooling can enforce.
3. Go’s design aligns with platform needs. Explicit errors, type safety, and static binaries all reduce surprises in production.
Bringing it home

This isn’t a “Perl vs. Go” story. It’s a story about deliberate simplification, taking a working Perl script and recasting it in Go. The aim is to see how the language’s choices shape a solution to the same problem.

The result is homebrew-semver-guard v0.1.0, a small but sturdy tool. It’s not feature-finished, but it’s production-ready in the ways that matter.

Next up: I’m considering more Go tools, maybe even Kubernetes for services on my home server. This port was practice, an artifact demonstrating platform engineering in action.

Links
- Original Perl script: brew-patch-upgrade.pl
- Go release: homebrew-semver-guard v0.1.0
- Last week’s post: Patch-Perfect: Smarter Homebrew Upgrades on macOS
October 5, 2025

Get out early with Perl statement modifiers

When I first started writing Perl in my early 20’s, I tended to follow a lot of the structured programming conventions I had learned in school through Pascal, especially the notion that every function has a single point of exit. For example:

sub double_even_number {
    # not using signatures, this is mid-1990's code
    my $number = shift;

    if (not $number % 2) {
        $number *= 2;
    }

    return $number; 
}

This could get pretty convoluted, especially if I was doing something like validating multiple arguments. And at the time I didn’t yet grok how to handle exceptions with eval and die, so I’d end up with code like:

sub print_postal_address {
    # too many arguments, I know
    my ($name, $street1, $street2, $city, $state, $zip) = @_;
    # also this notion of addresses is naive and US-centric

    my $error;

    if (!$name) {
        $error = 'no name';
    }
    else {
        print "$name\n";

        if (!$street1) {
            $error = 'no street';
        }
        else {
            print "$street1\n";

            if ($street2) {
                print "$street2\n";
            }

            if (!$city) {
                $error = 'no city';
            }
            else {
                print "$city, ";

                if (!$state) {
                    $error = 'no state';
                }
                else {
                    print "$state ";

                    if (!$zip) {
                        $error = 'no ZIP code';
                    }
                    else {
                        print "$zip\n";
                    }
                }
            }
        }
    }

    return $error;
}

What a mess. Want to count all those braces to make sure they’re balanced? This is sometimes called the arrow anti-pattern, with the arrowhead(s) being the most nested statement. The default ProhibitDeepNests perlcritic policy is meant to keep you from doing that.

The way out (literally) is guard clauses: checking early if something is valid and bailing out quickly if not. The above example could be written:

sub print_postal_address {
    my ($name, $street1, $street2, $city, $state, $zip) = @_;

    if (!$name) {
        return 'no name';
    }
    if (!$street1) {
        return 'no street1';
    }
    if (!$city) {
        return 'no city';
    }
    if (!$state) {
        return 'no state';
    }
    if (!$zip) {
        return 'no zip';
    }

    print join "\n",
      $name,
      $street1,
      $street2 ? $street2 : (),
      "$city, $state $zip\n";

    return;
}

With Perl’s statement modifiers (sometimes called postfix controls) we can do even better:

    ...

    return 'no name'    if !$name;
    return 'no street1' if !$street1;
    return 'no city'    if !$city;
    return 'no state'   if !$state;
    return 'no zip'     if !$zip;

    ...

(Why if instead of unless? Because the latter can be confusing with double-negatives.)

Guard clauses aren’t limited to the beginnings of functions or even exiting functions entirely. Often you’ll want to skip or even exit early conditions in a loop, like this example that processes files from standard input or the command line:

while (<>) {
    next if /^SKIP THIS LINE: /;
    last if /^END THINGS HERE$/;

    ...
}

Of course, if you are validating function arguments, you should consider using actual subroutine signatures if you have a Perl newer than v5.20 (released in 2014), or one of the other type validation solutions if not. Today I would write that postal function like this, using Type::Params for validation and named arguments:

use feature qw(say state); 
use Types::Standard 'Str';
use Type::Params 'compile_named';

sub print_postal_address {
    state $check = compile_named(
        name    => Str,
        street1 => Str,
        street2 => Str, {optional => 1},
        city    => Str,
        state   => Str,
        zip     => Str,
    );
    my $arg = $check->(@_);

    say join "\n",
      $arg->{name},
      $arg->{street1},
      $arg->{street2} ? $arg->{street2} : (),
      "$arg->{city}, $arg->{state} $arg->{zip}";

    return;
}

print_postal_address(
    name    => 'J. Random Hacker',
    street1 => '123 Any Street',
    city    => 'Somewhereville',
    state   => 'TX',
    zip     => 12345,
);

Note that was this part of a larger program, I’d wrap that print_postal_address call in a try block and catch exceptions such as those thrown by the code reference $check generated by compile_named. This highlights one concern of guard clauses and other “return early” patterns: depending on how much has already occurred in your program, you may have to perform some resource cleanup either in a catch block or something like Syntax::Keyword::Try’s finally block if you need to tidy up after both success and failure.

January 19, 2022

Highlighting members of the Perl family

This past year of blogging has introduced me to a wide variety of people in the Perl community. Some I’ve admired from afar for years due to their published work, and even more I’ve “met” interacting on social media and other forums. So this will be the first in an occasional series highlighting not just the code, but the people that make up the Perl family.

Paul “LeoNerd” Evans

I first came across Paul’s work during his series last year on writing a core Perl feature; he’s responsible for Perl v5.32’s isa operator and v5.34’s experimental try/catch exception handling syntax. I interviewed him about the latter for Perl.com in March 2021. He’s been active on CPAN for so much longer, though, and joined the Perl Steering Council in July. He’s also often a helpful voice on IRC.

Elliot Holden

Renowned author and trainer Randal L. “merlyn” Schwartz linked over the weekend in a private Facebook group to Elliot’s impassioned YouTube video about his day job as a Perl web application developer. Through his alter ego Urban Guitar Legend Elliot is also a passionate musician; besides gigging and recording he’s been posting videos for nine years. (I’m a bit envious since I took a break from music almost twenty years ago and haven’t managed to recapture it.) Elliot seems like the quintessential needs-to-get-shit-done developer, and Perl is perfect for that.

Gábor Szabó

Gábor is a polyglot (both in human and computer languages) trainer, consultant, and author, writing about programming and devops on his Code Maven and Perl Maven websites. He’s also the founder and co-editor of Perl Weekly and recipient of a Perl White Camel award in 2008 thanks to his organizational and support contributions. Last year he introduced me to the world of live pair programming, working on a web application using the Mojolicious framework.

If you’re on Twitter and looking to connect with other Perl developers, please consider participating in the Perl community I’ve set up there. Twitter Communities are topic-specific moderated discussion groups, unlike the freewheeling #hashtags system that can be diluted by spam or topics that share the same name. Unfortunately, they’re still read-only on the Twitter Android app, but you can participate fully on iOS/iPadOS and the website.

January 11, 2022
Perl warnings and the warn function
I mentioned in passing last week that the next major release of Perl, v5.36, is set to enable warnings by default for code that opts in to use v5.35; or above. Commemorating Perl’s 34^th birthday the week before that, I noted that the warnings system has been getting ever finer-grained since its introduction in 2000. And fellow Perl blogger and CPAN author Tom Wyant has been cataloging his favorites over the past several months—the latest as of this writing was on the “ambiguous” category of warnings, and you can find links to previous entries in his series at the bottom of that post.

It occurred to me afterward that there may be some confusion between the warnings pragma and the related warn function for reporting arbitrary runtime errors. warn outputs its arguments to the standard error (STDERR) stream, or if it’s not given any then you get a string with any exception from $@ ($EVAL_ERROR under use English) followed by a tab and then “...caught at <file> line x.” If that’s empty too, a plain warn just says, “Warning: something's wrong at <file> line x.”, which isn’t exactly helpful, but then again you didn’t give it much to go on.

warn output doesn’t have to go to STDERR, and this is where the relation to the warnings pragma comes in because both are governed by the __WARN__ signal handler in the %SIG hash. Normally, you might opt to only display runtime warnings if a debugging flag is set, like so:
```
#!/usr/bin/env perl

use strict;
use warnings;

my $DEBUG = 0;
$SIG{__WARN__} = sub { warn @_ if $DEBUG };
warn 'shhh'; # silenced

$DEBUG = 1;
warn 'hello warnings';
```
But if you set that signal handler in a BEGIN block, it catches compile-time warnings too, in which case flipping a flag after the fact has no effect—the compiler’s already run:
```
#!/usr/bin/env perl

use strict;
use warnings;

my $DEBUG = 0;
BEGIN { $SIG{__WARN__} = sub { warn @_ if $DEBUG } }
my $foo = 'hello';
my $foo = 'world'; # no warning issued here

$DEBUG = 1;
my $foo = 'howdy'; # still nothing
```
By the way, both __WARN__ and __DIE__ hooks are also used by the Carp module and its friends, so you can use the same technique with their enhanced output:
```
#!/usr/bin/env perl

use strict;
use warnings;
use Carp qw(carp cluck);

my $DEBUG = 0;
BEGIN { $SIG{__WARN__} = sub { warn @_ if $DEBUG } }
carp 'quiet fish';

$DEBUG = 1;
loud_chicken();

sub loud_chicken {
    cluck 'here comes a stack trace';
}
```
You could use these as stepping stones towards a debug log for larger applications, but at that point, I’d suggest looking into one of the logging modules on CPAN like Log::Log4perl (not to be confused with that lately-problematic Java library), Log::Dispatch (which can be wired into Log4perl), or something else to suit your needs.
January 4, 2022
Avoid Yoda conditions in Perl you should
I remember a brief time in the mid-2000s insisting on so-called “Yoda conditions” in my Perl. I would place constants to the left of equality comparisons. In case I accidentally typed a single = instead of ==, the compiler would catch it instead of blithely assigning a variable. E.g.:
```
if ( $foo == 42 ) { ... } # don’t do this
if ( 42 == $foo ) { ... } # do this
if ( $foo = 42  ) { ... } # to prevent this
```
And because a foolish consistency is the hobgoblin of little minds, I would even extend this to string and relational comparisons.
```
if ( 'bar' eq $foo ) { ... } # weirdo
if ( 42 > $foo )     { ... } # make it stop
```
It looks weird, and it turns out it’s unnecessary as long as you precede your code with use warnings;. Perl will then warn you: “Found = in conditional, should be ==“. (Sidenote: Perl v5.36, due in mid-2022, is slated to enable warnings by default if you do use v5.35; or above, in addition to the strictness that was enabled with use v5.11;. Yay for less boilerplate!)

If you want to fatally catch this and many other warnings, use the strictures module from CPAN in your code like this:
```
use strictures 2;
```
This will cause your code to throw an exception if it commits many categories of mistakes. If you’re running in a version control system’s working directory (specifically Git, Subversion, Mercurial, or Bazaar), the module also prevents you from using indirect object syntax, Perl 4‑style multidimensional arrays, and bareword filehandles.

Getting back to assignments vs. conditionals, there is one case where I’ve found it to be acceptable to use an assignment inside an if statement, and that’s when I need to use the result of a check inside the condition. For example:
```
if ( my $foo = some_truthy_function() ) {
    ... # do something further with $foo
}
```
This keeps the scope of some_truthy_function()‘s result inside the block so that I don’t pollute the outer scope with a temporary variable. Fortunately, Perl doesn’t warn on this syntax.
December 28, 2021

Tag: exceptions

The problem with brew upgrade

Why port to Go?

The journey

Error handling philosophy

Dependency management

Type safety

Binary distribution

Semantic versioning logic

Deliberate simplification

Platform engineering insights

Bringing it home

Links

The problem with `brew upgrade`