Thanks for all the information. 

The problem is probably not with the language releases itself (I take your 
word for it that point releases don't introduce incompatibilities) but with 
the package releases. Sometimes they lag behind  the language release (as 
I'm currently experiencing with Sundials) and sometimes they may well pass 
individual tests but then fail on real-world package dependencies which 
aren't noticed because they are not covered by tests. To give an example of 
the latter, a few weeks ago, when I started to test a major code re-write 
of my own, I got a set of "convert" errors. After digging around 
fruitlessly in my own code for several hours (the obscurity of the message 
didn't help), I finally discovered it was an error triggered by loading one 
package before another (forgot now which one it was, I think Colors.jl was 
involved). A third problem is that by depending on Python, some packages 
introduce all of the nightmares (and then some) of the multiverse of Python 
releases, especially on Linux (which is the cause of the error I'm 
experiencing with a 0.3.11 Julia/IJulia/Conda installation on Linux at the 
moment). A fourth problem is that, despite the assertion that I've seen 
that for-loops over Arrays should run at the same speed as vectorized code, 
I've found on several occasions that for loops are still quite a bit 
slower. It may be that I'm not writing it in the most optimal way but as 
far as I know I am following the documentation and guidelines that exist.

I know that all of these problems are solvable, but that's not the point I 
am trying to make. All of these issues take time that keep me away from 
writing the software that I am hired to write in a limited number of days, 
and my employers may not be interested in the reasons for why I can't get 
it to work on time. Please also note that when in the midst of a crisis and 
up against deadlines, I (and probably other users in similar situations) 
may not have time to file bug reports, and not even have the time to note 
down how I fixed or circumvented a certain problem.

I understand that my criticism may sound misplaced because I know that 
Julia is in early development, but as a "real" user of Julia (not involved 
in the development itself, but attempting to write real production code, 
rather than using it as an academic exercise), I'd rather let you know of 
my experience of using it. 

Thanks! And keep up the good work. Free software matters indeed - though so 
does paid-for.







  


On Friday, October 23, 2015 at 1:43:35 PM UTC+1, Stefan Karpinski wrote:
>
> Yes, my experience with upgrading large code bases to new point releases 
> is that no changes are required. Kris, if your experience with point 
> releases has been otherwise, it would be good to hear about specific issues 
> since those releases are strictly bug fix releases. Perhaps you are talking 
> about the last major upgrade from 0.2.x. to 0.3.x?
>
> On Fri, Oct 23, 2015 at 8:25 AM, Tony Kelman <[email protected] 
> <javascript:>> wrote:
>
>> >  I've been developing Julia code since release v0.3.7. Unfortunately 
>> this isn't the first time that I lose many hours having to figure out why 
>> something that works in one release stops working in a subsequent one.
>>
>> This surprises me. 0.4.0 is the only release that was intended to be 
>> breaking in any meaningful way since 0.3.0. Every point release 
>> announcement has said "We would like to get feedback if someone has a 
>> working program that breaks after this upgrade." I meant that seriously, if 
>> an unintended breaking change was made in any of the 0.3.x series and an 
>> issue was reported about it, we would find a way to fix it (for example, 
>> there was a problem in the embedding API that led us to put out 0.3.5 on an 
>> accelerated schedule to fix it). The same holds for 0.4.x relative to 0.4.0.
>>
>
>

Reply via email to