R.CodeCompared.To/Nushell

That last point is why every R example on this page prints explicitly. A script run with Rscript — and the WebR runtime behind the R column — does not auto-print a top-level value, so a bare x that shows a result at the console produces nothing at all. Nushell is the opposite: the last pipeline of a script prints itself, and only the ones before it need print.

The [1] is a vector-indexing aid that becomes noise when you only wanted the numbers, which is exactly why R users reach for cat in scripts and print at the console. Nushell has one printer and it renders each type in its own way — a list as a bordered table, a record as key-value rows, a string as itself. That is why the first Nushell line here draws a table where the R line draws [1] 10 20 30: neither is decoration, both are the runtime showing you the shape of what you have.

filter is where, select is select, mutate is insert or update, group_by plus summarize is group-by plus items, and arrange is sort-by. The base-R version is shown here rather than the dplyr one so that the comparison does not depend on a package, but the dplyr spelling is the closer match and the next rows use it. What Nushell adds is not a better pipeline; it is that this same pipeline reaches outside the process — over the filesystem, an HTTP response or another program's output — which is the subject of the last two sections.

The difference that matters is what a stage can be. In R, every stage is a function call, so a pipeline lives inside one R process and the things it can reach are the things loaded into that process. In Nushell every stage is a command, and a command may be a builtin, one you defined, or an external program, so the same syntax spans "sort this list" and "read every file in this directory". R's equivalent of the second is system(), which hands back a character vector you must then parse — the one place where an R user meets the problem this page is about.

So every elementwise operation becomes an explicit each, which is more typing and — unlike Python, where the answer is to install numpy — has no library that gives it back. Read that as a genuine cost of the language, not a hidden feature you have yet to find. Two things soften it: the math commands (math sum, math avg, math sqrt, math stddev) do work over a whole list, and a table column pulled out with get age is a list you can feed straight to them. What has no counterpart at all is R's recycling, where a short vector repeats to meet a long one — and given how many R bugs recycling has caused silently, losing it is not obviously a loss.

That single fact explains most of the differences on this page. Because everything in R is a vector, an operator can be elementwise, a function can accept any length, and if historically took the first element of a longer condition — a source of bugs so persistent that R 4.2 made it an error. Because a Nushell value is either a scalar or a container, an operation on the wrong one is caught rather than broadcast, and length on an integer is an error rather than 1. Neither model is better in the abstract; the R one is built for data analysis and the Nushell one for a shell where a filename is a filename.

The $ asymmetry catches everybody: it is let name = … to bind and $name to read, because the sigil belongs to the reference rather than the name. As for mut, you will need it less than you expect, because the accumulate-in-a-loop pattern is a pipeline here. Note also the rule with no R analogue: a mut variable cannot be captured by a closure, so each { |item| $total += $item } is rejected — which pushes you to reduce, and which exists because a closure may one day run in parallel.

R gives you the appearance of value semantics through an optimization: the vector is shared until somebody writes to it, and then it is copied. That is why a large data frame can quietly double in memory at an assignment, and why tracemem exists. Environments and R5/R6 reference classes escape it entirely and do alias. In Nushell there is no modification operation at all, so nothing is copied on write because nothing is ever written — update returns a new list, and the old one and the new one may share whatever the runtime finds convenient with no observable difference.

Off-by-one is the least of it — see the next row for the part that actually bites. Two smaller notes: there is no length(x)-based way to reach the end here, because last exists and reads better; and indexing past the end gives an error in Nushell rather than R's NA, which is one place the stricter language saves you from a silently wrong result.

Nushell has no negative indexing at all, which removes the ambiguity rather than resolving it — skip and drop say which end and how many, and last gets the final element. The range rule is worth pinning down because it is the one thing that does match: slice's range is inclusive at both ends, exactly like R's 2:3, so only the zero base moves. That makes numbers[2:3] into slice 1..2, which is a subtraction rather than the off-by-one-at-one-end conversion that Python would demand.

One R behavior to leave behind: $ does partial matching, so person$na returns the name field, and a typo can silently resolve to the wrong element. [[ ]] does not, which is why careful R code prefers it. Nushell has no partial matching anywhere — $person.na is a Name not found error that suggests name. Note also that names() becomes columns, because a record and a single table row are the same thing here.

That difference in construction is real. A data frame is fundamentally column-major: each column is a vector of one type, which is what makes people$age free and vectorized arithmetic over it natural. A Nushell table is row-major, so get age gathers a column by walking the rows, and there is no promise that every row has the same columns — a table with a missing cell is legal and shows as empty. For analysis work that is a downgrade; for a shell, where the rows come from a directory listing or a JSON array, it is the honest shape.

The third line is where the two diverge in readability. R's people[people$age > 40, "name"] repeats the data frame name inside its own subscript, which is why dplyr exists and why filter(people, age > 40) reads so much better. Nushell's where age > 40 is closer to the dplyr spelling than to the base-R one — the column names are in scope inside the condition, with no $ and no repetition. Note that get on a missing column errors rather than returning NULL, which is the general pattern: this language would rather stop than hand you nothing.

