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

JuliaLang: The Ingredients for a Composable Programming Language

white.ucc.asn.au

Post reply on HN
Print view View original

51–60 of 228 posts

Re: JuliaLang: The Ingredients for a Composable Programming Language

#51

Post by mumblemumble »

cultus wrote: post #25
tgflynn wrote: post #17

Julia is a language I really wanted to like, and to a certain extent I do. However after spending some time working with it and hanging out on the Discourse channels (they certainly have a very friendly and open community, which I think is a big plus), I've come to the tentative conclusion that its application domains are going to be more limited than I would have hoped. This article hits on some of the issues that t…

People write large-scale systems in dynamically-typed languages all the time. Multiple dispatch and macros make clean scaling easier than it would be in most other dynamic languages. Its competitors in numerical performance are C/C++ and Fortran, which are both minefields (C much more so). Julia is definitely safer in practice than these kind of languages with weak, unsafe type systems. I'm not saying static types do…

> I'm not saying static types don't have benefits as well,

It's funny; formerly I was a die-hard fan of static typing, but, lately, my opinions have become more nuanced. Something more along the lines of, "Yeah, I'd never want to just remove the type annotations from my Java code and then try to maintain the result, but some dynamic languages allow me to have a fraction as much code to maintain in the first place."

I'm also beginning to wonder if my feelings about dynamic languages have been unduly influenced by some particularly popular, and also particularly undisciplined, dynamic languages. JavaScript and PHP, for example.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#52

Post by giornogiovanna »

socialdemocrat wrote: post #28
Iwan-Zotow wrote: post #12

Composable? Julia and composable?!? They decided on sequence range [1...N], instead of [0...N) like Python. Try to compose that.

Depends on what you work on. When doing more computer science like stuff, such as computing memory offsets etc, then 0-based indexing is practical. But for numerical work 1-based indexing is usually easier to work with. Mathematical texts are already using 1-based indexing and hence that is what people are used to when thinking about math. I work with both and I never found this a big problem. This is on par with com…

> But for numerical work 1-based indexing is usually easier to work with.

That's not really true in my experience, since all the nice properties of zero-based indexing transfer perfectly over to mathematics.

But you're right, this isn't anything to abandon an otherwise wonderful language over.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#53

Post by nnq »

skybrian wrote: post #47
ScottPJones wrote: post #29

Earlier quoted context omitted.

I've been using Julia for non-scientific computing programs for almost 5 years now, and (especially now that it is stable since the 1.0 release) have found it well suited for general programming as well. Having a language that is easy to write (like Python), runs fast (like C/C++), and incredibly flexible & expressive (like Lisp) makes programming fun again!

Interesting, how does deployment work for you? What sort of executables do you ship?

Don't people mostly ship containers nowadays? Or deploy code but standardize on language version.

Why t f would you want to ship / deploy a naked executable in 2019?!

Re: JuliaLang: The Ingredients for a Composable Programming Language

#54

Post by eigenspace »

cosmojg wrote: post #49
cmcaine wrote: post #8

Earlier quoted context omitted.

