It shares some of the same drawbacks as C++, though. The language is extremely powerful, so while it is easy to write performant code, it is also easy for non experts to write very suboptimal code.

When creating a new type, it should be more clear cut when is subtyping Number (or Real, etc.) valid. Should unitful quantities be numbers? Should intervals be numbers? Related: I think there are some attempts by Tim Holy and others to create/document "thick numbers".

Furthermore, I believe it might be good to align the Number type hierarchy with math/abstract algebra as much as possible without breaking backwards compatibility, which might making Number, or some subtypes of it, actual interfaces.

> Subtyping Number is a way to opt into numeric promotion and a few other useful generic behaviors. That’s it.

OK, but I think that's not documented either.

There are some proposals to forbid the registration of a package release which trespasses on the internals of another package, though.

I hope someone tackles the above sooner or later, but another issue is the approach of testing every known dependent package might be very costly, both in terms of compute and manual labor, the latter because someone would have to do the work of maintaining a blacklist for packages with flaky unit tests. The good news is that this work might considerably overlap with the already existing PkgEval infrastructure. We'll see.

On the contrary, it is my impression the experienced Julia programmers, including those involved in JuliaLang/julia, take correctness seriously. More so than in many other PL communities.

> there are people working on traits/interfaces - but these are still peripheral projects and not part of the core mission to my knowledge

What exactly do you mean by "traits" or "interfaces"? Why do you think these "traits" would help with the issues that bug you?

The fact that bugs happen in software should not surprise anyone. Even software of critical importance, such as GCC or LLVM, whose correctness is relied upon by the implementations of many programming languages (including C, C++ and Julia itself), are buggy.

Instead the post could have focused more on actual design issues, such as some of the Base interfaces being underspecified:

> the nature of many common implicit interfaces has not been made precise (for example, there is no agreement in the Julia community on what a number is)

The underspecified nature of Number (or Real, or IO) is an issue, albeit not related with the rest of the blog post. It does not excuse the scaremongering in the blog post, however.

Be careful with that thought, it's a trap people have been falling into since the sixties:

https://en.wikipedia.org/wiki/ELIZA_effect

Comments URL: https://news.ycombinator.com/item?id=43602961

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=43602889

Points: 5

# Comments: 0

Anything particular in mind?

> recompilation on every run breaks this

Your comment is exceedingly misleading. Whether and when Julia code gets compiled is up to the user.

Huh? I think Pkg is very good as far as package managers go, exceptionally so. What specifically is your issue with it?

Comments URL: https://news.ycombinator.com/item?id=41973172

Points: 2

# Comments: 0