I don't think so. I think by virtue of having a GC language you pretty much have to manually anchor pointers before calling code which knows nothing of the GC. But if anyone knows of counter examples, I would be interested in them as well.
> you pretty much have to manually anchor pointers before calling code which knows nothing of the GC. Which I'd still consider trivial...
I wouldn't. Trivial to me means a call to a C routine looks and feels like a call to a native routine.
Manually managing the memory that the GC "owns" doesn't fit the bill in my definition.
> The base install is a bit bare. I think the problem here is the library approach. They should break stuff out of Julia's core library and move them into default included libraries (like python does).
The rude behavior definitely exists, I can point out a number of examples if you send me your e-mail address (you can look me up, @ScottPJones on GitHub, easily enough). I've seen that that sort of disrespectful behavior tends to spread in the community, unfortunately, when nobody dares call out one person for their comments and actions, because of their position.
But then - as a bystander - let me mention that I once wondered about your insistent replies in some gh issue. God, can't he stop, I thought, and, wow, they have patience. Fortunately such a situation is rare and I'm very often impressed by the intelligent friendly conversations I see. A lot to learn.
Yes, a year ago I'd never worked on any open source project, didn't use GitHub, Google Groups, Twitter, StackOverflow, or any of the other programmer social media sites, and was a total newbie about Julia, using git, and dealing with an open source community. Since I had convinced the other people at the startup where I am working that using Julia would be better for us than a mashup of Python, C, C++14, R or Octave, when I started encountering serious bugs and performance problems in areas that were critical to our development, I did get very insistent, esp. where I had lots of previous experience in the area. Instead of simply complaining about the problems, I submitted issues, wrote documentation, made PRs to fix the issues (in the Scheme parser code, in the core C code, in the C Unicode handling module, esp. to the string handling code in Base, and helped improve the coverage by adding a lot of unit tests). It was a major learning process for me, learning best practices for how to break apart a PR into smaller chunks (even though accepting huge PRs from other developers happens all the time), trying to focus on single issues in a PR, and trying to improve my own communications skills on social media. Between the time I started until early September when v0.4 was released, I'd even reached the point of being the #6 contributor to JuliaLang/julia (#26 all time out of some >400 contributors), so I don't think anybody could possibly accuse me of not having putting my time and effort where my mouth was, as far as fixing problems I encountered. Having gotten the critical issues fixed and into v0.4, so we had a reasonably stable base for our product, I was able to concentrate wholly on our product, and so stopped being so pushy about getting things fixed. ;) I still think there are some real systemic problems that need to be addressed, in how things are done, and hopefully some time will be spent to deal with that at this summer's JuliaCon 2016.
The author has addressed very valid issues, but I strongly disagree with his objective theme of "Giving up" I don't think the Julia team should be blamed for anything. I have not heard of the project receiving any support from large companies as Python, Golang and Rust do. For this reason, I find it very unfair to compare Julia to these languages. FYI Julia has not even reached version 1.0 yet! The language just need…
That's so biased that it gives me the urge to puke.
The Julia team can be blamed for these critics. Full stop.
That said, obviously they are working hard and well! Obviously a critic of a language is not a critic of its conceptors! However the conceptors are to blame and they are the one who can change the language for the better. Not acknowleging it is plain wrong and won't help.
Not receiving support is a problem of Julia. It might be unfair, but this is the fucking fact. Finding excuses (assuming this is really a problem) won't help either!
Oh and guess what? Julia will always be younger than C, Python and co. so what you say about 1.0 and stuff is just misleading. Again, you are looking for excuses: the guy is comparing today's Julia to today's languages. If I invented a new language, the first critique could be "oh that new language does not even have a standard lib" that woyld be true and fair!
Regarding the last sentence, analysing a language with that much attention is "helping". And telling the author to shut up because he has not providing any code is fucking moronic. Does a referee in the olympuc games need to run as fast as the one it judges to provide an accurate judgement?
Obviously static/strong typing is winning. Last man standing are JavaScript and Python, the former transforms into a compilation target (like Elm), the latter doing some kind of gradual typing (like mypy). I think dynamic typing has its place, but more in experimental design and prototyping than in bigger application development (big IMHO).
Uh, I think you're forgetting PHP. Not to mention Clojure is at least as popular as Go. Dynamic typing isn't going anywhere, desire for 'gradual typing' is a very niche but vocal desire in the dynamic language communities. It may lose some mindshare but there are a lot of options to lose that to these days since even the holdouts of 'annoying' static typing with terrible type systems like C++ or Java are making it mo…
Ha, you are right, I forgot PHP. However I think PHP is really a language where people agree that it has lots of weird corner cases.
So its popularity is really historical incident, in particular I think, that it was the first hack (see worse is better) to allow to easily deploy dynamic web applications (via web-server side interpretation of code, which got popular in Apache). Furthermore PHP hosting is still very popular in low-cost bundles to integrate e.g. Wordpress.
Clojure is another nice language, but could benefit from typing. :p Maybe the main "problem" for dynamic languages ist the fact that it requires more discipline on the Programmer's side, so I imagine it is popular for smaller teams, but this is hard to achieve for bigger development efforts, where you can benefit from a stronger type system.
Fortran has the rather unusual feature that you can change the indexing to an arbitrary offset. You can declare arrays to be indexed from 0 if you want, but it defaults to 1 and almost nobody uses this feature for obvious reasons.
I index from -N:N so that 0 is in the centre of my computational boxes.
Yeah, something like this is the intended use, but it isn't used much at least in the Fortran I've seen. Mostly because it's really confusing for someone reading your code, as once the array is declared there's no indication what the index range is.
Libraries? Sure. Ease of development, I cannot comment on. But measuring performance with timing a "hello world" program? Seriously? What scenario does the author have in mind that makes this particular benchmark even remotely relevant? The rest of the rant pretty much comes down to "it doesn't look like Python" (which is IMO a good thing, and I would certainly not call Python a "de facto standard of numerical comput…
I had also the feeling the "benchmark" is a joke. Even if it takes some seconds to print hello, speed is only important when you run big programs with million of operations.
If it takes a system 300ms to compile a function that prints "hello" then imagine how long it would take to compile a function that does something more sophisticated.
The "hello" benchmark is a fantastic benchmark for production-strength JIT-based runtimes because it tells you how long it takes for your system to warm up enough to be able to print something to the screen. You don't want this to be long. I prefer for "hello" to take about 10ms or less. In WebKit we have a few benchmarks that are the moral equivalent of "hello" and these are some of our most important benchmarks.
The reason why warm-up time is so insanely important is that any programming language, no matter what the domain is, will be used for the following things eventually:
- Tests.
- Data definitions in your language (moral equivalent of JSONP - every language/runtime has to deal with something like this).
- Initialization.
All of these things comprise run-once code that tends to be large. All of these things are important, even in math languages. The glorious "hello" benchmark is an excellent proxy for the performance of these kinds of code. So, I think that if Julia requires 300ms to run "hello" then they should make the "hello" benchmark into their primary optimization target.
Although we have since moved to using B3, LLVM was absolutely amazing for us, for the same reasons why it's amazing for Julia: you get tons of optimizations for a lot of targets with little effort. But you have to harness this power the right way. You can't fire up the full LLVM pipeline for code that runs once! It's a waste to unleash so many optimizations only to immediately throw away the result.
I'm not bothered by "hello world" performance myself, and I my recent issues with Julia have been caused by rapid development meaning that when I had to put it down for a few months lots of things I had done (because I'm mortal) stopped working. I wrote this off to "it's 0.x, getoverit". I've never tried complex text formatting in Julia either! My concerns are more focused on the type system (this I love) and perform…
Yeah the poor performance in this blog post is a total misunderstanding of why and how julia is performant. Is printing "hello world" fast really that important? OK. Then don't use Julia. You pay for it by having the compiler JIT the code in a highly optimized fashion. If you have actual numerical calculations that are compile-once, run-many-many-many-times, then you will see a huge performance benefit, amortizing th…
But this is a false choice. Mature JIT-based systems give you the best of both worlds by starting in an interpreter and then switching to a JIT on a per-function basis as code gets hot.
Obviously static/strong typing is winning. Last man standing are JavaScript and Python, the former transforms into a compilation target (like Elm), the latter doing some kind of gradual typing (like mypy). I think dynamic typing has its place, but more in experimental design and prototyping than in bigger application development (big IMHO).
> Obviously static/strong typing is winning. ... > I think dynamic typing has its place This is why I wish Groovy with it's combined static / dynamic typing abilities was a) better and b) more popular. Its ability to interweave static and dynamic typed code is really spectacular when it works. Unfortunately there are a lot of holes and it can still be quite painful when in static mode, so I mainly only use it for per…
Groovy originally never had static typing, but was only a dynamic typed complement to Java's static typing. It worked best for this purpose (e.g. testing and manipulating Java classes, scripting in Grails, a DSL for build scripts in Gradle) but fell flat when version 2 retrofitted it with static typing and promoted it as a replacement for Java, on the JVM and Android. Best to use Groovy with a language built from the ground up to be statically typed, like Java, Scala, or Kotlin.
Having said that, I've actually since found Clojure to be better than Groovy at testing Java classes. A well-placed macro can often cut out syntactic clutter when testing some repetitive scenario.