The other replies are slightly out of date and imprecise. PackageCompilerX replaced PackageCompiler (and there's a PR open that will pull all the X work in soon). The binaries produced bundle the whole Julia sysimage by default and they're quite big, but they are quite fast! A more traditional static compilation approach is being tried with StaticCompiler.jl by tshort, but it's in early development.

> A more traditional static compilation approach is being tried with StaticCompiler.jl by tshort, but it's in early development. The moment this ships, there will no longer be any reason to use any other garbage-collected language.

What does this have to do with garbage collection?

If your concern is about latency in real time systems, Garbage collection isn't the problem, heap allocating memory is. Julia makes it easy to never allocate anything on the heap (unlike most garbage collected langauges).

Check out this talk this discusses this in detail in the context of robotics: https://www.youtube.com/watch?v=dmWQtI3DFFo

Re: JuliaLang: The Ingredients for a Composable Programming Language

#55

Post by skybrian »

nnq wrote: post #53
skybrian wrote: post #47

Earlier quoted context omitted.

Interesting, how does deployment work for you? What sort of executables do you ship?

Don't people mostly ship containers nowadays? Or deploy code but standardize on language version. Why t f would you want to ship / deploy a naked executable in 2019?!

Containers are common for server-side code but not for mobile, desktop, or client-side web code.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#56

Post by [deleted] »

short_sells_poo wrote: post #40
tgflynn wrote: post #17

Julia is a language I really wanted to like, and to a certain extent I do. However after spending some time working with it and hanging out on the Discourse channels (they certainly have a very friendly and open community, which I think is a big plus), I've come to the tentative conclusion that its application domains are going to be more limited than I would have hoped. This article hits on some of the issues that t…

You touch upon some interesting pain points. I really like Julia and working with it is a pleasure. Except the Module system, which feels unnecessarily arcane. I'm happy to be educated on why, but it seems to successfully combine the awkwardness of C-style #include with the mess of a free-form module system. The end result is a Frankenstein monster where technically everything is possible, everything could be include…

[deleted]

Re: JuliaLang: The Ingredients for a Composable Programming Language

#57

Post by awb »

FranzFerdiNaN wrote: post #15
smabie wrote: post #10

Julia is great. It’s significantly simpler than Python while also being much more expressive. It’s too bad the typing is only for dispatch, but hopefully someone will write a typechecker someday. I’ve found it surprisingly refreshing to not have to think about classes and just add functions on objects wherever I want. Some languages solve this with monkey patching (which is bad), others like Scala with an extension c…

Python will still be used 20 years from now. The clear advantage of Python is the enormous ecosystem that is available, the millions of questions on SO giving solutions to every problem you can run into, the books and learning materials etc, programmers and corporations having invested loads of time and effort in building, maintaining and battle-testing libraries. Don't get me wrong, i think Julia is an amazing langu…

> Python will still be used 20 years from now

So much technology has come and gone since 2000. If innovation continues to accelerate I'd be hesitant to predict what 2040 will look like.

Programming might become so simple and automated that we won't need StackOverflow to the extent we do today.

It's really hard to predict the next year or two let alone the next 20.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#58

Post by krastanov »

mark_l_watson wrote: post #18
xvilka wrote: post #2

I hope Julia will be more popular in bioinformatics. Personally, I have a high hopes for BioJulia[1][2][3] and the amazing AI framework FluxML[4][5] + Turing.jl[6][7]. Apart from the speed, they offer some interesting concepts too - I recommend to check them out. [1] https://biojulia.net/ [2] https://github.com/BioJulia [3] https://github.com/BioJulia [4] https://fluxml.ai/ [5] https://github.com/FluxML/ [6] https://…

FluxML is amazing, so much nicer than using TensorFlow.

I will have to disagree. FluxML is indeed great, but it changes often and it does not support many of the advanced features of TensorFlow (neither is there a package that seamlessly works with Flux in order to support these features). It is getting there, but Tensorflow v2 is pretty great itself, and frequently faster. But FluxML might soon be as good or better.

Also, to be fair, FluxML is backed by a couple of people while Tensorflow is backed by megacorps, so it is already impressive how much they have done.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#59

Post by unlinked_dll »

nnq wrote: post #53
skybrian wrote: post #47

Earlier quoted context omitted.

Interesting, how does deployment work for you? What sort of executables do you ship?

Don't people mostly ship containers nowadays? Or deploy code but standardize on language version. Why t f would you want to ship / deploy a naked executable in 2019?!

Not all of us are web developers.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#60

Post by UncleOxidant »

I really like Julia a lot and actually used it in a work project a few years back.

However, there's the debugger issue. There are several debugger alternatives. It's tough to figure out which debugger is canonical (or is any of them the canonical debugger?). The one that seems to being used most at this point is Debugger.jl. However, it's exceedingly slow if you're debugging sizeable operations (matrix multiplies, for example) - I'm talking hitting 'n' to step to the next line and then waiting several minutes for it to get there. There's also Rebugger.jl, MagneticReadHead.jl (IIRC) and Infiltrator.jl among others. I finally found that Infiltrator.jl was a lot faster for that machine learning program I was trying to debug, but it's rather limited in features (the only way to set breakpoints it seems is by editing your source, for example).

And this isn't the only case where there are multiple packages for achieving some task and you're not quite sure which one is the one that's the most usable. I think what the Julia community needs to do is maybe add some kind of rating system for packages so you can see which packages have the highest rating.

Post reply on HN