Nu takes this one step further. The error reporting system comes from the design of [Rust's error messages](https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html), with clear messages to help guide you to success.

The goal for Nu is that it won't require you to be a wiz with the commandline or with complex programming practices. Instead, you start where you feel comfortable, and grow a line at a time. With Nu, as your comfort grows, single lines easily grow to multiple lines, and (eventually) to larger programs. You don't need separate styles of thinking when experimenting and another for building your application. In Nu, these are (or will be) one and the same.

## Crossplatform

One of the first decisions we made in making Nu is that it should not only be cross-platform, but should feel as native as possible across platforms. Commands should work the same, regardless of the platform you're on, without any loss of functionality if you switch from one OS to another. This has meant saying "no" a few times when someone offered to a cool feature, only to find out it didn't work well on one of the supported systems. The benefit, though, is that Nu users can move between OSes comfortably.

Nu lets you use common shortcuts, too. In Windows, you can change drives using the common `D:` shorthand. You can use `cd ~` and `cd -` as easy shorthands to jump between home and previous directories, too.

## Getting `$it` right

Early on, when we were first brainstorming how something like Nushell might work, we rediscovered the idea of iteration having its own special variable. The iteration variable, item variable, or simple the "it" variable, gave us a way to talk about the current row of data flowing through the pipeline. When we can talk about the current row, it was then easier to say how to handle the current row.

The simplest version is:

```
ls | echo $it
```

To `echo $it` doesn't really do anything interesting, it just passes along the value it was handed. It's when we combine this with variable paths that things get a little more interesting:

```
ls | echo $it.name
```

Now, in 4 words we've asked Nu to list all the files in the current directory and output only the names. This pipeline, if there are 100s of thousands of files, will happily stream out its results as it finds new files. As in this case:

```
ls **/* | echo $it.name
```

Once you have a mental model for using `$it`, it becomes common to grab it when working on data a row at a time.

A note for those wondering how this works under the hood: if an `$it` is found a part of an argument not otherwise inside of a block, it's "it-expanded". We replace the command with a call to `each` and the block.

This turns:

```
ls | echo $it.name
```

Into:

```
ls | each { echo $it.name }
```

The `each` command handles walking along each row and calling the block each time, setting the variable `$it` to the current row value.

## Everything is a macro

In Nu, a command has the form `<cmd> <arg1> <arg2>`. To the lisp-lovers among you, this should look very familiar. Slap on a pair of parens and you have yourself an s-expression.

You may be wondering - if you choose a cmd-arg-arg form, how do you write something like:

```
where size > 10kb
```

This is where Nu's parser steps up. The parser we use is a type-driven, recursive descent parser. If you look at the signature for the `where` command in the Rust code, you'll see it says:

```rust
Signature::build("where").required(
    "condition",
    SyntaxShape::Math,
    "the condition that must match",
)
```

That is, the `where` command takes a single parameter, a `condition`, which has a SyntaxShape of Math. This shape drives the parser to use different parser logic.

In math mode, we can now parse an expression using operator precedence. The `where` command tells the parser to treat all of the free parameters as a single expression, to parse that expression, and to pass it as the single argument. The canonical form is more precise, though a bit more cumbersome: