The idea of Nu runs deeper than just the shell, to being a language that's relatively easy to learn, yet powerful enough to do real work with your system, to process large amounts of data, to interactively let you iterate quickly on an idea, to invite exploration by building up a pipeline one piece at a time. There's really no shortage of ambition for where we hope to go.

# The design of Nu

Nu's original design has proven surprisingly robust thus far. Some of its core ideas are continuing to pay dividends a year later. Let's look at the designs that still feel right.

## Pipelines are infinite

When we first started writing Nu, we took a few shortcuts that had us processing all the data in a pipeline at once. Very quickly, we realize this wasn't going to work. External commands (think `cat /dev/random`) can output an infinite stream of data, and the system needs to be able to handle it. Understanding this, we transitioned to a different model: data flows between command as infinite streams of structured data. As the data is processed, we avoid collecting the data whenever possible to allow this streaming to happen.

Because the streams can be infinite, even the printing out of tables is done a batch at a time.

## Separating viewing data from the data itself

Coming from other shells, the idea of running `echo` or `ls` goes hand-in-hand with printing something to the terminal. It's difficult to see that there two steps going on behind the scenes: creating the information and then displaying it to the screen.

In Nu, these two steps are distinct. The `echo` command gets data ready to output into stream, but doesn't do any work to print it to the screen. Likewise, `ls` gets ready to output a stream of file and directory entries, but doesn't actually display this information.

That's because both `echo` and `ls` are lazy commands. They'll only do the work if the data is pulled from the stream. As a result, the step of viewing the data is separate from the step of creating it.

Behind the scenes, Nu converts a standalone `ls` to be the pipeline `ls | autoview`. The work of viewing comes from `autoview` and it handles working with the data and calling the proper viewer. In this way, we're able to keep things as structured data for as long as possible, and only convert it to be displayed as the final step before being shown to the user. (note: the wasm-based demo and jupyter do a similar step, but instead of adding `autoview`, they add `to html`)

## Rich data types

In a similar way to working with structured data, rather than only plain text, Nu takes a different approach to data types as well. Nu takes the traditional set of basic types, like strings and numbers, and extends them into a richer set of basic data primitives.

Numbers are represented internally as big numbers and big decimals, rather than integers and floating point machine-based representations. This gives us more flexibility to do math more accurately, and generally removes the worry of whether the number you want to work with will fit in the integer or float size you have available.

We carry this further, by also representing values common in modern computer usage: URLs, file paths, file sizes, durations, and dates are all examples of built-in data types. By building them in, Nu can have better syntax and type checking with their use.

For example, in Nu it's possible to write `= 1min + 1sec` to create a duration that is one minute one second long. You can also use the file sizes, like being able to filter a directory list by the size of the file `ls | where size > 10kb`.

Nu also can help if you try to mix types that shouldn't. For example, if you had written: `= 1min + 1kb` it seems you didn't mean to add time and file sizes together, and Nu gives you an error if you do:

```
error: Coercion error
  ┌─ shell:1:3
  │
1 │ = 1min + 1kb
  │   ^^^^   --- filesize(in bytes)
  │   │
  │   duration
```

_note: we'll be making this error better in the future_

Data in Nu also isn't just the value, but it's also a set of metadata that comes with the value. For example, if you load data from a file using the `open` command, we track the place that it's loaded along with the data that's loaded. We can see this metadata using the `tags` command: