# 1.0 annoyances and Matlab comparison

**URL:** <https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433>\
**Category:** Internals & Design\
**Created:** [March 1, 2018, 9:49pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433 "2018-03-01T21:49:56Z")\
**Posts on this page:** 20\
**Page:** 6

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [March 6, 2018, 12:27pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/102 "2018-03-06T12:27:34Z")

</div>

`uninitialized` forces my brain to go into “spelling” mode which is annoying. The `iti` part is what gets me, I think, since the pronunciation is more like “itchi”.

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [March 6, 2018, 1:28pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/103 "2018-03-06T13:28:53Z")

</div>

I agree that what I don’t like about “uninitialized” is its spelling, it takes me a few seconds to write it correctly without an autocompletion system.

---

<div class="post-metadata">

**Author:** ![yakir12](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yakir12/32/297_2.png) [@yakir12](https://discourse.julialang.org/u/yakir12)\
**Post date:** [March 6, 2018, 1:32pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/104 "2018-03-06T13:32:52Z")

</div>

> [@giordano](#):
>
> uninitialized

How about using `garbage` instead?

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [March 6, 2018, 1:38pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/105 "2018-03-06T13:38:39Z")

</div>

I think the discussion has moved to [https://github.com/JuliaLang/julia/pull/26316](https://github.com/JuliaLang/julia/pull/26316). I honestly can live with “uninitialized”, I just happen to dislike the word. I have to type it as “un-init-ial-ized”.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [March 6, 2018, 2:43pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/106 "2018-03-06T14:43:15Z")

</div>

> [@yakir12](#):
>
> How about using garbage instead?

Or maybe a short, four-letter synonym… 🤔

---

<div class="post-metadata">

**Author:** ![yakir12](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yakir12/32/297_2.png) [@yakir12](https://discourse.julialang.org/u/yakir12)\
**Post date:** [March 6, 2018, 2:44pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/107 "2018-03-06T14:44:50Z")

</div>

> [@StefanKarpinski](#):
>
> four-letter synonym

> **[Thesaurus.com - The world's favorite online thesaurus!](https://www.thesaurus.com/browse/garbage?s=t)**
>
> Thesaurus.com is the world’s largest and most trusted online thesaurus for 25+ years. Join millions of people and grow your mastery of the English language.

So many options…

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [March 6, 2018, 2:45pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/108 "2018-03-06T14:45:43Z")

</div>

I guess Stefan was referring to “junk” 😉

---

<div class="post-metadata">

**Author:** ![yakir12](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yakir12/32/297_2.png) [@yakir12](https://discourse.julialang.org/u/yakir12)\
**Post date:** [March 6, 2018, 2:46pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/109 "2018-03-06T14:46:39Z")

</div>

> [@giordano](#):
>
> junk

Yea, I figured, but there’s also muck… I love dreck!

---

<div class="post-metadata">

**Author:** ![piever](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/piever/32/1815_2.png) [@piever](https://discourse.julialang.org/u/piever)\
**Post date:** [March 6, 2018, 3:56pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/110 "2018-03-06T15:56:35Z")

</div>

I personally don’t mind `uninitialized` (even though I definitely need autocomplete to spell this right), but if there is a strong request for a more concise syntax, maybe it would be possible to bring back the (very) old constructor `Array(T, 3)` to mean `Array{T}(uninitialized, 3)`. It would be analogous to `missings(T, 3)` to create a `Array{Union{Missing, T}}` filled with `missings`.

Of course, as I don’t know what future constructor are planned for `Array`, this proposal only makes sense if dispatching on `::Type` as first argument does not clash with anything else.

---

<div class="post-metadata">

**Author:** ![johnh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnh/32/3615_2.png) [@johnh](https://discourse.julialang.org/u/johnh)\
**Post date:** [March 6, 2018, 4:18pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/111 "2018-03-06T16:18:03Z")

</div>

I rather like the term ‘dreck’ myself. And ti is not too English-centric.  
The Scots have a nice word for the fluff under the bed **oose**. But that is a very specific thing - it does not mean ‘rubbish’.

Just also noting that the era of non-volatile memory will be upon us soon. I guess the old timers with real core memory coped with that.  
Will there be language extensions in future Julia version maybe which say “pick up where you left off with that array before the machine crashed”. But tthats goign far off topic.

---

<div class="post-metadata">

**Author:** ![ScottPJones](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/scottpjones/32/146_2.png) [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)\
**Post date:** [March 6, 2018, 4:32pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/112 "2018-03-06T16:32:39Z")

</div>

> [@johnh](#):
>
> Just also noting that the era of non-volatile memory will be upon us soon. I guess the old timers with real core memory coped with that.

I think the really hard thing to deal with programming when that happens is efficiently making sure that old contents aren’t left around, for security reasons.  
It’s not fun having to do it with databases!

---

<div class="post-metadata">

**Author:** ![EthanAnderes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ethananderes/32/2028_2.png) [@EthanAnderes](https://discourse.julialang.org/u/EthanAnderes)\
**Post date:** [March 6, 2018, 4:39pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/113 "2018-03-06T16:39:20Z")

</div>

what about something like

```julia
Array{T}(vals, dim) where vals::Val{:uninitialized}

```

The nice thing is that when a user sees it for the first time and does

```julia
julia> typeof(vals)
Val{:uninitialized}

```

there is an automatic hook into the documentation and it becomes clear what is going on (… and avoids doing what I did a few posts up where I somehow thought `uninitialized` was a type of magic iterator … duh!). Also, I guess it could even be extended to something like

```julia
Array{T}(zeros, dim) where zeros::Val{:zeros}
Array{T}(ones, dim) where ones::Val{:ones}

```

now that `zeros` and `ones` are gone.

---

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [March 6, 2018, 5:04pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/114 "2018-03-06T17:04:29Z")

</div>

That’s another plus point for having an explicit first argument (possibly with shorter spelling than `uninitialized`): People could e.g. define something like:

```julia
struct Clear_on_free end
function Array{T}(::Clear_on_free, size...) where T
       rv = Array{T}(uninitialized, size...)
       finalizer(rv) do rv ccall(:bzero, Nothing, (Ptr{Nothing}, Cint), pointer(rv), sizeof(rv)) end
       rv
       end

A = Array{Int}(Clear_on_free(), 2, 2);
A[1]=-1; Aptr=pointer(A);
@show unsafe_load(Aptr);
#unsafe_load(Aptr) = -1

A= 2; 
@show unsafe_load(Aptr);
#unsafe_load(Aptr) = -1

GC.gc();
@show unsafe_load(Aptr);
#unsafe_load(Aptr) = 0

```

Warning: Don’t do this if for arrays that you resize during their lifetime. You need to subtract the offset from the pointer before calling bzero and clear up to the capacity. Also, you can still leak memory contents when resizing and I have no idea how to hook into the resize machinery.

---

<div class="post-metadata">

**Author:** ![ScottPJones](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/scottpjones/32/146_2.png) [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)\
**Post date:** [March 6, 2018, 5:31pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/115 "2018-03-06T17:31:51Z")

</div>

I like the technique, unfortunately, it doesn’t really give much in the way of security, because Julia is very lazy about picking up garbage lying around (just like my almost 15 year old son!)

---

<div class="post-metadata">

**Author:** ![dlfivefifty](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlfivefifty/32/1959_2.png) [@dlfivefifty](https://discourse.julialang.org/u/dlfivefifty)\
**Post date:** [March 6, 2018, 5:39pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/116 "2018-03-06T17:39:46Z")

</div>

> [@carstenbauer](#):
>
> what’s wrong about in addition having special convenience function

Nothings wrong with it, there’s just no reason for it to be in Base. I’m sure there’ll quickly sprout up a ConvenientArrays.jl package.

---

<div class="post-metadata">

**Author:** ![Seif\_Shebl](https://avatars.discourse-cdn.com/v4/letter/s/eada6e/32.png) [@Seif\_Shebl](https://discourse.julialang.org/u/Seif_Shebl)\
**Post date:** [March 6, 2018, 7:12pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/117 "2018-03-06T19:12:45Z")

</div>

I think `new` is a very valid choice, short and clear, and has been used by other languages to do the same thing. In C++, `int* p = new int[n];` will do the same as `p = Array{Int}( uninitialized, n)`. `new` is also used in Pascal and other languages with the same meaning. All of which will do simple allocation reserving a block of memory of a certain size without concern of its contents. What is wrong with using it in Julia instead of that mouthful `uninitialized`?

I’d also love to remind you of [the Zen of Python](https://en.wikipedia.org/wiki/Zen_of_Python), too many of these cool principles are already applied in Julia. I’ll copy these here for convenience, I hope this will help us take the right decision. As a performance language, Julia should never deprive us from writing readable code without any [performance loss from forcing the user to initialize arrays](https://blog.codinghorror.com/for-best-results-dont-initialize-variables/).

The Zen of Python:

1. Beautiful is better than ugly.
2. Explicit is better than implicit.
3. Simple is better than complex.
4. Complex is better than complicated.
5. Flat is better than nested.
6. Sparse is better than dense.
7. Readability counts.
8. Special cases aren’t special enough to break the rules.
9. Although practicality beats purity.
10. Errors should never pass silently.
11. Unless explicitly silenced.
12. In the face of ambiguity, refuse the temptation to guess.
13. There should be one—and preferably only one—obvious way to do it.
14. Although that way may not be obvious at first unless you’re Dutch.
15. Now is better than never.
16. Although never is often better than right now.
17. If the implementation is hard to explain, it’s a bad idea.
18. If the implementation is easy to explain, it may be a good idea.
19. Namespaces are one honking great idea—let’s do more of those!

---

<div class="post-metadata">

**Author:** ![simonbyrne](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/simonbyrne/32/19_2.png) [@simonbyrne](https://discourse.julialang.org/u/simonbyrne)\
**Post date:** [March 6, 2018, 7:20pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/118 "2018-03-06T19:20:02Z")

</div>

Note that it isn’t always “garbage”: if it’s an array of non-bitstypes, then you’ll get undefs.

---

<div class="post-metadata">

**Author:** ![Liso](https://avatars.discourse-cdn.com/v4/letter/l/898d66/32.png) [@Liso](https://discourse.julialang.org/u/Liso)\
**Post date:** [March 6, 2018, 7:25pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/119 "2018-03-06T19:25:11Z")

</div>

Could pls you show some example what do you mean?

---

<div class="post-metadata">

**Author:** ![simonbyrne](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/simonbyrne/32/19_2.png) [@simonbyrne](https://discourse.julialang.org/u/simonbyrne)\
**Post date:** [March 6, 2018, 7:25pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/120 "2018-03-06T19:25:58Z")

</div>

```julia
julia> Vector{BigFloat}(uninitialized, 10)
10-element Array{BigFloat,1}:
 #undef
 #undef
 #undef
 #undef
 #undef
 #undef
 #undef
 #undef
 #undef
 #undef

```

---

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [March 6, 2018, 7:29pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/121 "2018-03-06T19:29:34Z")

</div>

> [@ScottPJones](#):
>
> it doesn’t really give much in the way of security

Depends. Julia is guaranteed on to call the finalizer before clean exit, or before giving the memory to some other object. Even in ref-counted languages you are afaik not guaranteed immediate scrubbing upon unreachability (I think cycle detection is done periodically, at least in python).

In other words: This will protect you from leaking the secrets from bugs that leak uninitialized memory, and it will protect you from leaving the secret behind after exit. It will not protect you from buffer overflow based info leaks. The secret will not be scrubbed if you segfault / crash julia.

Also, it gives you the nice way of scrubbing your secrets by calling finalize explicitly, once you know that you don’t need the array anymore (if you don’t want to wait for the gc).

The main problem I see is the resize / realloc leak. A dirty work-around would be to just set the shared flag on the array, such that the runtime throws in `array.c` on attempted resize (protecting you from accidentally resizing: A crash is better than a security incident).

Not sure whether that makes trouble; I think we would lie to the compiler here. julia / the type-tag would think that the array is non-shared, but `array.c` would think that it is shared via the flags in the `jl_array` struct-- but maybe I misunderstood how shared arrays are working internally.

If you think a “self-scrubbing” resizeable array is important, then maybe something can be done via modifying `array.c` (scrub after realloc, do the size computation correctly with offset and capacity for the scrubbing; should be reasonably cheap since moving data after realloc is expensive anyway; but you would need to build your custom julia binaries that scrub all arrays on realloc).

Generally, I would like to see more use of `calloc` instead of `malloc` and `bzero` / `memset` in `array.c`. That would also go into the first slot of the constructor! Just as `arena` if you have strong opinions on where the array should be placed (feature currently does not exist, but is trivial to badly implement via `unsafe_wrap` after `ccall` to your favorite allocator; the only thing that I don’t see how to nicely get from julia without modifying `array.c` is the crazy fast pool-allocation for small arrays, and I think finalizers are more expensive to manage for the gc than the free; others would know more about this).

edit: One great way of leaking uninitialized memory that contains secrets from the previous owner – even if you never use the `uninitialized` constructor – is via structure padding. The self-scrubbing non-resizeable array will protect you from this, but you can still leak register contents into structure padding.

[Previous page](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433.md?page=5)

[Next page](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433.md?page=7)