# 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:** 2

<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, 9:37am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/21 "2019-06-24T09:37:47Z")

</div>

Makes sense. I have a lot more experience _using_ standard libraries than maintaining them, so I probably just lack the perspective to recognize the problem. I suppose, like most things, there’s a balance to be struck here. In my experience, Python projects tend to be easier to maintain over a long period vs Ruby projects (to say nothing of JavaScript and the NPM nightmare) because they rely on fewer external dependencies. Standard library batteries may be “worse” in a lot of ways, but they have the benefit of being a known quantity that’s always there.

Of course, there are rumblings among the Python core devs at the moment about majorly downsizing the standard library and breaking a lot of it into a “core” package set which is maintained separately and can be added à la carte because the current size of the Python standard library is beginning to become untenable. Maybe something for Python 4.

Returning to syntax, for me, the current amount of syntax in Julia is a decent balance. It could be less, but it’s still manageable, and if the rate of growth of syntactic forms has slowed (like, hopefully to something barely more than stopped) as you say, I guess there’s no problem.

As someone who occasionally uses Perl, it’s possible that I just have bit of “PTSD” (so to speak–I don’t mean to trivialize the actual medical condition) about large syntaxes with a lot of subtle semantics. The words “Julia is an enormous language” just kind of exacerbated the paranoia I already have about Julia slowly turning into Perl.

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [June 24, 2019, 9:39am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/22 "2019-06-24T09:39:49Z")

</div>

> [@tkf](#):
>
> > but the `for x=xs` definitely qualifies as additional syntax
> 
> I do feel the same.

That is a short for the form `for k = 1:N` that for many of us (those coming from Matlab, which is the original inspiration of Julia syntax) is the natural form of expressing a loop. `for k in x` came later (if I remember well). Anyway, this was discussed some 5 years ago.

---

<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, 9:46am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/23 "2019-06-24T09:46:02Z")

</div>

Maybe “additional” wasn’t the right word. What I meant was that they are duplicates in terms of functionality. Either form would be fine with me, it’s just weird to have both. I suppose it’s for historical reasons; i.e. originally based on Matlab, but added `in` to be helpful to people more used to Python, Ruby and JavaScript. Either form is fine with me, but supporting both… ech.

---

<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, 9:52am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/24 "2019-06-24T09:52:14Z")

</div>

> [@ninjaaron](#):
>
> it’s just weird to have both

I think the best course is just to ignore the one you don’t use for now, and participate in the discussion for 2.0, which is the earliest point this can be removed. Even if one considers this a wart, it is simply not a high priority one.

Also, it serves as a prime example of how you are stuck with things once they are in `Base`. 😉

---

<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, 10:28am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/25 "2019-06-24T10:28:48Z")

</div>

> [@joa-quim](#):
>
> That is a short for the form `for k = 1:N` that for many of us (those coming from Matlab, which is the original inspiration of Julia syntax) is the natural form of expressing a loop.

As a mainly Matlab programmer for the last two decades, I really dislike that spelling. The first time I saw `for i in 1:N`, I immediately thought “that makes _so_ much more sense.”

---

<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, 10:53am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/26 "2019-06-24T10:53:40Z")

</div>

> [@ninjaaron](#):
>
> What gives you that impression?

Some of your examples, such as `map` and `∈`, and then I misremembered ChrisRackauckas’s post as being yours.

---

<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, 11:01am UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/27 "2019-06-24T11:01:18Z")

</div>

> [@ninjaaron](#):
>
> Splatting with `...` vs. array concatination with `;`

Due to how powerful generic concepts are in Julia, everything you add to the language gets multiple possible applications. Consider `...`. If that was special syntax for use inside array brackets, `[]`, then that would perhaps be too much syntax. But that’s not what it’s for, it just happens to work that way as a _side effect._ The more powerful and composable concepts become, the more you get a proliferation of ways of doing things, just by the law of unintended consequences.

If you want very much to avoid multiple ways of spelling things, you end up having to impose artificial limitations, and making the language less consistent. In languages with less powerful generics, you don’t get that problem to the same degree.

---

<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, 2:40pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/28 "2019-06-24T14:40:38Z")

</div>

