Perl.CodeCompared.To/Nushell

The similarity ends sooner than it looks. Perl's say writes bytes to a stream, so everything downstream of it is text. Nushell's print takes a value and renders it — hand it a table and you get a drawn table, hand it a record and you get a record. That distinction is the whole page: in Perl the pipeline is made of characters, and in Nushell it is made of values that happen to be displayed as characters at the very end.

Coming from Perl the rule reads backwards: in a Perl script an expression in void context is discarded silently, and in a Nushell script the last expression is the script's output. So a Nushell script that ends in let result = … prints nothing at all, and one that ends in a bare pipeline prints a table you may not have wanted. Use print for anything you want shown before the end, and null or a let as the last line when you want a script to be quiet.

perl -ne wraps your code in a loop over input lines and hands each one to you as $_. The Nushell equivalent has no wrapper and no implicit variable: lines turns the text into a list, and everything after it is ordinary list processing. That is a small thing that says something large — Perl gives you a special mode for the line-at-a-time case because lines are what it fundamentally has, while Nushell treats lines as one more way of getting a list and then leaves the special-casing behind.

Note where the type conversion happens in each. Perl has no separate string and number types at the value level, so $age + 1 just works and "36abc" + 1 quietly gives 37; that permissiveness is exactly what makes Perl fast to write and exactly what lets a malformed field pass unnoticed. Nushell makes you say into int, which fails loudly on input that is not a number. The rest of the page is about the situation where neither language should have been parsing at all.

Count what the Perl version has to get right that has nothing to do with the actual question. It must skip blank lines, choose between split /\s+/ and split ' ' (they differ on leading whitespace), assume the fields never contain a space, and know that field 1 is the age. Change the upstream program's column order and the script is silently wrong. The Nushell version names age, so the only way to break it is to remove the column — which fails loudly. That is the trade: Perl works on anything that has ever been printed, and Nushell works beautifully right up to the boundary where somebody hands you text.

Read the third Perl line: sort @sizes gives 1024 2048 512, because "512" sorts after "2048" as a string. That is not a Perl bug, it is the honest consequence of a value that does not know whether it is a number — and every Perl programmer has shipped it at least once. Nushell has no such fork in the road, because 512 parsed as an integer the moment it entered the list. describe is the command that tells you what a value is, which is worth knowing early.

Notice the declarations have no sigil at all: it is let name, not let $name. That catches Perl programmers constantly, and the rule is simple once seen — the $ is part of the reference, never part of the name. There is also no @ or % to choose between, because a list and a record are just two kinds of value a name can hold, the way an arrayref and a hashref already are in modern Perl.

You will use mut less than you expect, because the accumulate-into-a-variable loop that Perl writes constantly is usually a pipeline here — math sum rather than $total += $_. There is also a scoping rule with no Perl equivalent: a mut variable cannot be captured by a closure, so you cannot write each { |item| $total += $item }. That is deliberate, because a closure may one day run in parallel, and it pushes you towards reduce, which is the right tool anyway.

Nushell has nothing like it, and the cost is that you say what you want: length for the count, .0 for the element, str join to flatten into a string. The gain is that an expression means the same thing wherever it appears, so a pipeline stage can be cut out and tested on its own — you cannot lift my $count = @friends out of its line without changing what it does. If you have ever been bitten by a subroutine returning a list where you wanted a count, this is the section that explains why that cannot happen here.

The third line is where Nushell wins outright. Perl's double-quoted strings interpolate variables but not expressions, so "@{[ $age + 1 ]}" is the well-known workaround: build a one-element anonymous array, dereference it, and let list interpolation do the rest. Nushell's hole takes any expression, including a whole pipeline — $"total: ($items | length)". Note also that a plain "…" string in Nushell never interpolates, which is what Perl's single quotes do; the $ prefix is the opt-in.

That missing builtin is a small landmark: every Perl codebase contains some version of s/^\s+|\s+$//g, usually written slightly differently each time, and the /r flag that returns the modified copy instead of editing in place only arrived in 5.14. Two Nushell details worth carrying: str upcase and str downcase were deprecated in 0.114 in favor of str uppercase and str lowercase, so the old spellings print a warning; and str substring takes a range rather than an offset and length. That range is inclusive at both ends, so Perl's substr $text, 0, 5 is str substring 0..4 — a genuine off-by-one waiting for anyone translating code.

That distinction is a preview of the Tables section. "ada:36" | split column ":" name age produces a one-row table with named columns, which is the shape you actually wanted whenever you wrote my ($name, $age) = split in Perl and then had to remember which was which. Note that Nushell's split row takes a literal string by default, not a pattern; add --regex to make it one, where Perl's split takes a pattern by default and a literal only if you spell it out.

