4 ms·

> Julia says: > A language must compile to efficient code, and we will add restrictions to the language (type stability) to make sure this is possible. > A la

• adgjlsfhk1 5y ago
  no data types, no operator overloading, no extendability of new functions to existing objects, no C/Fortran interop, mediocre performance. Need I go on?
  • fantod 5y ago
    Also no (official) REPL.
    • AstroDogCatcher 5y ago
      The Julia crowd really need to hang less value on the REPL - people writing serious production code don't use one, and scientists using Python have moved on to notebooks. At this point, having Julia be so focused on the REPL is a weird affectation.
      • jakobnissen 5y ago
        I used notebooks when I did my PhD using Python, but have moved to the REPL using Julia on my PostDoc. The Julia REPL experience is so much nicer than Python's, it removes the need for notebooks completely for me.
      • patagurbon 5y ago
        Julia has great notebook support, the Ju in Jupyter stands for Julia after all. There's also the fantastic Pluto.jl for reactive notebooks. And the VSCode extension isn't quite IDE level, but that's just a matter of resources.
      • adgjlsfhk1 5y ago
        IMO, the REPL is really nice for exploration. I would never write code in it, but it serves as a really good doc search tool and quick way to check things. It helps that the Julia REPL is more inspired by the Lispy ones than python/R.
      • dash2 5y ago
        I'm a scientist, I use REPL a ton. Notebooks are fine too, but there's a thing called exploration and nothing beats REPL speed for that. In future it would be great to mashup something like repl.it with Jupyter notebooks, maybe with Medium-style wysiwyg. That might really win.
    • WoodenChair 5y ago
      Actually Java has had a repl called Jshell since JDK 9.
  • dgellow 5y ago
    Mediocre performance compared to what?
• iddan 5y ago
  Because people in that game value simplicity of use over anything else (performance, safety, maintenance) and Python is a top performer in that KPI while Java is not very good at this (though it is getting better but still)
  • edgyquant 5y ago
    This is a big part of it. People who are scientists write code that we would think is disgusting and don’t care that much about abstraction outside of mathematical functions. There’s a lot to learn with Java. I helped classmates in my intro to programming class when I went to college, because I already knew how to code, and I have no idea why they picked that language as an introduction language. After weeks people were still struggling because on top of the ideas like loops/variables/control flow now they are having to learn classes. Python was written with people like scientists in mind. Professionals write fast C libraries and then people who know just enough to get by use python to glue it all together.
    • jstx1 5y ago
      > People who are scientists write code that we would think is disgusting and don’t care that much about abstraction outside of mathematical functions. - plenty of scientists write good code; I think the "scientist can't code" meme is harmful. - most of the people that write PyTorch code aren't necessarily scientists - they're software developers (data scientists, ML engineers, research engineers, whatever title - but their main job is to write code) > Python was written with people like scientists in mind. Python had nothing to do with scientists when it started. It was written to be readable and easy to use and it started as a hobby project. It existed for over 15 years until the data science / ML ecosystem started growing around it.
      • AstroDogCatcher 5y ago
        I'd flip that meme slightly; it is true that scientists write shitty code...but it turns out computer scientists do exactly the same, and with less humility.
• edgyquant 5y ago
  The main reason is that a lot of scientific computing depends on ancient libraries written in Fortran or C, and a lot of newer libraries depend on GPUs for their matrix operations so need to be able to make calls to C/C++ modules that run directly to the GPU. This probably isn’t impossible for Java but that was never meant to be it’s niche, it doesn’t compile to machine instructions and prefers portability.
  • upbeat_general 5y ago
    I know FFI in Java is certainly possible and I’ve seen it at least a few times personally; is it that much harder than in Python or just less common due to the need? Python doesn’t compile to machine instructions either and there’s nothing that prevents GPU access from Java. In fact I’d bet in many cases pure Java beats Python + C library though it obviously depends on how much has to be written in pure python.
• ted_dunning 5y ago
  Java falls apart on the point about post factor extensibility. See this talk for examples: https://www.youtube.com/watch?v=kc9HwsxE1OY https://www.youtube.com/watch?v=kc9HwsxE1OY
• hjtkfkfmr 5y ago
  For once it's impossible to work in Java without an IDE and without creating a project. But you can just write a simple 20 line Python script to do some data mangling, no project with 30 IDE files required.
  • pjmlp 5y ago
    Between 1996 and 1999 there were hardly any IDEs available for Java outside Windows, and Forte was Solaris only. Visual J++, Visual Cafe and JBuilder were the main ones but not everyone was eager to buy them, while the JDK was free beer.
• yakubin 5y ago
  Julia is designed with interactive use and REPL in mind. Java is designed with enterprise software written by large teams and IDEs in mind. The first one, among other things, leads to valuing terseness. The seconds leads to valuing verbosity. I wouldn't want to deal with the usual Java boilerplate in an interactive session.
• StefanKarpinski 5y ago
  That’s a really good question and I’m not sure I fully understand all the reasons. One big one is that Java intentionally has made interop with native libraries quite difficult. One cannot take a language seriously for numerical computing if you can’t easily call BLAS, LAPACK and FTTW just to start, and there’s a neverending supply of such efficient native libraries. Julia, on the other hand makes it easy to write efficient code in Julia but also makes it easy to call native libraries written in other languages. Easy interop with numerical libraries was pretty much the first design criterion. There’s also some unfortunate choices Java made like standardizing one specific semantics for reproducible floating point code. That’s unfortunate because adjusting for native SIMD widths sacrifices reproducibility but improves both accuracy and speed. The only choice if you want perfect reproducibility on all hardware that Java supports is the worst performance model with the worst accuracy. There’s also the fact that Java integers are 32-bit and Java arrays are limited to 2GB, which was reasonable when Java was designed, but is pretty limiting for modern numerical computing. I also think that the JVM object model is quite limiting for numerical computing. They still don’t support value types, but value types are precisely what you want to represent efficient numerical values like complex numbers, or quaternions or rationals, and so on. Java forces all user-defined types to be heap-allocated reference types. Julia solves this by defaulting to immutable structures, which is exactly what you want for numerical values: the semantics are still referential (if you can’t mutate you can’t distinguish value semantics from reference semantics), you just can’t change values, which is exactly how you want numbers to behave (you don’t want to be able to change the value of 2). Lack of value types in Java also makes memory management unnecessarily challenging. You can’t make a user-defined type with an efficient C-compatible array layout in Java. Because the objects are references, so the array is an array of pointers to individual heap-allocated objects. The ability to subtype classes forces that, but even with final classes, the ability to mutate objects also forces it, since pulling an object reference out of an array and modifying it is required to modify the object in the array (reference semantics), and that’s incompatible with the inline array layout. And finally, this same lack of value types puts a LOT of pressure on the garbage collector.
  • wging 5y ago
    > I also think that the JVM object model is quite limiting for numerical computing. They still don’t support value types This is mostly true, but the primitives are value types and you can get some things done with them. (Not enough to make Java good for these use cases, no.) I.e. write float[] instead of Float[] and you have a contiguously allocated region of memory that can be efficiently accessed.
• rackjack 5y ago
  one day OCaml will win ;-;
  • dunefox 5y ago
    Not with its Unicode handling.