Re: [julia-users] When Julia v1.0 will be released?
On Friday, July 8, 2016 6:43:36 PM CDT Daniel Carrera wrote: > For that matter, will there be upper case functions for every > concrete type? ... I'm just curious. I wouldn't actually use that feature. Yes, it's just the constructor. In most cases you don't have to define them manually, they are created automatically. --Tim
Re: [julia-users] When Julia v1.0 will be released?
On 8 July 2016 at 17:20, Tim Holy wrote: > The string unification is already in julia-0.5. > I don't think I know what "string unification" means, but I guess part of it is that Base.String will become ok to use again? > There are functions called String(), Int(), and Float64(). In some cases > there > are lowercase variants, and these often "do more" (e.g., `float` will > parse a > string and return an AbstractFloat). The uppercase versions are the > minimalist > type-conversion forms. > > Int isn't an alias for Int64: it's an alias for either Int32 or Int64, > depending on whether you have a 32-bit or 64-bit computer. There's no > analogous issue for Float32/Float64 (these are not CPU-dependent types), > which > is why Float won't become an alias for one of them. > Great. And thanks for explaining. Will there also be Int32() and Int64() then? For that matter, will there be upper case functions for every concrete type? ... I'm just curious. I wouldn't actually use that feature. So I think your list is as done as it's going to get :-). > > --Tim > Ok. I'm happy with String(), Int(), and Float64(). They are consistent which is the most important thing. Cheers, Daniel.
Re: [julia-users] When Julia v1.0 will be released?
The string unification is already in julia-0.5. There are functions called String(), Int(), and Float64(). In some cases there are lowercase variants, and these often "do more" (e.g., `float` will parse a string and return an AbstractFloat). The uppercase versions are the minimalist type-conversion forms. Int isn't an alias for Int64: it's an alias for either Int32 or Int64, depending on whether you have a 32-bit or 64-bit computer. There's no analogous issue for Float32/Float64 (these are not CPU-dependent types), which is why Float won't become an alias for one of them. So I think your list is as done as it's going to get :-). --Tim On Friday, July 8, 2016 7:02:19 AM CDT Daniel Carrera wrote: > This is just me, but I prefer to wait a bit longer than to get mistakes > frozen into the language. One bit that I care about is the names of some > types and functions. For example, right now we have > > - Base.String > - Base.ASCIIString > - Base.UTF8String > - Base.AbstractString > > So, I want to use "String" in my code but right now it's deprecated, and > the others look horrible. My understanding is that this is still in flux > and in the future there will be a sane "String" type that people can > default to without getting errors... I would very much like to see that > implemented and working before Julia is frozen. > > I also think that the type-related functions in Julia are inconsistent. I > think there should be functions called string(), int(), and float() that > return a String, Int64, and Float64. I don't think that the Julia > developers agree with me. > > Oh, and I think that Float should be an alias for Float64 just like Int is > an alias for Int64. > > So... there are some inconsistencies in Julia and I prefer to wait in the > hope that some of these might be ironed out before they become hard-coded > into the language. > > Cheers, > Daniel. > > On Thursday, 7 July 2016 16:47:28 UTC+2, Isaiah wrote: > > I knew that. > > > > > > The goal is 2017, if development community considers it to be ready. > > > > I don't mean to be too glib, but I fail to see how any answer is > > particularly actionable; it is certainly not binding. > > > > On Thursday, July 7, 2016 at 10:14:24 AM UTC-4, Isaiah wrote: > >>> When it is ready. > >>> > >>> On Thu, Jul 7, 2016 at 10:07 AM, Hisham Assi wrote: > I really like Julia (I am using it for my publications & thesis), but I > noticed that the versions are not really backward compatible. I am > still ok > with that, but many other people are waiting for the mature, stable > version (1.0) to start using Julia. So, when Julia v1.0 will be > released?
Re: [julia-users] When Julia v1.0 will be released?
On Friday, 8 July 2016 16:01:25 UTC+2, Scott Jones wrote: > > We are looking forward to being able to use v0.5, with fast anonymous > functions, cleaner array syntax, Gallium debugger and C++, and many many > other improvements > Cleaner array syntax? Tell me more? > (although the string changes mean we need to be careful not to use Julia's > base String type - currently we use ASCIIString/UTF16String for performance > reasons), but we aren't at all dependent on it (or v1.0, for that matter). > Yeah.
Re: [julia-users] When Julia v1.0 will be released?
It used to be that [[1,2],[3,4]] would try to concatenate the two vectors
into [1,2,3,4], which was inconsistent with Vector{Int}[[1,2],[3,4]] (which
returns a vector of vectors).
That syntax was deprecated in v0.4.x, and in v0.5 now means the same thing
(and the same as in any other language I've dealt with, a vector of
vectors).
That makes life a lot easier for people coming from JavaScript, Python, etc.
There is now also the possibility of using arbitrarily based arrays (and
even "permuted index" arrays, which means you can handle row-major arrays
now much easier), thanks to Tim Holy's wonderful (as always) contributions.
Great stuff, that will cut down a lot of complaints about only having
1-based, column major arrays in Julia.
On Friday, July 8, 2016 at 10:10:52 AM UTC-4, Daniel Carrera wrote:
>
>
> On Friday, 8 July 2016 16:01:25 UTC+2, Scott Jones wrote:
>>
>> We are looking forward to being able to use v0.5, with fast anonymous
>> functions, cleaner array syntax, Gallium debugger and C++, and many many
>> other improvements
>>
>
> Cleaner array syntax? Tell me more?
>
>
>
>> (although the string changes mean we need to be careful not to use
>> Julia's base String type - currently we use ASCIIString/UTF16String for
>> performance reasons), but we aren't at all dependent on it (or v1.0, for
>> that matter).
>>
>
> Yeah.
>
>
Re: [julia-users] When Julia v1.0 will be released?
This is just me, but I prefer to wait a bit longer than to get mistakes frozen into the language. One bit that I care about is the names of some types and functions. For example, right now we have - Base.String - Base.ASCIIString - Base.UTF8String - Base.AbstractString So, I want to use "String" in my code but right now it's deprecated, and the others look horrible. My understanding is that this is still in flux and in the future there will be a sane "String" type that people can default to without getting errors... I would very much like to see that implemented and working before Julia is frozen. I also think that the type-related functions in Julia are inconsistent. I think there should be functions called string(), int(), and float() that return a String, Int64, and Float64. I don't think that the Julia developers agree with me. Oh, and I think that Float should be an alias for Float64 just like Int is an alias for Int64. So... there are some inconsistencies in Julia and I prefer to wait in the hope that some of these might be ironed out before they become hard-coded into the language. Cheers, Daniel. On Thursday, 7 July 2016 16:47:28 UTC+2, Isaiah wrote: > > I knew that. >> > > The goal is 2017, if development community considers it to be ready. > > I don't mean to be too glib, but I fail to see how any answer is > particularly actionable; it is certainly not binding. > > > On Thursday, July 7, 2016 at 10:14:24 AM UTC-4, Isaiah wrote: >>> >>> When it is ready. >>> >>> On Thu, Jul 7, 2016 at 10:07 AM, Hisham Assi wrote: >>> I really like Julia (I am using it for my publications & thesis), but I noticed that the versions are not really backward compatible. I am still ok with that, but many other people are waiting for the mature, stable version (1.0) to start using Julia. So, when Julia v1.0 will be released? >>> >>> > >
Re: [julia-users] When Julia v1.0 will be released?
Actually, the blog post from StaffJoy ( https://blog.staffjoy.com/retro-on-the-julia-programming-language-7655121ea341#.35atllel3) never said that it turned out to be a mistake, in the conclusion they said: > The Julia language helped to create Staffjoy and turn it into a business, > and for that I am grateful It seemed clear to me that their reason for moving away from Julia was more an issue of Julia not being ready *yet* for the scaling and reliability they needed to provide for their business. People (like the company I consult for) who are using Julia in industry are well aware both of the pros and cons of using Julia in it's current state, we started a good deal later than StaffJoy, and things have been stable enough for us with v0.4.x that the pros have far outweighed the cons up til now (we had needed a number of critical fixes for string performance / correctness, but were able to get those in just before v0.4 was frozen). We are looking forward to being able to use v0.5, with fast anonymous functions, cleaner array syntax, Gallium debugger and C++, and many many other improvements (although the string changes mean we need to be careful not to use Julia's base String type - currently we use ASCIIString/UTF16String for performance reasons), but we aren't at all dependent on it (or v1.0, for that matter). Julia can be great for a small startup, in the case where the features in the current release version are enough for the application (and where you wouldn't be able to simply use some already existing library available in some other language), since you can quickly prototype things, and then turn those prototypes into production code. In our particular case, if we had continued with our original plan of developing in Python, C++, and some C, I really don't think we'd have things nearly so far along. On Thursday, July 7, 2016 at 11:23:34 AM UTC-4, John Myles White wrote: > > For industry, it probably means something similar. > > > I really hope people in industry won't act on this date, as it is not > nearly firm enough to bet a business on. We already have people writing > blog posts about how using Julia for their startup turned out to be a > mistake; we really don't need to encourage a new group of people to bet on > something that's not 100% guaranteed. > > Or to use industry language: that date isn't an SLA. > > -- John > > On Thursday, July 7, 2016 at 7:55:34 AM UTC-7, Chris Rackauckas wrote: >> >> This information is hugely beneficial in science/mathematics, especially >> for a PhD. It means that if you start a project in Julia now, although >> there will be some bumps for when versions change, the project will likely >> end after v1.0 is released (say 2 years?) and so your code should be stable >> when complete. It could have been 3-5 years for v1.0 (that's actually what >> I thought before reading it), in which case you know your code will be >> broken soon after publication, and so you should think about either not >> publishing the code or putting it to a Github repo with tests and be ready >> for the extra work of updating it. >> >> For industry, it probably means something similar. >> >> It's by no means a guarantee, but as a ballpark it's still extremely >> useful just to know what they have in mind. Since it's so soon, it also >> tells us that the "put the extra stuff in a package" instead of growing >> base mentality is how they are continuing forward (it's the leaner version >> of Julia that they have been pushing with at least v0.5 which gives them >> more mobility), which I think is good and it means I should plan to really >> plug into the package ecosystem, which may not be stable at the v1.0 >> release. >> >> On Thursday, July 7, 2016 at 7:47:28 AM UTC-7, Isaiah wrote: >>> >>> I knew that. >>> >>> The goal is 2017, if development community considers it to be ready. >>> >>> I don't mean to be too glib, but I fail to see how any answer is >>> particularly actionable; it is certainly not binding. >>> >>> >>> On Thursday, July 7, 2016 at 10:14:24 AM UTC-4, Isaiah wrote: > > When it is ready. > > On Thu, Jul 7, 2016 at 10:07 AM, Hisham Assi > wrote: > >> I really like Julia (I am using it for my publications & thesis), but >> I noticed that the versions are not really backward compatible. I am >> still >> ok with that, but many other people are waiting for the mature, stable >> version (1.0) to start using Julia. So, when Julia v1.0 will be >> released? >> > > >>>
Re: [julia-users] When Julia v1.0 will be released?
> For industry, it probably means something similar. > > > I really hope people in industry won't act on this date, as it is not > nearly firm enough to bet a business on. We already have people writing > blog posts about how using Julia for their startup turned out to be a > mistake; we really don't need to encourage a new group of people to bet on > something that's not 100% guaranteed. > This is indulging in a potential tangent, but I think the planned (non-binding) date conversation is often useful as a scope. FWIW, things are rapidly progressing on that front -- especially with what was on display at JuliaCon. It's clear Julia Computing is helping push a number of things now... I agree with John that it's not an SLA. And betting a complicated codebase on a rapidly evolving technology is a .. well .. significant risk. That said, there are lots of places Julia can still excel and be a great choice. If an industry application can just freeze out a version of julia for a specific task, it's not hard to keep it running using Julia v0.3 or whatever until it needs to be updated again. I don't think John meant anything against the last bit -- but for the silent readers, I wanted to throw in some of these thoughts. Cameron
Re: [julia-users] When Julia v1.0 will be released?
> > For industry, it probably means something similar. I really hope people in industry won't act on this date, as it is not nearly firm enough to bet a business on. We already have people writing blog posts about how using Julia for their startup turned out to be a mistake; we really don't need to encourage a new group of people to bet on something that's not 100% guaranteed. Or to use industry language: that date isn't an SLA. -- John On Thursday, July 7, 2016 at 7:55:34 AM UTC-7, Chris Rackauckas wrote: > > This information is hugely beneficial in science/mathematics, especially > for a PhD. It means that if you start a project in Julia now, although > there will be some bumps for when versions change, the project will likely > end after v1.0 is released (say 2 years?) and so your code should be stable > when complete. It could have been 3-5 years for v1.0 (that's actually what > I thought before reading it), in which case you know your code will be > broken soon after publication, and so you should think about either not > publishing the code or putting it to a Github repo with tests and be ready > for the extra work of updating it. > > For industry, it probably means something similar. > > It's by no means a guarantee, but as a ballpark it's still extremely > useful just to know what they have in mind. Since it's so soon, it also > tells us that the "put the extra stuff in a package" instead of growing > base mentality is how they are continuing forward (it's the leaner version > of Julia that they have been pushing with at least v0.5 which gives them > more mobility), which I think is good and it means I should plan to really > plug into the package ecosystem, which may not be stable at the v1.0 > release. > > On Thursday, July 7, 2016 at 7:47:28 AM UTC-7, Isaiah wrote: >> >> I knew that. >>> >> >> The goal is 2017, if development community considers it to be ready. >> >> I don't mean to be too glib, but I fail to see how any answer is >> particularly actionable; it is certainly not binding. >> >> >> On Thursday, July 7, 2016 at 10:14:24 AM UTC-4, Isaiah wrote: When it is ready. On Thu, Jul 7, 2016 at 10:07 AM, Hisham Assi wrote: > I really like Julia (I am using it for my publications & thesis), but > I noticed that the versions are not really backward compatible. I am > still > ok with that, but many other people are waiting for the mature, stable > version (1.0) to start using Julia. So, when Julia v1.0 will be > released? > >>
Re: [julia-users] When Julia v1.0 will be released?
This information is hugely beneficial in science/mathematics, especially for a PhD. It means that if you start a project in Julia now, although there will be some bumps for when versions change, the project will likely end after v1.0 is released (say 2 years?) and so your code should be stable when complete. It could have been 3-5 years for v1.0 (that's actually what I thought before reading it), in which case you know your code will be broken soon after publication, and so you should think about either not publishing the code or putting it to a Github repo with tests and be ready for the extra work of updating it. For industry, it probably means something similar. It's by no means a guarantee, but as a ballpark it's still extremely useful just to know what they have in mind. Since it's so soon, it also tells us that the "put the extra stuff in a package" instead of growing base mentality is how they are continuing forward (it's the leaner version of Julia that they have been pushing with at least v0.5 which gives them more mobility), which I think is good and it means I should plan to really plug into the package ecosystem, which may not be stable at the v1.0 release. On Thursday, July 7, 2016 at 7:47:28 AM UTC-7, Isaiah wrote: > > I knew that. >> > > The goal is 2017, if development community considers it to be ready. > > I don't mean to be too glib, but I fail to see how any answer is > particularly actionable; it is certainly not binding. > > > On Thursday, July 7, 2016 at 10:14:24 AM UTC-4, Isaiah wrote: >>> >>> When it is ready. >>> >>> On Thu, Jul 7, 2016 at 10:07 AM, Hisham Assi wrote: >>> I really like Julia (I am using it for my publications & thesis), but I noticed that the versions are not really backward compatible. I am still ok with that, but many other people are waiting for the mature, stable version (1.0) to start using Julia. So, when Julia v1.0 will be released? >>> >>> >
Re: [julia-users] When Julia v1.0 will be released?
> > I knew that. > The goal is 2017, if development community considers it to be ready. I don't mean to be too glib, but I fail to see how any answer is particularly actionable; it is certainly not binding. On Thursday, July 7, 2016 at 10:14:24 AM UTC-4, Isaiah wrote: >> >> When it is ready. >> >> On Thu, Jul 7, 2016 at 10:07 AM, Hisham Assi wrote: >> >>> I really like Julia (I am using it for my publications & thesis), but I >>> noticed that the versions are not really backward compatible. I am still ok >>> with that, but many other people are waiting for the mature, stable >>> version (1.0) to start using Julia. So, when Julia v1.0 will be >>> released? >>> >> >>
Re: [julia-users] When Julia v1.0 will be released?
OTOH many other people would prefer to wait a bit until certain design decisions are hammered out in a satisfactory way. Stable & mature software usually happens after spending a lot of time using and developing unstable & immature software. Incompatibilities are a pain, of course, but most packages do a fine job updating relatively quickly, and Compat.jl is a really nice solution -- you may find it useful. Best, Tamas On Thu, Jul 07 2016, Hisham Assi wrote: > I really like Julia (I am using it for my publications & thesis), but I > noticed that the versions are not really backward compatible. I am still ok > with that, but many other people are waiting for the mature, stable > version (1.0) to start using Julia. So, when Julia v1.0 will be released?
Re: [julia-users] When Julia v1.0 will be released?
I knew that. On Thursday, July 7, 2016 at 10:14:24 AM UTC-4, Isaiah wrote: > > When it is ready. > > On Thu, Jul 7, 2016 at 10:07 AM, Hisham Assi > wrote: > >> I really like Julia (I am using it for my publications & thesis), but I >> noticed that the versions are not really backward compatible. I am still ok >> with that, but many other people are waiting for the mature, stable >> version (1.0) to start using Julia. So, when Julia v1.0 will be >> released? >> > >
Re: [julia-users] When Julia v1.0 will be released?
I knew that. On Thursday, July 7, 2016 at 10:14:24 AM UTC-4, Isaiah wrote: > > When it is ready. > > On Thu, Jul 7, 2016 at 10:07 AM, Hisham Assi > wrote: > >> I really like Julia (I am using it for my publications & thesis), but I >> noticed that the versions are not really backward compatible. I am still ok >> with that, but many other people are waiting for the mature, stable >> version (1.0) to start using Julia. So, when Julia v1.0 will be >> released? >> > >
Re: [julia-users] When Julia v1.0 will be released?
When it is ready. On Thu, Jul 7, 2016 at 10:07 AM, Hisham Assi wrote: > I really like Julia (I am using it for my publications & thesis), but I > noticed that the versions are not really backward compatible. I am still ok > with that, but many other people are waiting for the mature, stable > version (1.0) to start using Julia. So, when Julia v1.0 will be released? >
[julia-users] When Julia v1.0 will be released?
I really like Julia (I am using it for my publications & thesis), but I noticed that the versions are not really backward compatible. I am still ok with that, but many other people are waiting for the mature, stable version (1.0) to start using Julia. So, when Julia v1.0 will be released?