Two things surprise Perl programmers. There is no negative indexing: $numbers.-1 is not a thing, and last is the answer. And slicing is a command, slice, rather than subscript syntax — which reads worse in isolation and better in a pipeline, since it can sit between two other stages without parentheses. first 3 and last 2 take counts, so the common cases rarely need slice at all. The range is inclusive at both ends, like Perl's @numbers[1 .. 3], and it clips silently rather than erroring when the top end runs past the list.

The practical effect is that a value has to be kept — $queue | append "second" on a line by itself computes a longer list and throws it away, silently. That is the most common beginner mistake here, and the habit that fixes it is to end every line either in a let or in a pipe. In exchange, the aliasing question Perl programmers know from passing \@array around simply does not arise: nothing you hand to a command can come back changed.

The flattening is the part worth dwelling on. Perl's %person is a flat list of alternating keys and values, which is what makes (%person, age => 37) work as a copy-with-override and also what makes it so easy to lose a key by accident — an odd-length list is a warning, not an error. A Nushell record is a single value with an ordered key set, so upsert, merge and reject are explicit operations rather than emergent behavior of list flattening. Note columns, not keys: a record and a table row are the same thing here, so they share the vocabulary.

That third Perl line is the tax: getting the length of a nested array needs @{ ... } to turn the reference back into an array so that scalar context can count it. Nothing in Nushell corresponds, because a list is a value and length takes it directly. Perl's references buy real things a record does not offer — aliasing, cycles, weak references, code refs — but for the ordinary job of describing configuration or a decoded JSON document, they are pure ceremony, and that job is most of what either language does with nested data.

An array of hashrefs is the same data, and that is the point: Perl can hold it perfectly well, but the language has no opinion about it, so displaying it means choosing a format string and getting the widths right by hand. Every Nushell command that returns several things returns a table, so the rendering is written once, in the runtime, rather than once per script. The [[col1 col2]; [a b] [c d]] syntax is the literal form — the header row, a semicolon, then the data rows.

The Nushell version reads close to SQL, and that is not an accident — a table is the same shape as a result set, so the vocabulary converges. What it buys over grep is that where city == "london" is checked against the column names: misspell citty and you get an error naming the column, while $_->{citty} in Perl is undef and the eq quietly fails to match, giving you an empty result and no clue. Turning on use strict does not help, because hash keys are not symbols.

The closure receives the whole row, so it can use any column, and the result is a table you can keep piping — | insert total {…} | where total > 20 | sort-by total reads as one sentence. Its siblings are worth learning together: insert adds a column and fails if it exists, update changes one and fails if it does not, and upsert does whichever applies. Perl's $order->{total} = … is all three at once, which is convenient right up to the typo that silently adds a column named totl.

Losing $_ costs a few characters and buys the thing Perl programmers work around constantly: nested maps. In Perl the inner block shadows $_, so the outer element has to be saved to a named variable first, and forgetting is a bug that produces plausible wrong output. In Nushell each { |outer| ... each { |inner| ... } } has both names in scope with nothing to remember. Note that where also accepts the shorthand form where age > 40 on a table, where the bare column name is understood — that form is not available on a plain list, which is why this row spells out the closure.

The argument order is the trap, and it is the reverse of what a Perl programmer expects: Nushell passes the element first and the accumulator second, so { |word, best| … } has the current word in word. Without --fold the first element becomes the initial accumulator, exactly like List::Util::reduce; with --fold 0 you supply a starting value, which is what you want when the list may be empty. Note also that $a and $b being globals is why a Perl reduce block cannot be a proper closure over them — a limitation with no analogue here.

enumerate turns a list into a table with index and item columns, which means the result is an ordinary table and every table command applies to it — you can where index > 1 or sort-by item without leaving the pipeline. The $#array notation is one of the corners of Perl that most reliably confuses newcomers, since it is off by one from the length; nothing here has that shape.

This is where the typed pipeline pays a visible dividend. Perl needs two different comparison operators — <=> for numbers, cmp for strings — and choosing wrong gives you a wrong answer rather than an error. sort-by age sorts integers numerically because they are integers, and sort-by name sorts strings alphabetically for the same reason. Add --reverse for descending order, and give several columns to break ties: sort-by city age.

The Perl version is genuinely clever and genuinely opaque — @{ ... } to dereference, autovivification to create, and a nested loop to sum, with the dereference syntax repeated in both places. The cost of that cleverness is that a typo in the key silently creates a new group. group-by returns a record whose keys are the group names and whose values are tables, and items walks that record giving you the key and the value together. $rows.total pulls one column out of a whole table, which is the move that makes this a one-liner.

