# Julia included in Oreilly's "Emerging Programming Languages" report (June 2019)

**URL:** <https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562>\
**Category:** Community\
**Created:** [June 23, 2019, 6:12am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562 "2019-06-23T06:12:25Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![essenciary](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/essenciary/32/210469_2.png) [@essenciary](https://discourse.julialang.org/u/essenciary)\
**Post date:** [June 23, 2019, 6:12am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/1 "2019-06-23T06:12:25Z")

</div>

It’s a nice and positive presentation of the language, although superficial compered to the others they covered:

> **[Emerging Programming Languages](https://www.oreilly.com/library/view/emerging-programming-languages/9781492082590/)**
>
> C++, Java, Python, and other established programming languages may yet be with us for a long time, but our current software development landscape has given rise to new languages that … - Selection from Emerging Programming Languages \[Book\]

---

<div class="post-metadata">

**Author:** ![ninjaaron](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ninjaaron/32/6392_2.png) [@ninjaaron](https://discourse.julialang.org/u/ninjaaron)\
**Post date:** [June 23, 2019, 12:15pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/2 "2019-06-23T12:15:19Z")

</div>

> Julia is an enormous language

You reckon this is true? It seems kind medium-sized to me–though I have to admit, the apparent eagerness of the core devs to add syntax is the only significant source of trepidation I have about the language. I don’t feel like it’s enormous yet, but it does seem like it could get that way if a more restrained approach to adding features isn’t taken in the future.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [June 23, 2019, 12:40pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/3 "2019-06-23T12:40:02Z")

</div>

> [@ninjaaron](#):
>
> apparent eagerness of the core devs to add syntax

I am not quite sure what you mean here, can you give a few examples? I feel kind of the opposite: extra syntax is usually added after careful consideration. Eg [#24990](https://github.com/JuliaLang/julia/pull/24990).

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [June 23, 2019, 1:44pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/4 "2019-06-23T13:44:40Z")

</div>

> [@ninjaaron](#):
>
> You reckon this is true? It seems kind medium-sized to me–though I have to admit, the apparent eagerness of the core devs to add syntax is the only significant source of trepidation I have about the language. I don’t feel like it’s enormous yet, but it does seem like it could get that way if a more restrained approach to adding features isn’t taken in the future.

> [@Tamas\_Papp](#):
>
> I am not quite sure what you mean here, can you give a few examples? I feel kind of the opposite: extra syntax is usually added after careful consideration. Eg [#24990](https://github.com/JuliaLang/julia/pull/24990).

I think it’s just perspective. Someone who doesn’t do technical programming for a living looks at Julia and goes "man, they have a lot of weird extra syntax for math people like `\`, `mul!` vs `*`, `@.`, `Tridiagonal`, etc., while omitting the things people are used to seeing in a basic language implementation like a web server (yup, quite a few languages have on in there) or graphics engine (usually much bigger than the entirety of Julia). But when you see something you don’t expect, you go “they add a lot of peculiar things”.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [June 23, 2019, 1:56pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/5 "2019-06-23T13:56:12Z")

</div>

It is possible that I understand syntax in the narrow technical sense (syntax is what the parser eats).

For me `Tridiagonal`, `mul!`, and `*` are not syntax; `@.` is. 😉

---

<div class="post-metadata">

**Author:** ![rfourquet](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rfourquet/32/3610_2.png) [@rfourquet](https://discourse.julialang.org/u/rfourquet)\
**Post date:** [June 23, 2019, 2:08pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/6 "2019-06-23T14:08:47Z")

</div>

Probably one example at [I wrote a guide about Object Orientation and Polymorphism in Julia. opinions wanted! - #48 by ninjaaron](https://discourse.julialang.org/t/i-wrote-a-guide-about-object-orientation-and-polymorphism-in-julia-opinions-wanted/25425/48)

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [June 23, 2019, 2:16pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/7 "2019-06-23T14:16:46Z")

</div>

I understand `*` and `\` as syntax, but not the rest, they are just names. Actually, even those are just operators, not sure if they count as syntax. The `@` itself is syntax.

---

<div class="post-metadata">

**Author:** ![tk3369](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tk3369/32/2824_2.png) [@tk3369](https://discourse.julialang.org/u/tk3369)\
**Post date:** [June 23, 2019, 6:31pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/8 "2019-06-23T18:31:08Z")

</div>

The goal of this report seems ambitious but IMO it does not have enough details for any language. I think it needs to go just a little bit deeper to be useful. I’m pleased to see Julia gets covered though.

---

<div class="post-metadata">

**Author:** ![ninjaaron](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ninjaaron/32/6392_2.png) [@ninjaaron](https://discourse.julialang.org/u/ninjaaron)\
**Post date:** [June 23, 2019, 9:24pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/9 "2019-06-23T21:24:17Z")

</div>

> [@Tamas\_Papp](#):
>
> I am not quite sure what you mean here, can you give a few examples? I feel kind of the opposite: extra syntax is usually added after careful consideration. Eg [#24990](https://github.com/JuliaLang/julia/pull/24990).

Well, it’s encouraging to see that they are being careful about it. It would be more encouraging to see some examples of extra syntax being _rejected_ after careful consideration–though not necessarily this specific case. I’m biased towards anything that helps with pipelines.

For me, the canonical example is the for loops. `for x in xs` vs. `for x ∈ xs` vs. `for x=xs`. I realize that the the first two are alternate ways to write the `in` operator (because every languages needs two of those, right?), but the `for x=xs` definitely qualifies as additional syntax.

Then you’ve got comprehensions syntax vs. the usual functors (map, filter and friends) vs. dot broadcasting. I like all of those things, but they are all sight variations on the same concept.

`import` vs. `using`

Splatting with `...` vs. array concatination with `;`. I realize these are quite different… but then they are kind of the same when defining a new array, only you’re supposed to use `;` if it’s an array you’re “splatting” into your new array, but not necessarily a lazy iterable. I do admit that I find the syntax for array literals in general to be a bit overwhelming, but I suspect that is because I never use multi-dimensional arrays, and I assume the extra syntax is necessary for those who do, so that’s not one of the ones that bugs me.

> [@rfourquet](#):
>
> Probably one example at [I wrote a guide about Object Orientation and Polymorphism in Julia. opinions wanted!](https://discourse.julialang.org/t/i-wrote-a-guide-about-object-orientation-and-polymorphism-in-julia-opinions-wanted/25425/48)

Yes, and that’s the latest one I’ve discovered. Another related one which no one has been able to explain to me is the difference between `Array{T,1} where T` and `Array{T,1} where {T}`. If they are the same, why are they both supported? (I don’t know if they are the same, but nobody knew a difference when I asked)

I will say that generics _in gnereal_ are one area where Julia definitely hits the jackpot in terms of giving a lot of expressiveness with very little syntax.

I give all _explicitely marked_ macros a pass. `@` is syntax, but every little micro DSL I just file away under that single feature. Places where the languages transforms something with macros implicitly, that’s syntax. I’m actually very pleased that most of Julia’s concurrency features are wrapped up in explicit macros rather than new keywords, since you can see how all of it works with `@macroexpand`.

> [@ChrisRackauckas](#):
>
> I think it’s just perspective. Someone who doesn’t do technical programming for a living looks at Julia and goes "man, they have a lot of weird extra syntax for math people like `\` , `mul!` vs `*` , `@.` , `Tridiagonal` , etc., […]

Of these features, `\` is the only one I find a little unnecessary, but I’m generally willing to ignore “math stuff” I don’t use because I assume it’s there for a reasons and I never really have to deal with it. The thing I might object to a wee tiny bit is all the functions that have some alias to a unicode operator, but I try to suspend my misgivings about this because I can imagine its helpful to be able to express oneself in code the same way one would in a paper–on the other hand, I know a physicist who does technical computing for a living and is much harder on Julia’s novel math syntax than I am, but I’ll leave that discussion to the domain experts.

In the end, It’s not any one bit of syntactic sugar that’s too much, it’s just the number of cases where there are multiple ways to the same or nearly the same thing reminds me a bit of Perl. I don’t think Julia is an enormous language… I just… don’t want it too be one, either!

It was more just when I read this sentence in the report that I was like, “oh, maybe I’m not just paranoid.”

They are probably including macros or something, or maybe all the functions in the default namespace (which is admittedly way more than most languages, but that doesn’t bother me. A function is a function.)

---

<div class="post-metadata">

**Author:** ![WschW](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wschw/32/6575_2.png) [@WschW](https://discourse.julialang.org/u/WschW)\
**Post date:** [June 23, 2019, 10:26pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/10 "2019-06-23T22:26:14Z")

</div>

> [@ninjaaron](#):
>
> Yes, and that’s the latest one I’ve discovered. Another related one which no one has been able to explain to me is the difference between `Array{T,1} where T` and `Array{T,1} where {T}` . If they are the same, why are they both supported? (I don’t know if they are the same, but nobody knew a difference when I asked)

They are the same. However the second one is more compact when writing of more complex types, for example `SArray{S, T, L} where S where T where L` can be shortened to `SArray{S, T, L} where {S, T, L}`

---

<div class="post-metadata">

**Author:** ![tkf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkf/32/17635_2.png) [@tkf](https://discourse.julialang.org/u/tkf)\
**Post date:** [June 24, 2019, 12:13am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/11 "2019-06-24T00:13:26Z")

</div>

> [@ninjaaron](#):
>
> but the `for x=xs` definitely qualifies as additional syntax

I do feel the same.

> [@ninjaaron](#):
>
> `import` vs. `using`

I think the difference is clear once you know it:

- `using M` if you want all symbols exported from `M`
- `import M` if you only want `M` to be in your namespace
- `using M: f, g` if you only want to call functions
- `import M: f, g` if you want to extend functions (without fully qualifying them like `M.f`)

> [@ninjaaron](#):
>
> Places where the languages transforms something with macros implicitly, that’s syntax. I’m actually very pleased that most of Julia’s concurrency features are wrapped up in explicit macros rather than new keywords, since you can see how all of it works with `@macroexpand` .

FYI you can also expand native syntaxes using `Meta.@lower`. For example,

```julia
julia> Meta.@lower x[y] .= f.(z)
:($(Expr(:thunk, CodeInfo(
1 ─ %1 = (Base.dotview)(x, y)
│ %2 = (Base.broadcasted)(f, z)
│ %3 = (Base.materialize!)(%1, %2)
└── return %3
))))

```

Once I realized that many syntax magics happen at lowering phase, it felt like Julia is more minimalistic (compared to the impression before realizing it).

---

<div class="post-metadata">

**Author:** ![Azamat](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/azamat/32/6892_2.png) [@Azamat](https://discourse.julialang.org/u/Azamat)\
**Post date:** [June 24, 2019, 1:05am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/12 "2019-06-24T01:05:59Z")

</div>

> [@WschW](#):
>
> `SArray{S, T, L} where S where T where L` can be shortened to `SArray{S, T, L} where {S, T, L}`

It shortens to `SArray{S, T, L} where {L, T, S}`.

---

<div class="post-metadata">

**Author:** ![WschW](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wschw/32/6575_2.png) [@WschW](https://discourse.julialang.org/u/WschW)\
**Post date:** [June 24, 2019, 2:22am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/13 "2019-06-24T02:22:43Z")

</div>

It is still equivalent which is my point.

```julia
julia> (SArray{S,T,L} where {S, T ,L}) == (SArray{S,T,L} where {L, T, S})
true

```

---

<div class="post-metadata">

**Author:** ![Azamat](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/azamat/32/6892_2.png) [@Azamat](https://discourse.julialang.org/u/Azamat)\
**Post date:** [June 24, 2019, 3:04am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/14 "2019-06-24T03:04:26Z")

</div>

Equivalent in _some_ context (where the order of `S,T,L` does not matter), different in other (where their order does matter).

`SArray{S, T, L} where {S, T, L}` is the same as `SArray{S, T, L} where L where T where S`.

---

<div class="post-metadata">

**Author:** ![WschW](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wschw/32/6575_2.png) [@WschW](https://discourse.julialang.org/u/WschW)\
**Post date:** [June 24, 2019, 3:43am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/15 "2019-06-24T03:43:52Z")

</div>

While for printing, `===` or directly observing the fields they are different but from a type standpoint in Julia they are the same.

```julia
julia> (SArray{S,T,L} where {S <: Int, T <: Real ,L <: Complex}) <: (SArray{S,T,L} where {L <: Complex, T <: Real, S <: Int})
true

julia> (SArray{S,T,L} where {L <: Complex, T <: Real, S <: Int}) <: (SArray{S,T,L} where {S <: Int, T <: Real ,L <: Complex})
true

julia> (SArray{S,T,L} where {L <: Complex, T <: Real, S <: Int}) == (SArray{S,T,L} where {S <: Int, T <: Real ,L <: Complex})
true

```

If Julia took order into account while determining specificity in type dispatch, like Common Lisp, it may have mattered that the expression after the where was in a different order but Julia does not.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [June 24, 2019, 4:05am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/16 "2019-06-24T04:05:50Z")

</div>

> [@ninjaaron](#):
>
> It would be more encouraging to see some examples of extra syntax being _rejected_ after careful consideration

Are you following discussions here, and issues and PRs on Github? At this stage of the language, many (I would say most) proposals for syntax changes are actually _rejected_.

> [@ninjaaron](#):
>
> comprehensions syntax vs. the usual functors (map, filter and friends) vs. dot broadcasting. I like all of those things, but they are all sight variations on the same concept.

Not really. They have an intersection, but they are different. Both have their uses (and similarly list comprehensions).

> [@ninjaaron](#):
>
> Splatting with `...` vs. array concatination with `;` . I realize these are quite different… but then they are kind of the same when defining a new array

I hope you realize that `...` has uses outside creating arrays — in fact, it has nothing to do with arrays _per se_.

Your point about `=` and `in` in loops is valid. @tkf has explained the difference between `import` and `using`.

While Julia is of course not perfect, I am wondering if your impression about the “eagerness to add syntax” stems from a superficial understanding of some elements of the language.

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [June 24, 2019, 6:06am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/17 "2019-06-24T06:06:37Z")

</div>

As far as I can tell (despite some syntax examples) you seem to be more concerned about the number of names defined in Base than actual syntax.

The good news on that front is that there has been a concerted effort to slim down Base, and move things _out_. So much so, that I frequently see people clamoring to bring things back or put new stuff in.

(I totally agree on `for i = ...`, btw. I really dislike that particular Matlabism.)

---

<div class="post-metadata">

**Author:** ![ninjaaron](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ninjaaron/32/6392_2.png) [@ninjaaron](https://discourse.julialang.org/u/ninjaaron)\
**Post date:** [June 24, 2019, 8:23am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/18 "2019-06-24T08:23:25Z")

</div>

> [@tkf](#):
>
> I think the difference is clear once you know it:
> 
> - `using M` if you want all symbols exported from `M`
> - `import M` if you only want `M` to be in your namespace
> - `using M: f, g` if you only want to call functions
> - `import M: f, g` if you want to extend functions (without fully qualifying them like `M.f` )

I looked it up recently, so these differences are still in my mind, I just don’t get why there needs to be two keywords for this. I personally would rather have fewer semantic options. i.e. one option for all exported symbols (not extensible) and one for importing just the module name. `Module.function` aways required for extension.

> [@tkf](#):
>
> FYI you can also expand native syntaxes using `Meta.@lower`.

This is very cool, thanks!

> [@Azamat](#):
>
> It shortens to `SArray{S, T, L} where {L, T, S}` .

Good to know, thanks!

> [@Tamas\_Papp](#):
>
> At this stage of the language, many (I would say most) proposals for syntax changes are actually _rejected_ .

I’m glad to hear it. It seems like most of the proposals I end up hearing about get through, but, as you say, I don’t follow the all the proposal requests closely. It’s probably mostly the ones that have some support from the core devs that trickle down to me.

> [@Tamas\_Papp](#):
>
> I hope you realize that `...` has uses outside creating arrays — in fact, it has nothing to do with arrays _per se_ .

yes.

> [@Tamas\_Papp](#):
>
> While Julia is of course not perfect, I am wondering if your impression about the “eagerness to add syntax” stems from a superficial understanding of some elements of the language.

I guess it’s possible. From my perspective–which may be skewed, as you point out–I just see a lot of syntax for similar kinds of things. I realize that dot broadcasting, map’n’filter and comprehensions are different (well, comprehensions are basically same as Base.Filter + Base.Generator, but broadcasting is a little different), but with subtly different semantics.

I tend to gravitate towards languages that are intentional about restricting themselves to a smaller number of syntactic forms, and I’m not sure Julia is that kind of language. I do realize that most syntax features are just sugar for normal functions and macros, but that doesn’t make them… not syntax.

> [@DNF](#):
>
> As far as I can tell (despite some syntax examples) you seem to be more concerned about the number of names defined in Base than actual syntax.

What gives you that impression? I find it convenient to have a lot of stuff in Base. I hope they at least leave the functions for dealing with files and the filesystem in! That’s (maybe) my favorite thing about Julia! I also like having easy access the the functions for running and communicating with external processes, though I could understand if that were moved out of Base. (but I guess it won’t be, since there is literal syntax for commands in the language, and it would be silly to have to import a bunch of functions to be able to use this language feature.)

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [June 24, 2019, 8:33am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/19 "2019-06-24T08:33:38Z")

</div>

> [@ninjaaron](#):
>
> I realize that dot broadcasting, map’n’filter and comprehensions are different (well, comprehensions are basically same as Base.Filter + Base.Generator, but broadcasting is a little different), but with subtly different semantics.

I think the main problem with the current situation is not that `map`, broadcasting, and list comprehensions are too similar (and thus redundant syntax for the same thing), but that they are quite different, and a new user may have a difficult time understanding the difference and, more importantly, _picking when to use the right one_. Pitfalls like

```julia
julia> map(+, 1, 1:3)
1-element Array{Int64,1}:
 2

julia> 1 .+ (1:3)
2:4

```

can be surprising since eg `map` in particular can’t be accused of being overdocumented. I would of course make a PR but I am not sure I know all the corner cases. The differences are scattered in [comments like these](https://github.com/JuliaLang/julia/issues/32081#issuecomment-494080206).

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [June 24, 2019, 8:53am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/20 "2019-06-24T08:53:50Z")

</div>

> [@ninjaaron](#):
>
> I find it convenient to have a lot of stuff in Base.

Your position is a curious mixture of being a purist when it comes to language design (avoiding constructs you consider redundant) and a kitchen sink approach for “built-in” functions. 😉

People may find it convenient to have stuff in `Base`, but at the same inconvenient to _develop_ stuff in `Base`, or even the standard librares. As long as their release cycle and versioning is coupled to `Base`, changes are going to be very slow (2-3 times a year, compared to packages which can get new features with a complete deprecation cycle in a matter of _weeks_), and consequently people tend to be more conservative about what goes into `Base` and the standard libraries.

I wonder if people arguing for “batteries included” realize that this means that they get stuck with one battery type for longer time, when with a more modular approach they would already have the shiny new batteries with 2x the capacity, a mascot playing a percussion instrument, and a raygun (\* _while stocks last_).

[Next page](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562.md?page=2)