Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming Technology

Is Julia the Next Big Programming Language? MIT Thinks So, as Version 1.0 Lands (techrepublic.com) 386

Julia, the MIT-created programming language for developers "who want it all", hit its milestone 1.0 release this month -- with MIT highlighting its rapid adoption in the six short years since its launch. From a report: Released in 2012, Julia is designed to combine the speed of C with the usability of Python, the dynamism of Ruby, the mathematical prowess of MatLab, and the statistical chops of R. "The release of Julia 1.0 signals that Julia is now ready to change the technical world by combining the high-level productivity and ease of use of Python and R with the lightning-fast speed of C++," says MIT professor Alan Edelman. The breadth of Julia's capabilities and ability to spread workloads across hundreds of thousands of processing cores have led to its use for everything from machine learning to large-scale supercomputer simulation. MIT says Julia is the only high-level dynamic programming language in the "petaflop club," having been used to simulate 188 million stars, galaxies, and other astronomical objects on Cori, the world's 10th-most powerful supercomputer. The simulation ran in just 14.6 minutes, using 650,000 Intel Knights Landing Xeon Phi cores to handle 1.5 petaflops (quadrillion floating-point operations per second).
This discussion has been archived. No new comments can be posted.

Is Julia the Next Big Programming Language? MIT Thinks So, as Version 1.0 Lands

