Nuon is a superset of JSON, allowing you to pass JSON files and parse them as Nuon. Additionally, Nuon supports the data forms from Nushell, including compact tables, durations, filesizes, and more.

```
# sample.nuon
[
    # The nuon compact table format
    [[a, nuon, table]; [1, 2, 3], [4, 5, 6]],

    # A filesize
    100kib,

    # A duration
    100sec,

    # A date
    2022-01-11,

    # A boolean
    true,

    # A record
    {name: "Bobby", age: 99},

    # Binary data
    0x[11, ff, ee, 1f]
]
```

Nuon is still experimental, but we're already enjoying using it and are eager to continue to improve on it.

# Smaller release size

The 0.60 release is significantly smaller than the previous 0.44 release.

| release file for 0.44.0 | size    |
| ----------------------- | ------- |
| nu_0_44_0_linux.tar.gz  | 103 MB  |
| nu_0_44_0_macOS.zip     | 79.7 MB |
| nu_0_44_0_windows.msi   | 55.5 MB |
| nu_0_44_0_windows.zip   | 57.9 MB |

| release file for 0.60.0 | size    |
| ----------------------- | ------- |
| nu_0_60_0_linux.tar.gz  | 14.8 MB |
| nu_0_60_0_macOS.zip     | 12.9 MB |
| nu_0_60_0_windows.msi   | 10.1 MB |
| nu_0_60_0_windows.zip   | 10.1 MB |

# New Engine

Nicknamed "engine-q", the new engine grew from being a rewrite of parsing and evaluation logic into a full rewrite of Nushell itself. Done over 8 months, the final result has many improvements over the 0.44 engine.

## The new delta system

One powerful new aspect of the new engine is its delta system. Deltas, or change sets, let the engine stay immutable except at key phase shifts. For Nushell, after the user has hit enter in the repl, it will phase shift into parsing, then take a delta of what was given by the user. This delta may contain new definitions, new variables, new modules and more. This delta is merged into the permanent state inside of the engine. After this, the engine returns to being immutable as evaluation begins.

These discrete phase shifts make it possible to limit what mutates while maintaining flexibility, including the ability for users to write parallel code against the engine at any point of evaluation.

Mutation during evaluation isn't removed, instead it's isolated to the stack.

## Stacks, the site of change

For evaluation, stacks are now the site of change in the engine. Stacks are represented as vectors that are passed around during evaluation. They include changes to the environment, newly shadowed variables, and more.

## Closing over variables

Another important aspect of the engine and the new uses of stacks is an increased focus on correctness for how blocks work with stacks. In 0.60, we've eliminated many bugs related to variables scopes, where sometimes variables would "leak" from one scope to the next. Now, a "snapshot" of a variable's value is captured when the block is taken as a value in the system. This allows us easy access to run the block later and always have the correct state to run it with.

## Spans for better errors

Another important area of correctness we wanted to fix from previous versions of Nushell was error spans. Prior Nushell versions struggled with a very common pattern: errors that happen in code that isn't the code you just typed. For example, aliases that failed, calls to custom commands that were previously defined, and more.

In 0.60, along with keeping around code that's still available for the user to call, we also keep around the original span information and original source. This allows us to give better errors for the cases where the error refers to code that's not the current line.

## Bind once, run anywhere

While improving the parser and engine, we also improved how the two connected to each other. One piece of this was "binding", that is, how definition sites and use sites connect to one another.

In the new engine, we use unique identifiers for all forms of definition in the engine, including variables, declarations, aliases, modules and more. During parse time, we bind the use we see against the definition in scope, and replace the use with a reference to the ID we found. With this, we can later safely export or pass the containing block without losing track of what the original code meant.