&gt; I remember plenty of cases I got simply from observing the Julia repo for a few months, I could list them if you like... But I&#x27;ve been told by Julia contributors before that discussing this on HN is not an appropriate place. So we can discuss it, where I start linking to public examples on HN, or you can ignore my opinion and we can not discuss it.<p>I do think HN is not the right forum to link to individual comments and call out people for their behavior. Perfectly happy to discuss the technical issues though. If you would would still like to discuss, or at least bring such instances to my attention, please do feel free to send me an email.<p>&gt; People who suggest refactoring large sections of Julia&#x27;s expansive base library (1600 symbols? a problem that causes parts of the slow startup time and memory usage) into other libraries (which would improve batteries included, etc. features) are summarily ignored &#x2F; shouted down &#x2F; (predicated on my previous paragraph) banned.<p>There are several recent examples where people have suggested such things, e.g. They were neither ignored nor shouted down nor banned.
<a href="https:&#x2F;&#x2F;github.com&#x2F;JuliaLang&#x2F;julia&#x2F;issues&#x2F;16357" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;JuliaLang&#x2F;julia&#x2F;issues&#x2F;16357</a>
<a href="https:&#x2F;&#x2F;github.com&#x2F;JuliaLang&#x2F;julia&#x2F;pull&#x2F;16070" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;JuliaLang&#x2F;julia&#x2F;pull&#x2F;16070</a><p>&gt; Important improvements to the language go in circles on JULEP tagged issues namely any large improvement that would require multiple people and lots of dev work seems to gain little traction unless a core dev just takes the time to do it; rather than a timeline to reach consensus and then design a plan for implementing it.<p>I don&#x27;t understand what exactly the criticism is. At first I thought it was about, too much dicussion, but then it seemed to be about too little dev time, please do clarify.<p>&gt; There was a push to increase test coverage and then a few months later commits plummeted the code coverage numbers and no one seemed to care.<p>I&#x27;m not really sure which instance you&#x27;re referring to, but last time there was a major drop in coverage, it was investigated, found to be a bug in the instrumentation (which was fixed). I don&#x27;t really think it&#x27;s fair to say that people don&#x27;t care. There&#x27;s somewhat of a tooling problem here, since we can&#x27;t run the coverage tests on travis, so we don&#x27;t get them integrated in the GitHub UI, but people do look at them and add tests as appropriate.<p>&gt; Sections of important code are uncommented, undocumented, and untested on purpose.<p>Yes, there are undocumented and uncommented sections in the code base, but I wouldn&#x27;t say that they are so on purpose. I do admit to having added such hacks in the past (and not documented them because they were gonna go away soon after), because I needed them in outside packages, but people don&#x27;t let me do that anymore ;).<p>&gt; Unpredictable un-typed exceptions, namespaces&#x2F;modules being hard to use for non-trivial designs, interfaces without any sort of type enhancement.<p>These are fair points, which I&#x27;m sure you&#x27;ve seen the issues about. The problem is the availability of developer time, not some sort of unwillingness to fix problems. Putting together the road map of what goes into each release and prioritizing are very hard, because there&#x27;s just so much that could be worked on.<p>&gt; setup a transparent community policy and actually follow it;<p>This is being discussed (as part of larger discussions around community governance) and as I mentioned will likely be a topic at JuliaCon.