Nushell has both jobs as flags on one command: uniq for the distinct values and uniq --count for a table of value and count, which is what the second Perl block builds by hand. The counting version returns a table, so it sorts and filters like anything else. Note that uniq here does not require sorted input the way the Unix uniq program does — that similarity of name to a very differently behaved tool is worth flagging, since a Perl programmer reaching for sort | uniq out of shell habit will find the sort unnecessary.

The section exists to say plainly: regex is still the right tool for genuinely unstructured text, and this page's argument is not that you should stop using it. What changes is how often you need it. In Perl a regex is also how you split a line into fields, pick out the third column and check that a value is a number, because there is no other structure to work with. Here those jobs belong to split column, get and into int, and the regex is left for the case it is actually good at. Note the single quotes: a Rust regex uses backslashes freely, and a single-quoted Nushell string passes them through untouched.

parse takes a template with named holes and returns a table, one row per match, with a column per hole. That is why the result is subscripted .0.name — it is a table even for one match, which means running it over a list of lines produces a table of everything, ready to where and sort-by. Perl's named captures (?<name>\w+) and %+ get halfway there, but you still write a loop to accumulate the results. When the template is not enough, parse --regex takes a full regex with named groups.

The flags line up: /g is --all, and a regex needs --regex because str replace takes a literal string by default. That default is the opposite of Perl's and it is the safer one — replacing a literal "1.2.3" in Perl requires remembering that . is a metacharacter, and here it requires nothing. Perl still wins outright on the harder end of this: /e to evaluate the replacement as code, and tr///, have no equivalent.

Losing the statement-modifier forms — say "chilly" unless $cold, say for @list — is the change a Perl programmer feels most, because those are what make Perl short. What you get back is that the value cannot be left unset: there is no path through the Nushell version where advice is undefined, whereas the Perl version relies on the else being there. Nushell's conditions are also strictly boolean; an empty string or a zero is not a condition, which is the subject of a Gotchas row below.

The reason this row is short is that you will rarely write it. for is a statement: it produces no value, so its body has to print or mutate to be worth anything, and that puts it in the same category as Perl's for with a side effect. Nearly every loop that computes something is a pipeline instead, and the pipeline is what composes. Reach for for when you genuinely want the imperative version — early exit, or a side effect per item — and for each the rest of the time.

Three things follow from that declaration. The parameters have types, so passing a string where an int is declared is an error at the call site rather than a surprise inside. Defaults are part of the signature, so //= is not needed. And help greet works — the signature is the documentation, where Perl needs POD written separately and kept in step by hand. The other visible change is the call: arguments are separated by spaces, not commas, because a command call is shell syntax rather than function syntax.

A flag declared with no type is a switch: --loud is true when passed and false otherwise, so there is no truthy sentinel to invent the way Perl's loud => 1 does. The larger point is that the command now behaves exactly like a builtin — it takes flags, it appears in help, it tab-completes, and a caller cannot tell it was not shipped with Nushell. A Perl sub taking %options is a convention that every caller and every reader has to recognize on sight.

That is the payoff of the whole design. [ada grace] | shout | str join " " puts your command in the middle of a pipeline exactly as where or sort-by would be, and it composes with everything because it speaks the same protocol — values in, values out. Perl's pipeline is the shell's, made of bytes between separate processes, so a Perl sub can never be a stage in one; the closest equivalent is a filter script, which pays a process launch and a round trip through text. You can declare the shape too, with def shout []: list -> list.

A Nushell closure has no mutable captured state by design: it may run once per row of a large table, and a shared mutable cell would make the order of evaluation observable. So there is no counter, no memoization and no object-in-a-closure, which are all real Perl patterns. What a closure is for here is being passed to a command — the block you hand each, where, insert or sort-by is exactly this value, which is why $scale can be stored in a variable and reused across both calls above. do is how you invoke one directly.

Both examples write the file first, because every run starts from an empty filesystem in the browser and each row here uses a filename prefix no other row uses. Two details on the Nushell side: lines splits the text and drops the trailing newline, so there is no chomp to forget; and save refuses to overwrite without --force, which is the opposite of > and has saved more files than it has annoyed people. The bigger surprise is in the next row.

The Perl column shows the honest alternative when a parser is not to hand: pull the field out with a regex, which works until the file is formatted differently. With JSON::PP — core since 5.14 — Perl is one decode_json call away, and the comparison becomes fair; the difference that remains is that Nushell decided for you based on the name, so there is no import and no chance of forgetting. When you want the raw text, open --raw gives it, and the from json family lets you parse text whose extension lied.

