Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia 1.0

julialang.org

Post reply on HN
Print view View original

441–446 of 446 posts

Re: Julia 1.0

#441

Post by one-more-minute »

ksaitor wrote: post #440

> We want the speed of C with the dynamism of Ruby. We want a language that’s homoiconic, with true macros like Lisp, but with obvious, familiar mathematical notation like Matlab. We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. … they forgot…

Perhaps it would have been good to add “the reach of JavaScript”. Webassembly wasn’t around at the time of the post, but it’s a promising way to get there that’s actively being worked on.

Re: Julia 1.0

#442

Post by essenciary »

ChrisRackauckas wrote: post #179
StefanKarpinski wrote: post #166

Earlier quoted context omitted.

I do think we should add a code sample prominently on the page, however. I've always find it really frustrating when I look at a programming language and can't get a quick sense of how it looks. If a language looked like, say, APL, I'd be reluctant to use it even if it had an impressive ecosystem. Issue filed: https://github.com/JuliaLang/www.julialang.org/issues/115 .

Oh I thought the first tab had code and the complaint was it was too low. I guess that was a prototype build of the site. Yeah we should get that back.

Yeah, there is code set up in the page to add a code sample for each tab in the ecosystem. It's a matter of content (adding it).

Re: Julia 1.0

#443

Post by renox »

rrock wrote: post #398
renox wrote: post #392

Earlier quoted context omitted.

I already know about this but if you use someone else's code in a library for example in Julia the library will most likely only work with 1-indexed array, in Ada it will work with any base index. Default matters!

It's straightforward to write library code in Julia that handles any type of index. If it doesn't, it is probably old code from before the time before offset arrays. Take a look at Tim's linked blog post.

It is straightforward to create a language where a user can specify any type of index (like Ada), if you need to import a library everywhere to have the correct behaviour then this library should be a part of the language instead.

Re: Julia 1.0

#444

Post by FridgeSeal »

ksaitor wrote: post #440

> We want the speed of C with the dynamism of Ruby. We want a language that’s homoiconic, with true macros like Lisp, but with obvious, familiar mathematical notation like Matlab. We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. … they forgot…

JavaScript, whilst widely used, is not a language I would want to compare my own against when it comes to talking about quality and features, unless I want to talk about how actual thought went into my language.

Re: Julia 1.0

#445

Post by johnsea »

tavert wrote: post #425
ScottPJones wrote: post #417

Earlier quoted context omitted.

I complained also about the "cowboy" culture I saw among the Julia developers when I first started with it (people making a change directly to master, or merging there own PR without giving time for people around the world to review, or not having a minimum number of qualified reviewers before merging), but those days are gone, and I feel they've matured quite a lot in the past few years in that respect. Some of it I…

Just in the last few months BinDeps was broken by a "deprecation fix" that was completely wrong and using a name that didn't exist, and it got merged and released by the patch author before anyone else could look at it, breaking many downstream packages. Refactorings and major changes in ZMQ.jl and the web stack similarly get merged and released immediately with zero review, still. This is a major problem. Features i…

> Just in the last few months BinDeps was broken ...

What I don't understand is why you didn't just stay with old stable versions? You wouldn't be exposed to such issues, wouldn't you?

> It's not a development culture I would rely on when products and money and jobs are at stake

On the other hand this 'development culture' has brought brilliant results in a relatively short amount of time with a relatively small team.

There was a talk [1] at the Juliacon 2018 where a company very successfully replaced an IBM product with Julia code. At 48:07 there was a question 'about problems with changes in Julia'. Answer: they started with v0.3 and 'didn't really have many problems'. They 'didn't use anything particularly exotic'. So, yes, I'd say if you adapt to the given situation it can (could have) work(ed).

I'm not convinced that a non-cowboy style would have been better. (And besides, this doesn't come free moneywise).

[1]: https://www.youtube.com/watch?v=__gMirBBNXY

Re: Julia 1.0

#446

Post by tavert »

johnsea wrote: post #445
tavert wrote: post #425

Earlier quoted context omitted.

Just in the last few months BinDeps was broken by a "deprecation fix" that was completely wrong and using a name that didn't exist, and it got merged and released by the patch author before anyone else could look at it, breaking many downstream packages. Refactorings and major changes in ZMQ.jl and the web stack similarly get merged and released immediately with zero review, still. This is a major problem. Features i…

> Just in the last few months BinDeps was broken ... What I don't understand is why you didn't just stay with old stable versions? You wouldn't be exposed to such issues, wouldn't you? > It's not a development culture I would rely on when products and money and jobs are at stake On the other hand this 'development culture' has brought brilliant results in a relatively short amount of time with a relatively small team…

These incidents were with respect to 0.6-supporting versions of packages. Pinning is a good idea for reproducability but it's not the default, so updating packages or new installs are broken when careless things make it instantly into a release.

Talk to me when google, amazon, microsoft, facebook etc are publicly using and officially supporting julia on cloud platforms or even infrastructure libraries like protobuf.

The carelessness isn't responsible for or helping anything. A good diffeq and optimization suite have been built despite the prevalence of careless practices, not because of them.

It's not a question of money either, just patience and code review and recognition of how many things downstream are going to be affected by mistakes. You'll save more time in not having to put out as many fires than it will cost to slow down and not be in such a rush at all times.

Post reply on HN