insert adds a column and fails if it is already there, update changes one and fails if it is not, and upsert does whichever applies. R's orders$total <- … is all three at once, which is convenient right up to the typo that silently creates a column named totl beside the one you meant. The closure receives the whole row, so any column is available — and note the vectorization difference: R computes price * quantity as one vector operation over the whole column, while Nushell runs the closure once per row.

The -people$age trick for descending order is a small piece of R folklore worth naming: it works because negating the values reverses their order, which means it does not work on a character column at all — you need order(people$name, decreasing = TRUE) there. Nushell's --reverse is a flag on the command, so it applies to any type. Multiple sort keys work the same way in both, listed in priority order.

dplyr closes that gap with select(people, -secret), which is the fair comparison and reads well; the base-R version is shown to make the point that a verb has to exist somewhere. reject is the exact counterpart and, like select, takes several names. Both error on a missing column; reject --optional is the lenient form, for when the only goal is that the column not be there.

R wins on brevity here and it is worth saying so; the formula interface is one of the language's genuinely good ideas, and dplyr's group_by(customer) |> summarize(total = sum(total)) is barely longer. What Nushell gives back is that the intermediate is an ordinary value you can look at: group-by customer alone returns a record whose keys are the customers and whose values are whole tables, so you can inspect it, filter it, or summarize several ways without recomputing. items is what walks a record giving you each key and value together, and $rows.total pulls one column from a whole table.

The difference in return type is the whole comparison. R's table gives you an object with its own printing, its own names(), and its own quirks — sorting it keeps the names attached, but turning it into a data frame needs as.data.frame and produces columns called Var1 and Freq. Nushell's uniq --count returns an ordinary table with value and count columns, so every table command already applies and nothing needs converting. Plain uniq, with no flag, gives just the distinct values, which is R's unique().

What disappears with sapply is its most notorious property: it simplifies the result, returning a vector when it can and a list when it cannot, so the type of what you get back depends on the data rather than on the code. That is why vapply exists and why tidyverse code uses the map_* family with the type in the name. each over a list always returns a list. Note reduce's argument order, which is the reverse of R's: the element comes first and the accumulator second, so it is { |number, total| … }. --fold supplies the initial value, and without it the first element becomes it.

The R version has a trap that has bitten every R user at least once: apply converts the data frame to a matrix first, and a matrix has one type, so a data frame with any character column turns every number into a string and the multiplication fails or lies. That is why rowwise() and pmap exist in the tidyverse. Nushell's each over a table hands you a real record per row with every value keeping its own type, because a table was always a list of records. This row is the clearest case on the page where the shell's model is the better fit.

The three lines show three different answers to the same question. R's sum(values) returns NA because it genuinely does not know the total, and na.rm = TRUE is you stating that you accept an answer computed from what is there. Nushell's math sum does neither — it refuses the list outright with only list<number> … is supported, because [1 2 null 4] is not a list of numbers. So you must call compact, which is na.rm = TRUE spelled as a pipeline stage. The third line is the one to remember: NA > 1 is NA in R, so a comparison involving missing data is itself unknown, while null == 1 is plainly false. For statistics that contagion is the point and losing it is a real loss; for a shell, where a null is a directory entry with no size rather than an unrecorded measurement, plain false is right. If missingness matters in your data, count the nulls yourself, because nothing here will remind you.

The substring row is the one to write down. R's substr(x, 1, 5) is 1-based and inclusive; Nushell's str substring 0..4 is 0-based and also inclusive, so the conversion is "subtract one from both ends" rather than the mixed adjustment other languages need. Two Nushell details: str upcase and str downcase were deprecated in 0.114 in favor of str uppercase and str lowercase, and str replace replaces the first match by default — R's gsub is global and its sub is not, so gsub maps to str replace --all.

The R detail worth remembering here is that paste is vectorized: given vectors it returns a vector of results, which is enormously useful and also why paste with a stray length-3 vector silently produces three strings where you wanted one. And strsplit returns a list of character vectors even for a single input, which is why the [[1]] is there — a wart the tidyverse's str_split_1 was added to fix. Nushell's split row returns the list directly, and there is no vectorization to be surprised by.

Two R details that cost people time: grep returns indices by default and the matched values only with value = TRUE, and backreferences in a replacement are written \\1 — doubled, because R string literals process backslashes before the regex engine sees them. Nushell's parse takes a different approach to extraction entirely: it returns a table with a column per named group, so running it over a whole list gives you a table of everything, ready to filter and sort. The single quotes matter — a single-quoted Nushell string passes backslashes through untouched, which is what a regex wants.

That third R line is the loss. R lets any argument be passed by name in any order, with partial matching on the name — a genuinely convenient feature that also means greet(gr = "Hi") works and greet(g = "Hi") is ambiguous only if another parameter starts with g. Nushell's positional parameters are positional; anything you want to pass by name is declared as a --flag, which is the next row. In exchange, the signature is real documentation: the third Nushell line pulls it out of greet --help, which prints > greet <name> (greeting) — required parameters in angle brackets, optional ones in parentheses, generated from the declaration and impossible to leave stale. R needs a separate .Rd file or roxygen comments kept in step by hand.