This is the thesis in its most concrete form. In Perl, -s, -M and -d each ask the filesystem again about a name you already have; in Nushell the columns name, type, size and modified came back with the listing, so "the three biggest files modified this week" is ls | where modified > (date now) - 7day | sort-by size --reverse | first 3 with no stat calls written at all. Note the size prints as 10 B rather than 10: it is a filesize value, not an integer, so it compares against 1mb correctly and formats itself when shown.

The third line is where the difference has teeth. Perl has no boolean type, so encode_json cannot tell 1 meaning true from 1 meaning one, and every JSON module ships sentinel objects — JSON::PP::true — that you must remember to use or your API sends "ok": 1. Nushell has a real bool, so true round-trips as true. The same gap explains why numbers sometimes serialize as strings from Perl: a scalar that has been used as a string remembers, and the encoder can only report what it sees.

The Perl column also shows the hash slice @row{@header} = @fields, which is a genuinely nice piece of the language: it assigns a whole list to a set of hash keys at once. It is still eight lines to produce what from csv produces in one, and it is still wrong on quoted fields. describe confirms the result is a table<name: string, age: int> — the ages parsed as integers, so they sort and sum correctly with nothing further asked. The whole from family works this way: from tsv, from yaml, from toml, from ssv for space-separated output from other tools.

The from X | to Y shape works for every pair the two families cover, which is the practical reason people install Nushell in the first place. The Perl version is not badly written — it is what you get from doing it honestly without Text::CSV — and note that its JSON output has the ages as strings, because split produced strings and nothing said otherwise, while the Nushell output has them as numbers. That is the typed pipeline showing up one last time in the place it matters most: the boundary where the data leaves your program.

The 1; at the end of the Perl block is not decoration — eval returns the block's last value, so a block that legitimately ends in 0 or "" is indistinguishable from one that died, and that is why the idiom exists. The $@ global has a matching hazard: anything running between the eval and the check can overwrite it, which is what Try::Tiny exists to fix. Nushell's catch receives the error as an ordinary value with msg, debug and raw fields, so there is no global and no sentinel return.

Which behavior you want depends on the day, and it is worth being honest about that: Perl's is what makes a throwaway one-liner over messy data work at all, and Nushell's is what stops a bad row from silently changing a total in a report somebody acts on. The Nushell column shows the middle path — try per element, and a count of what did not survive, which is the thing the Perl version cannot tell you: its total is 81 and looks entirely plausible. One behavior here is worth committing to memory: each drops any element whose closure returns null, so the failed conversion removes itself from the list and no compact is needed. That is convenient exactly until you return null by accident and quietly lose rows.

So if $count { … } is not a shortcut, it is an error — can't convert int to boolean, at the moment the line runs. You write if $count > 0, or if ($list | is-empty). That is more typing and it removes a category of bug: the Perl line say "found" if $count is wrong when a legitimate count of zero should still be reported, and it reads as correct. Note the narrowness of into bool too: it accepts a number, or the literal strings "true" and "false", and refuses everything else — "0" | into bool is an error rather than false. There is no coercion to fall back on, deliberately.

The difference that matters everywhere: an external command returns text, so the moment you call one you are back in Perl's world and must parse. That is why Nushell ships builtin equivalents of so many familiar tools — ls, ps, du, http get — and why ^ls | from ssv exists as the escape hatch for the ones it does not. The difference that only matters on this page: the in-browser build has no processes at all, so ^anything has nothing to dispatch to, which is why the second column demonstrates the replacement rather than the call.

each does exactly the same work in the same order, so nothing here is wrong — only slower on a large list than the same script would be at a terminal. It is worth knowing what the real thing costs elsewhere: because closures capture by value and nothing is shared, par-each needs no lock and no coordination, which is a considerably easier promise than threads makes in Perl, where the entire interpreter is cloned per thread. Result order is not guaranteed with par-each; pipe through sort-by if it matters.

The failure mode is quiet, which is why this is in Gotchas. add 2, 3 is not a syntax error — it passes the single string "2," and then 3, or fails on the type in this case, but in a command taking strings it would simply do the wrong thing. The other half of the rule is that a command call in an expression needs parentheses: print (add 2 3), because print add 2 3 would mean printing four separate things. Once both halves are internalized the syntax stops surprising you; until then it is the most common source of confusion on the page.

So an example must create every file it reads — which is why each file row above writes before it opens — and nothing one row leaves behind can be seen by another. That mirrors what a fresh shell would give you and removes a real hazard: without it, what a row printed would depend on which rows you had clicked first. It also means no def, no let and no environment change carries over, so each example is genuinely self-contained. At a real terminal, of course, all of that persists for the length of the session.