# Why I love Julia
**URL:** https://discourse.julialang.org/t/why-i-love-julia/29489
**Category:** Community
**Tags:** announcement
**Created:** [October 4, 2019, 3:29pm UTC](https://discourse.julialang.org/t/why-i-love-julia/29489 "2019-10-04T15:29:50Z")
**Posts on this page:** 1
**Showing post:** 28
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [October 8, 2019, 2:01pm UTC](https://discourse.julialang.org/t/why-i-love-julia/29489/28 "2019-10-08T14:01:36Z")
> [@kolia](#):
>
> possibly forbidding type piracy and adding a formal-ish interfaces are on the compiler team’s TODO list
I am not sure about these last two specifically:
> [@Compiler work priorities](https://discourse.julialang.org/t/compiler-work-priorities/17623):
>
> In response to I thought I might write a little post about the rough priorities of the compiler team: Correctness finding and fixing compiler and inference bugs Multithreading [non-copying task stack switching](https://github.com/JuliaLang/julia/pull/13099) (done) [new PARTR parallel runtime](https://github.com/JuliaLang/julia/pull/22631)[locks for I/O operations](https://github.com/libuv/libuv/issues/1595) other thread safety Compile-time latency, aka “the time-to-first-plot problem” making compilation faster caching more things Compiler-related packages and tools [PackageCompiler](https://github.com/JuliaLang/PackageCompiler.jl) Debugger [Cxx](https://github.com/Keno/Cxx.jl) type checking/linting J…
Sure, there are issues open, like
>
>
> I think this feature request has not yet its own issue although it has been disc…ussed in e.g. #5.
>
> I think it would be great if we could explicitly define interfaces on abstract types. By interface I mean all methods that have to be implemented to fulfill the abstract type requirements. Currently, the interface is only implicitly defined and it can be scattered over several files so that it is very hard to determine what one has to implement when deriving from an abstract type.
>
> Interfaces would primary give us two things:
> \- self documentation of interfaces at a single place
> \- better error messages
>
> Base.graphics has a macro that actually allows to define interfaces by encoding an error message in the fallback implementation. I think this is already very clever. But maybe giving it the following syntax is even neater:
>
> \`\`\`
> abstract MyType has print, size(::MyType,::Int), push!
> \`\`\`
>
> Here it would be neat if one could specify different granularities. The \`print\` and \`push!\` declarations only say that there have to be any methods with that name (and \`MyType\` as first parameter) but they don't specify the types. In contrast the \`size\` declaration is completely typed. I think this gives a lot of flexibility and for an untyped interface declaration one could still give quite specific error messages.
>
> As I have said in #5, such interfaces are basically what is planed in C++ as \`Concept-light\` for C++14 or C++17. And having done quite some C++ template programming I am certain that some formalization in this area would also be good for Julia.
which has been around since the dawn of time and I am not sure it is going anywhere — I imagine people realized that formal interfaces would not add that much value, compared to other neat features which are the focus of current attention.
For type piracy, there is
>
>
> I wonder if we should issue a warning, at least for code evaluated in the \`Main\`… module, perhaps only when \`isinteractive()\` (i.e. in the REPL and similar), when type piracy occurs.
>
> This is a practice that we usually don't recommend and is an easy way for newcomers to shoot themselves in the foot with baffling error messages. See e.g. #29321, #27926, #26528, #22363, etcetera.
which would make sense but I guess it doesn’t address the concerns of a C++ programmer, since it is just a warning, and would not show up in non-interactive use.
Even though software engineers used to C++ & friends may find some parts of Julia puzzling or inadequate, I think it would be misleading to say that implementing these things is a priority in any sense.
I think that it would be fair to say that Julia programmers just rely on other tools (CI, TDD) to deliver quality software, and people interested in Julia should just explore it as it is. Julia is not like some half-constructed building with random things falling on your head all the time, but a comfortable place for productive work.
---
_[View the full topic](https://discourse.julialang.org/t/why-i-love-julia/29489)._