# Features most wanted in Julia

**URL:** <https://discourse.julialang.org/t/features-most-wanted-in-julia/50821>\
**Category:** Internals & Design\
**Created:** [November 26, 2020, 3:11pm UTC](https://discourse.julialang.org/t/features-most-wanted-in-julia/50821 "2020-11-26T15:11:58Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [November 26, 2020, 4:07pm UTC](https://discourse.julialang.org/t/features-most-wanted-in-julia/50821/2 "2020-11-26T16:07:26Z")

</div>

> [@jakobnissen](#):
>
> Scott Paul Jones:
> 
> > Being able to specify a finalizer for a type, instead of having to use a 16-byte (on 64-bit machines) entry for every object.

There isn’t always 16-byte overhead(?). See: [Essentials · The Julia Language](https://docs.julialang.org/en/v1/base/base/#primitive%20type) and on isbitstype [Essentials · The Julia Language](https://docs.julialang.org/en/v1/base/base/#Base.isbits)

> Return `true` if type `T` is a “plain data” type, meaning it is immutable and contains no references to other values, only `primitive` types and other `isbitstype` types.

My understanding is that there’s no overhead when such types are stack allocated, i.e. (almost) always. And even with an array of such, then 16-byte overhead seems rather low for the whole array (then there’s StaticArrays.jl for no overhead where it applies, and also for tuples of?), if that’s what it really is.

A destructor as in C++ might change things (I’m not sure about finalizers), but making Julia a very different language without without garbage collection (it’s still possible to do your own memory management). For e.g. strings you actually want GC (for long strings), rather than finalizers/destructors and (naively) copying:

I would be rather happy with only 16-byte overhead (memory is cheap), for say strings, as the (64-bit) pointer is 8 bytes, and you need to store the length somehow. I’m more worried about the pointer-indirection, what I believe ShortString.jl (and FixedSizeString.jl) solve. I actually had the same idea as others, described here (and nothing in the way to do it, if not already done), to make more general:

> [@Progress towards faster \`sortperm\` for Strings](https://discourse.julialang.org/t/progress-towards-faster-sortperm-for-strings/8505/4):
>
> At some point I played around with a hybrid representation where strings up to 15 bytes were stored inline with one byte of length in such a way that they integer sort in correct string sort order (store the length in the low byte, pad string data with zeros) and as a pointer to string data otherwise. This not only means that short strings can fit in a single register but also that when comparing two short strings the compare is just an integer comparison. This flew for sorting and basically eli…

---

_[View the full topic](https://discourse.julialang.org/t/features-most-wanted-in-julia/50821)._