> [@ninjaaron](#):
>
> 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.

I more or less agree (though I want `using M: f` too) and I only use `Module.function` for extending functions. But I can see someone wants `import M: f` for extending a lot of (say) binary operators in a lot of ways.

> [@Tamas\_Papp](#):
>
> > it’s just weird to have both
> 
> I think the best course is just to ignore the one you don’t use for now, and participate in the discussion for 2.0, which is the earliest point this can be removed.

Another way to encourage/enforce uniformity in the syntax is a code formatter (with (almost) no configuration options). These days I really enjoy using [`black`](https://github.com/python/black) in Python projects and I remember [`gofmt`](https://blog.golang.org/go-fmt-your-code) was great too. I know Julia has [DocumentFormat.jl](https://github.com/julia-vscode/DocumentFormat.jl) but I don’t know if it converts `for x = xs` to `for x in xs`.

---

<div class="post-metadata">

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

</div>

> [@tkf](#):
>
> Another way to encourage/enforce uniformity in the syntax is a code formatter (with (almost) no configuration options).

Personally this really annoyed me, I format my code so **I** can easily read it, but when the formatter has it’s own way to format…it just annoys me. I was forever disabling the go formatter in the editor, which for some reason always loved to re-enable 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, 2:57pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/30 "2019-06-24T14:57:38Z")

</div>

> [@Tamas\_Papp](#):
>
> ```julia
> julia> map(+, 1, 1:3)
> 1-element Array{Int64,1}:
> 2
> 
> ```

This does not make sense to me. Can anyone explain why is it giving this output?

---

<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, 3:04pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/31 "2019-06-24T15:04:23Z")

</div>

Scalars are [iterable](https://github.com/JuliaLang/julia/issues/11769), with length 1, and

```julia

julia> length(zip(1, 1:3))
1

```

This, of course, does not make sense 😉, but is surprisingly tricky to get rid of now.

---

<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, 3:08pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/32 "2019-06-24T15:08:43Z")

</div>

in many languages, map only takes one iterable as the argument, but in Julia, it can take a list of iterables, but it zips them first and turns that into separate arguments for the function. That’s kind of cool.

Unfortunately, in Julia, even numbers are iterables of length == 1, so… bad stuff happens. `broadcast` has some trait magic to work around this insane behavior. `map` does not.

---

<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:10pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/33 "2019-06-24T15:10:34Z")

</div>

> [@Tamas\_Papp](#):
>
> Scalars are [iterable](https://github.com/JuliaLang/julia/issues/11769)

And so are `1:2` and `1:5`, but

```julia
julia> map(+, 1:2, 1:3)
ERROR: DimensionMismatch("dimensions must match")

julia> map(+, 1:5, 1:3)
ERROR: DimensionMismatch("dimensions must match")

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

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

```

So it seems inconsistent to me that `map(+, 1, 1:3)` does not throw `DimensionMismatch` exception like `1:2` and `1:5` do.

---

<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, 3:11pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/34 "2019-06-24T15:11:52Z")

</div>

Wow. This, I didn’t know and cannot explain.

_edit: Looks like `map` doesn’t use `zip` internally_

---

<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, 3:29pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/35 "2019-06-24T15:29:38Z")

</div>

> [@ninjaaron](#):
>
> edit: Looks like `map` doesn’t use `zip` internally

It falls back to `Base.Generator` which does.

---

<div class="post-metadata">

**Author:** ![bkamins](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bkamins/32/208538_2.png) [@bkamins](https://discourse.julialang.org/u/bkamins)\
**Post date:** [June 24, 2019, 3:37pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/36 "2019-06-24T15:37:03Z")

</div>

Actually I would say that for Julia learners a bigger surprise usually is:

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

```

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [June 24, 2019, 3:41pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/37 "2019-06-24T15:41:58Z")

</div>

> [@ninjaaron](#):
>
> Unfortunately, in Julia, even numbers are iterables of length == 1, so… bad stuff happens. `broadcast` has some trait magic to work around this insane behavior. `map` does not.

Just FWIW, the fact that numbers act like 0-dimensional arrays (that is, they’re iterable, indexable, and have `axes`) means that broadcast does _not_ need to do anything special — in fact it makes broadcasting _more_ consistent, not less. I agree that it’s not ideal in other situations, but it is what it is.

As far as `map` not ensuring that its arguments are the same lengths, I call that a bug: [#13361](https://github.com/JuliaLang/julia/issues/13361).

---

<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, 3:43pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/38 "2019-06-24T15:43:02Z")

</div>

these examples are making my body hurt.

---

<div class="post-metadata">

**Author:** ![bkamins](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bkamins/32/208538_2.png) [@bkamins](https://discourse.julialang.org/u/bkamins)\
**Post date:** [June 24, 2019, 3:48pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/39 "2019-06-24T15:48:31Z")

</div>

> [@mbauman](#):
>
> As far as `map` not ensuring that its arguments are the same lengths, I call that a bug: [#13361](https://github.com/JuliaLang/julia/issues/13361).

Here we have a delicate thing that is related to how `zip` works:

```julia
julia> collect(zip(1:3, 1:5))
ERROR: DimensionMismatch("dimensions must match")

```

but

```julia
julia> for v in zip(1:3, 1:5)
       println(v)
       end
(1, 1)
(2, 2)
(3, 3)

```

and I always thought this was intended.

EDIT: but I agree that it is natural to expect that `map` always checks that the dimensions match.

---

<div class="post-metadata">

**Author:** ![jeff.bezanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeff.bezanson/32/48_2.png) [@jeff.bezanson](https://discourse.julialang.org/u/jeff.bezanson)\
**Post date:** [June 24, 2019, 3:49pm UTC](https://discourse.julialang.org/t/julia-included-in-oreillys-emerging-programming-languages-report-june-2019/25562/40 "2019-06-24T15:49:15Z")

</div>

> [@ninjaaron](#):
>
> in many languages, map only takes one iterable as the argument, but in Julia, it can take a list of iterables, but it zips them first and turns that into separate arguments for the function.

`map` accepting multiple arguments in this way is quite traditional in the lisp world. Allowing different-length arguments and taking the prefix is too, but slightly more controversial. Some people _insisted_ on giving an error in at least some cases though, leading to the current inconsistent state, which is very frustrating. We should remove that error.

Quick aside on the amount-of-syntax thing: it’s true that we have many syntax forms, perhaps too many, but I don’t think we are adding more at a high rate. Almost all the syntax you mentioned has been there since v0.1. I agree it would be nice to deprecate `for x = y` in v2.0; it really doesn’t make sense.

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

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