So loud = FALSE as a default disappears — --loud needs no default because absence is the default. The larger point is that the command now behaves exactly like a builtin: it takes flags, it appears in help, it tab-completes at the prompt, and a caller cannot tell it was not shipped with Nushell. An R function with named arguments is just an R function; there is no sense in which report becomes part of the language's command vocabulary, because R has no command vocabulary to join.

The distinction sounds academic until you want both. A Nushell command can take pipeline input and positional arguments and flags, each in its own place, so $data | my-report --format json has nowhere for the three to collide. In R everything is a parameter, so a function that is pipeable and also configurable relies on the first parameter being the data by convention, and nothing enforces it — which is exactly why base R's inconsistency here (sapply(X, FUN) against Map(f, ...)) makes some functions awkward to pipe into. The : list -> list annotation declares the input and output types and is optional.

Both columns write the file before reading it, and both use a filename prefix no other row on this page uses. That is not tidiness: in the browser every run starts from a fresh engine and an empty filesystem, so an example must create whatever it reads, and locally the examples share a real temporary directory where one row could otherwise pick up another's leftovers. Two small Nushell notes: lines drops the trailing newline so there is no chomp equivalent to forget, and save refuses to overwrite without --force, which is the opposite of R's silently-clobbering writeLines.

Nushell's ls returns a table with name, type, size and modified already filled in, so "the three biggest files modified this week" is ls | where modified > (date now) - 7day | sort-by size --reverse | first 3 with no second trip to disk. R can get there with file.info(), which does return a data frame — but you have to know to ask, and you have to pass it the names you already got. The size also prints as 10 B rather than 10, because it is a filesize value that compares correctly against 1mb and formats itself when shown. This is the concrete form of the claim that the pipeline reaches outside the process.

That consequence is the honest limit of everything above: the moment you call an external program you are back to parsing text, in either language. Nushell's answer is to ship builtin equivalents of the tools you would otherwise shell out to — ls, du, ps, http get — so the escape hatch is needed less often, and to provide from ssv, from json and friends for when it is. R's answer is a package per tool. The in-browser build on this page has no processes at all, which is why the second column demonstrates the parsing rather than the call.

Two pieces of R history are visible in that call. stringsAsFactors = FALSE had to be written on every read.csv until R 4.0 changed the default, because character columns were silently converted to factors and comparing one against a string then failed in ways that took an afternoon to find. And read.csv guesses types by scanning, which is why a column of identifiers with a leading zero arrives as an integer with the zero gone. Nushell infers types too and has the same class of hazard; describe is how you check what you actually got, and it is worth the habit in both languages.

The regex in the R column is not a straw man — it is what people actually write when they need one field out of a small JSON blob and do not want a dependency for it, and it breaks the moment the key order changes or a nested object contains the same key name. With jsonlite, fromJSON(text)$port is one line and the comparison becomes fair. What remains is that Nushell has no dependency to install and no import to write, and that the same from family covers YAML, TOML, XML and INI with identical syntax — so a script that reads a config file does not care which format the config is in.

The R column shows the hand-rolled version, and note what apply did to it: converting the data frame to a matrix turned the ages into strings, which is why they have to be pasted in unquoted by hand and why a value containing a quote would produce invalid JSON. jsonlite::toJSON(people) is the real answer and is one line. The durable difference is not the line count but the coverage: from X | to Y works for every pair Nushell knows, so CSV to JSON, TOML to YAML and XML to CSV are the same command with different words, where R needs a package per format and each has its own conventions about what a row is.

So if $count { … } is not a shortcut, it is an error — can't convert int to boolean, at the moment the line runs. And sum(x > 5), which counts matches by relying on logicals being numbers, becomes $x | where {|value| $value > 5} | length — the last line of each column shows the same count reached the two different ways. into bool exists for deliberate conversion and is narrower than you would guess: it takes a number, a string holding a number, or the strings "true" and "false", and errors on anything else, so "0" | into bool is false while "yes" | into bool is an error. Losing R's coercion costs brevity and removes the class of bug where a legitimate zero silently reads as "nothing here".

The failure mode is quiet, which is why this is a gotcha rather than a note. add 2, 3 is not a syntax error — it passes the string "2," and then 3, which errors on the type here but would do something wrong and silent in a command taking strings. The other half of the rule is that a command call used as an expression needs parentheses: print (add 2 3), because print add 2 3 means printing four separate things. Once both halves are internalized the syntax stops surprising you, and until then it is the most common source of confusion.

each does the same work in the same order, so nothing on this page 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 Nushell closures capture by value and nothing is shared, par-each needs no lock and no cluster setup, which is a much smaller promise than R's parallel package makes with its fork-or-socket-cluster choice and its rules about what can be sent to a worker. Result order is not guaranteed with par-each; pipe through sort-by when it matters.

So an example must create everything it reads, and nothing one row leaves behind is visible to another. That is the opposite of the R habit, where the workspace persists across an entire session and a variable defined an hour ago is still there — the reason rm(list = ls()) is a reflex before running a script, and the reason a script that works interactively can fail from a clean session. Treat every row on this page the way you should treat an R script: as if nothing exists that it did not create.