Comments Filter:
  • by account_deleted ( 4530225 ) on Wednesday August 29, 2018 @12:24PM (#57218680)
    Comment removed based on user account deletion
  • by king neckbeard ( 1801738 ) on Wednesday August 29, 2018 @12:25PM (#57218688)
    Obligatory Betteridge's Law Post.
  • by kalpol ( 714519 ) on Wednesday August 29, 2018 @12:26PM (#57218704)
  • Great.. (Score:5, Insightful)

    by Anonymous Coward on Wednesday August 29, 2018 @12:29PM (#57218734)

    Great... Just what we need... another language.. oh wait, that will need a new package manager.. and new frameworks.. and..
    screw it I'll just stick to C++.

    • Having languages to choose from is a good thing. Saying Julia is the perfect language may be pushing it, because it may be the perfect Language for MIT, and research and education. It may not be a good language for businesses who may want more CRUD applications, and/or Heavy Database work and reporting.
      Julia seems to trying to compramise on the fight within MIT whose better. C++,Python, R and Ruby (Currently the most popular languages Outside of Java* ). They basicly took the key strengths of the differe

  • by Bruce Perens ( 3872 ) <bruce@perens.com> on Wednesday August 29, 2018 @12:39PM (#57218824) Homepage Journal

    There is always going to be argument about which language is the best, which Linux distribution, which web framework, and systemd.

    I have been using Crystal [crystal-lang.org] and the Lucky Web Framework [luckyframework.org] for a large project, and it's been great. Crystal's handling of types, and the fact that you get all of the error-killing power of tight typing while you often don't have to specify the types at all because they are inferred, has make my code cleaner and easier to write, with fewer bugs and less need for testing. You write it like an interpreted language (it follows Ruby syntax, but treats typing and metaprogramming differently) and it has compiled speed (uses LLVM).

    • by Desler ( 1608317 )

      it follows Ruby syntax

      That's supposed to be a selling point?

      • Would you rather that white space had syntactic significance? I only know two programs where that's the case: make, and python. And even the author of make was clear that was a mistake. Guido is a nice guy, but he really blew that one.
        • Occam is also whitespace sensitive, as part of the logic for determining design bugs. I don't mind it, although it's not everyone's preference. Occam is one of the few languages in which programs are provable, so I'm careful about arguing about design defects.

    • by farble1670 ( 803356 ) on Wednesday August 29, 2018 @03:55PM (#57220346)

      I have been using Crystal [crystal-lang.org] and the Lucky Web Framework [luckyframework.org] for a large project, and it's been great. Crystal's handling of types, and the fact that you get all of the error-killing power of tight typing while you often don't have to specify the types at all because they are inferred, has make my code cleaner and easier to write, with fewer bugs and less need for testing. You write it like an interpreted language (it follows Ruby syntax, but treats typing and metaprogramming differently) and it has compiled speed (uses LLVM).

      I'm sure your employer (or contractor) is ecstatic about the fact that they'll have to pay 3x the going rate to find devs that can work on the project you've built. Well actually that's not true. They'll have to pay someone to completely re-write the project when they can't find anyone to work on it and / or the niche framework you've picked is no longer supported / evolved.

      Maybe it was a pet project though.

      • Your viewing this from the perspective of the sort of programmer who is hired like an interchangeable cog. I'm definitely not one of those commodity guys. In this case it's not an employer, but investors. They are probably more concerned with time-to-market than anything else. Ruby-on-rails was the standard platform for web startups for a long time. Crystal is taking it's place. Node was not considered because JavaScript is just not a nice language to write in,
        • by farble1670 ( 803356 ) on Wednesday August 29, 2018 @06:55PM (#57221258)

          Your viewing this from the perspective of the sort of programmer who is hired like an interchangeable cog.

          If you are telling me that you develop in a way that isn't easily picked up by another engineer, I don't think you are the master you think.

          Software engineering is... engineering. That means it's well documented, easily understood standard practices. Part of that is choosing a language, toolchain, and development environment that is stable and well understood.

          They are probably more concerned with time-to-market than anything else.

          Probably? So you explained it to them right? They probably don't understand the implications of your choices.

  • No. (Score:5, Informative)

    by xtal ( 49134 ) on Wednesday August 29, 2018 @12:39PM (#57218826)

    C is lightning fast and is the tool for when you know what you're doing.

    Python is .. for everything else.

    Everything else just turns into a clusterfuck over time. C and Python have somehow avoided turning into clusterfucks by being simple, while building an unstoppable freight train of reference work.

    Julia solves lots of problems in a specialized domain, but most programming is laughably mundane.

    • Re: (Score:2, Flamebait)

      by JoeDuncan ( 874519 )

      Everything else just turns into a clusterfuck over time.

      Exactly, try looking at ANY fully functional Julia code (not the trivial examples from docs & tutorials) - it's ALREADY a giant clusterfuck, it's unreadable gobbledygook on any kind of usable scale that isn't a trivial demo.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Python is a clusterfuck. Not enough people recognize it in time.

      • Python is [also] a clusterfuck. Not enough people recognize it in time.

        Almost all programming languages that end up in common use become messy as features and adjustments based on practical experience and industry changes are added over time. The originators cannot anticipate all future needs and trends/fads*.

        C# used to be relatively simple because it applied to hard lessons of Java, but has grown screwier over time to keep up with the Jones' (along with Java).

        Just try to do reflection on nullable C# types

        • when you want to automate class/schema mapping between layers

          I honestly don't even know what this means. All I have is some vague idea. Do you have a practical example?

          • I imagine they're referring to features typically provided by ORM frameworks, in that it'll map classes to each of your database tables (see: ActiveRecord, Hibernate, etc)
        • by Zmobie ( 2478450 )

          While I definitely agree the fad driven additions cause a lot of headaches in languages, playing devil's advocate, some of the features are added because of a growing need from the user base and no one wants to rewrite their codebase just because a whole new language was designed for one feature (even a big feature). I mean, C++ was basically just C with class support tacked on originally so that code would easily port into it, and look how popular C++ remains.

          To borrow your example, C# has had some very m

        • by nmb3000 ( 741169 )

          Just try to do reflection on nullable C# types, for example. It's a WTF moment. When you investigate why it's that way, you learn that nullable types are an ugly hack on top of the existing dynamic type sub-engine.

          In what way? Aside from some magic around implicit type conversion, Nullable types were added to the language through the Nullable<T> generic struct and some new language syntax to support the int? syntactic sugar (instead of Nullable<int>). Detecting and reflecting on a nullable type is just a matter of using Nullable.GetUnderlyingType(Type), or if you want to do it the long way you can always use the IsGenericType, IsValueType, GetGenericTypeDefinition(), and GenericTypeArguments on the Typ

    • Re:No. (Score:5, Insightful)

      by fahrbot-bot ( 874524 ) on Wednesday August 29, 2018 @01:08PM (#57219008)

      C is lightning fast and is the tool for when you know what you're doing.

      Python is .. for everything else.

      So Python when (a) you don't need fast and (b) you don't know what you're doing. :-)

      [ And when you don't want C, but want fast and you know what you're doing, use Perl. ]

      • So Python when (a) you don't need fast and (b) you don't know what you're doing. :-)

        [ And when you don't want C, but want fast and you know what you're doing, use Perl. ]

        Actually . . . I prefer to use a language that let's others, who don't know what they are doing . . . understand what I am doing, who ends up doing it for them.

        Folks who don't know what they are doing . . . usually end up not doing anything, anyway.

        • Actually . . . I prefer to use a language that let's others, who don't know what they are doing . . . understand what I am doing, who ends up doing it for them.

          That's largely a factor of the programmer, not the language. One can write (un)readable code in any language. For example, just because Perl allows one to write cryptic code, doesn't mean one must and doesn't mean one can't add documentation when appropriate and/or to clarify cryptic code when used.

          For example, several of my co-workers have mentioned that they can identify a piece of my code in (say) C, Java, Ksh and Perl by my style, structure, clarity and documentation and have no problems following m

    • My impression is that for every language other than C/C++, there are three things more important than almost any feature of the language or runtime:

      (1) the package system - how you search+download+reference them, how dependencies+conflicts are managed, how updates are managed
      (2) the build system
      (3) editor integration, be it Emacs or Sublime or VSCode

    • C and Python have somehow avoided turning into clusterfucks by being simple, while building an unstoppable freight train of reference work.

      I use Python much more than C or C++, but seriously. The complication between Python 2.x and 3.x compatibility is immense. And then there are the third-party libraries that frequently are no platform independent. To try to address this nightmare, the concept of Python virtual environments has been created as a hacky workaround.

      For these reasons, I cannot agree with y

    • R.I.P. Python (Score:2, Insightful)

      by Anonymous Coward

      Python 2.x to 3.x incompatibility is a total clusterfuck, and it's why I left the language.

      At this point I only trust people if can define their language up front in a way that can be safely extended and hopefully standardized. I'm not going to muck with Python again only to have it break in some version 4 or version 5. (Yes, I still have code in production with K&R prototypes even though ANSI C has been around for nearly 30 years.)

      Languages that offer useful pure functional programming are the future w

      • by Zmobie ( 2478450 )

        Functional languages are great, but difficult for a lot of people to wrap their heads around. I still routinely see people completely misuse even the simple C# lambda expressions because they don't understand the paradigms of that type of programming. Granted the lambdas in C# are confusing to understand how they execute under the hood just due to the nature of how they implemented the feature (and people assuming just because a generic functions is defined it must be the best one for their particular nee

    • Re:No. (Score:5, Insightful)

      by serviscope_minor ( 664417 ) on Wednesday August 29, 2018 @01:57PM (#57219392) Journal

      C is lightning fast and is the tool for when you know what you're doing.

      C is a lightning fast tool for people who are obsessed with micromanaging things which can be easily automated. If yu want lightning fast performance (often faster) but don't really want to do things by hand that a computer can be easily taught how to do then there's C++.

      Everything else just turns into a clusterfuck over time. C and Python have somehow avoided turning into clusterfucks by being simple

      C moves the complexity of the language into every single project that uses it. So the language per-se might not be a cluster fuck, but it is the epicentre of a custerfuck of biblical proportions.

    • My [limited,

      Julia solves lots of problems in a specialized domain, but most programming is laughably mundane.

      This.
      Programming is a tool. There needs to be a problem to solve... I find too many coders fail to see that and get lost in how clever they're trying to be.

    • "C is lightning fast and is the tool for when you know what you're doing."

      No one knows what they're doing.

    • Re:No. (Score:4, Interesting)

      by fortytwoQAM ( 1543673 ) on Wednesday August 29, 2018 @03:50PM (#57220316)
      TL; DR: There are a lot of great and nuanced features of Julia, but if you're writing off Julia without understanding the potential power of "multiple dispatch", I'd really encourage you to read up on multiple dispatch and its benefits. Also, if your programming is "laughably mundane", watch out that a machine or machine-learned model doesn't take your job. I'm surprised this got upvoted to a 5. One of the aims of Julia is to 'solve' or 'avoid' the "two-language problem". Interestingly, you just embraced the two-language problem. You can call and use C-code from Python, but that's not necessarily simple. At that point, anything that is "fast" from a computational standpoint now needs someone who's expert at both languages to provide functionality. Most Julia packages provide "fast" code, while allowing any Julia user to help and fix things by learning Julia - i.e. the "one-language satisfaction" ? Julia code is generally "fast" while being very "expressive" - i.e. an aim at trying to avoid the 2-language problem. Crystal looks very interesting and is an "LLVM-language" like Rust and Julia, but I don't see any mention of "N-Dimensional Arrays". To quote another poster, "dealing with ND Arrays with for loops is like pulling teeth". Python has NumPy, but all the good syntax was taken by the time NumPy came along (mid-2000s), so the ND Array syntax can be quite cumbersome with Python, as much as I like the NumPy/SciPy stack. I've been working almost exclusively with Julia over the past 3 months. I'm parsing large-ish (~1GB) binary files generated by arduino boards and a lot of signal analysis work. I'm absolutely loving it, but Julia has been on my radar for a few years now. A few years ago I did a bunch of the Euler challenges with Julia while trying to write as little code as possible and that was a fun exercise to see how powerful some of the syntax is.
    • by T.E.D. ( 34228 )

      C is lightning fast and is the tool for when you know what you're doing.

      C's good for situations where your development machine or target for some reason can't handle a smarter compiler. Its actually *too* low level for best optimization, as it forces the user to specify too much detail and provides too much unnecessary aliasing capabilities.

      It just looks blazingly fast if you only compare it to interpreted or VM-based languages.

  • by The Original CDR ( 5453236 ) on Wednesday August 29, 2018 @12:42PM (#57218844)
    Quote [imdb.com]: "These damn things are as hot as a stiff cock!"
  • by presidenteloco ( 659168 ) on Wednesday August 29, 2018 @12:47PM (#57218882)

    I can see perhaps adding some greek symbols to ascii for variable names, function names, but allowing full unicode is a disaster of a design decision since it permits all kinds of deliberately obscured code.

    Languages need to be about well-chosen constraints to guide creativity, not about absolute freedom. Libertarian languages are a bad idea, since code is maintained and extended collectively.

    Unicode for string data, yes, of course. But entity names in the language, no, no, no.

    • In other languages you could define main(), maiN(), maIn(), maIN(), mAin(), mAiN(), mAIn(), mAIN(), Main(), MaiN(), MaIn(), MaIN(), MAin(), MAiN(), MAIn(), and MAIN(). It's probably a bad idea to do so. Whether you choose to or not isn't the responsibility of the language.
      • by dfghjk ( 711126 )

        But these are a consequence of allowing mixed case identifiers, something you WANT to do. The other is a consequence of something you don't want to do. A feature or capability without redeeming qualities shouldn't be done simply because it can be. Doing the right thing isn't about whose responsibility it is.

        • But these are a consequence of allowing mixed case identifiers, something you WANT to do.

          True

          The other is a consequence of something you don't want to do.

          False, it's a consequence of something you seem to think someone else could use wrongly. Other people already have useful cases in mind.

          A feature or capability without redeeming qualities shouldn't be done simply because it can be.

          True, and the fact that someone else can think of redeeming qualities, but that you cannot, is a personal issue. Still not a fault of the language.

          Doing the right thing isn't about whose responsibility it is.

          True, but not an argument against allowing something optional.

        • I don't see any advantage in case-sensitive identifiers. I started without it, in Pascal, and it is just more natural and avoids lots of trouble. You can just use identifiers like spoken words, not worrying which word in it starts with a capital or not. To distinguish types from variables just add a t in front.
      • and try to limit the egregiousness of bad code.

        One example. Languages should probably enforce the presence of a method header comment.
        If you still choose to make it a useless comment, you're just advertising your complete misfit / incompetent status.

        Language made it easier to do the right thing and harder to do a bad practice.

        Same goes for meaningful indenting enforcement. It's a good thing, because it doesn't hurt, and encourages comprehensible code.

        The freedom you NEED as a programmer is freedom to
        - organ

    • by mark-t ( 151149 )
      I think that person that needs unicode in their identifiers to obfuscate their code lacks imagination
    • I can see perhaps adding some greek symbols to ascii for variable names, function names, but allowing full unicode is a disaster of a design decision since it permits all kinds of deliberately obscured code.

      do they allow full unicode. C++ allows unicode[*], but it specifies which character ranges within unicode can form part of an identifier. So you can have a poop emoji as an identifier, but not a thin space.

      [*] which is to say it doesn't and does sort of, in the most C++ish way possible. C++ is defined in

    • by Zmobie ( 2478450 )

      Yes and no. Within an organization those problems can be solved with a style guide that is enforced properly. Now, in the open source community and development at large you have a solid point though. Still, I would argue some of it could be curved with generally accepted guidelines just like how camel case is the norm for lots of function/method naming, hungarian notation is still heavily used in dynamic type languages, and almost universally it seems everyone uses caps for constants. These are things t

  • So complete dumpster fire then - got it

  • Because almost all the other names have been taken: https://en.wikipedia.org/wiki/... [wikipedia.org]

    After that, all we have left is "Zittzers".

    If you don't get the reference, you don't belong here.

  • by jma05 ( 897351 ) on Wednesday August 29, 2018 @12:59PM (#57218956)

    If MIT had been having its way, we'd all be using Scheme.

    Julia is a better Octave (open source Matlab replacement) - good for computer scientists, but software engineers will not be interested. Question is, will the scientific community create enough definitive libraries to provide alternatives for Matlab toolboxes. Not enough seem to have attended the Octave party.

    Also, computer scientists don't define popular adoption of programming languages. Else, we'd be using Haskell/Scheme by now.

  • by fahrbot-bot ( 874524 ) on Wednesday August 29, 2018 @01:02PM (#57218964)

    ... for developers "who want it all" ...

    I want: local/global "goto" operations; unchecked pointers and arrays; brace *and* white-space (for you Python freaks) block delineation; weird operators like "+-+", "=!=", "-+/*" and "..."; support for casting on the *left* side of the assignment (ya, I did that on 4.3 BSD w/K&R C); random requirements for some variable to be in UPPER case and/or start with specific letters (for you FORTRAN fans) ...

    Feel free to add to this; I'll be back after I get a fourth cup of coffee.

    • ..are you having a day off?

    • by tgibson ( 131396 ) on Wednesday August 29, 2018 @02:01PM (#57219422) Homepage

      the readability of Perl with the brevity of COBOL.

    • by dargaud ( 518470 )

      weird operators like "+-+", "=!=", "-+/*" and "..."

      Just out of curiosity, what should those operators do ? Do they exist in some languages ?

      • by Kjella ( 173770 )

        Well "..." is the spread [mozilla.org] operator in Javascript, here's =!= [stackoverflow.com], it seems plausible that "+-+" might be interpreted as x+(-(+y)) which collapses to "x-y". Not sure about -+/* but Ruby should get a honorable mention for %/% [statmethods.net]. The most annoying thing about operators though is not each one, it's the precedence rules. For example in SQL "WHERE a OR b AND c = 1" when you mean "WHERE (a OR b) AND c = 1. I really, really wish some smart language would say "fuck that, we're not making obscure rules nobody remembers/noti

    • I want: local/global "goto" operations...

      Right. The language designers are clearly aware of this issue, they have created a library macro that kind-of does goto. But it is lame, I tried it. It is ugly with weird limitations. Obviously, the macro just tries to translate the goto into an equivalent using the existing structures, and that fails in many common cases. Plus @goto just plain looks ugly. This half measure is not enough. Doing the job properly is not rocket science.

  • What does this language accomplish that none of the other thousands of languages in existence do not?
    • by jma05 ( 897351 )

      It is the only array programming language with a decent JIT.
      It is a high-level array programming language like Matlab/Octave/R, while executing at about the speed of a native language like Fortran.
      If you prototype a lot of linear algebra functions in an interactive environment, this is the language for you. The thunder is somewhat stolen by newer tools like tensorflow, which give you GPU performance, while still providing a high-level language (Python).
      Still, Julia has meta-programming features. So it can d

      • Native C interface is a huge feature, this gives immediate access to a huge number of libraries. It mystifies me why so many language projects drop the ball on this one (most definitely including Java, if you don't agree then you just don't know JNI)

  • MatLab eh.. (Score:4, Funny)

    by volodymyrbiryuk ( 4780959 ) on Wednesday August 29, 2018 @01:23PM (#57219110)

    the mathematical prowess of MatLab

    Like arrays starting at index 1?

    • Cool thing about indexes starting at 0: you can just pretend the first element doesn't exist and suddenly your array starts at index 1.
  • http://www.zverovich.net/2016/... [zverovich.net]
    Like most of the comments here, not impressed... See the comments under the article for rebuttals. They have some good points, but I think this will only suit a niche user if it survives in the longer run.
  • No curly braces? Asymmetric 'end' doesn't work for me.

    No switch control statements? Seriously?

    Garbage collected = ick.

    Socket interface was written by mickey mouse. No protocol family? Apparently only works with IP (TCP/UDP only) and domain sockets. To say that Sockets.setopt is lacking is the understatement of the year.

    Included function library way too weak to take seriously.

    Julia is actually a lot better than I thought it would be. Was expecting typical academic snobbery. Yet it fails to bring anyth

  • by BrendaEM ( 871664 ) on Wednesday August 29, 2018 @02:52PM (#57219858) Homepage
    Nearly seamless multitasking over an entire network.
  • I think I've seen this headline "is xx the next big language" 1/2 a dozen times on this site....
  • by dbrueck ( 1872018 ) on Wednesday August 29, 2018 @03:48PM (#57220306)

    I read through the docs and was really liking what I was seeing... right up until the part that it says arrays are 1-based. Ah well, nevermind then.

    • This is the Right Way.

      Zero-based counting in computers has evolved from a useful efficiency trick during an era of scarce resources into an almost elitist vestigial organ that needs to be chopped off. All it leads to is more intense thought processes and off-by-one bugs.
      • Zero-based counting in computers has evolved from a useful efficiency trick during an era of scarce resources into an almost elitist vestigial organ that needs to be chopped off. All it leads to is more intense thought processes and off-by-one bugs.

        Actually, the opposite is true - zero-based indexing can help eliminate off-by-one bugs (see https://en.wikipedia.org/wiki/... [wikipedia.org]). It's also not true that the reasoning for it is efficiency (in addition to the wikipedia article, see Dijkstra's take on it - http://www.cs.utexas.edu/users... [utexas.edu])

      • This is the Right Way.

        According to who? Of course you are aware that the concept of zero was a relatively late development in the time line of mathematical history. Can you see how that might extend to your own preconception?

        Like OP, I view 1-based arrays as a flaw. Main reason: code written around zero based arrays tends to have fewer boundary conditions than one-based, as any skilled developer knows. I hope that the language designers are smart enough to address this, otherwise it is just going to keep coming back to haunt the

  • Installed Julia as a result of some earlier Slashdot post. Installed and played with it a bit and didn't get immediately pissed off by anything blatant, that's already good. Looked a bit deeper, found that it has extensible types but does not have methods on types, instead it has signature-based function dispatch. For me, the jury is still out on just how well it works. Otherwise, this one looks really promising.

    Like many others, I have been casting around for a great language for casual programming that al

  • Yet another programming language that promises to do it all.

Trap full -- please empty.

Working...