11 ms·

Java has a massive ecosystem yet we continue to see rapid replacement of backends in JavaScript (Node now Deno) and Golang. Each of those language ecosystems ra

by xbpx 5y ago

Java has a massive ecosystem yet we continue to see rapid replacement of backends in JavaScript (Node now Deno) and Golang. Each of those language ecosystems rapidly became both large (arguably too large) and robust. Rust has been eating C++ lunch. Same rapid rise of ecosystem story. Instead of forcing Python to be a language it isn't it might be more efficient and ultimately the "right choice" to invest the time in Julia. Julia is great for numerical computing, it needs faster time to plot and more hands in the ecosystem. The former will be solved and the latter seems inevitable to me. Pitch in!

zz865 5y ago
Wow I hadn't seen deno before, looks great. I dont like js/ts, but if you have to learn it for front end dev, it makes sense to use it at the back too. I'm not sure what advantage Julia has over Python. Yeah it has some typing and can be faster, but its too similar. Still single threaded.
- adgjlsfhk1 5y ago
  this is just false. Julia has partir based threading (like go).
- ur-whale 5y ago
  > I'm not sure what advantage Julia While I'm really not a fan of 1-based indexing, Julia's multiple dispatch is not something easy to match in Python. [EDIT]: one thing that's still not solved in Julia is code startup time. Many people will sell you some sort of workflow that works around the problem, but it's the same old tired arguments people would use to defend traditional compiled languages, and I'm not buying. I really wish they would find a way to truly solve this.
  - Mikeb85 5y ago
    > [EDIT]: one thing that's still not solved in Julia is code startup time. > Many people will sell you some sort of workflow that works around the problem, but it's the same old tired arguments people would use to defend traditional compiled languages, and I'm not buying. I mean, Julia has a REPL so you can basically edit code as the process runs, which definitely makes startup time less of an issue. The fact Julia can produce such fast code is also pretty nice. Starting a new process every time you want to run a snippet of code isn't getting the best out of a dynamic language...
  - fault1 5y ago
    I would say the almost every version of Julia 1.x has better in terms of code startup. as in 1.7 > 1.6 > 1.5 > 1.4 > 1.3 > etc... it's especially goten way better since julia 1.5, so really mostly in the last few years. In julia 1.8, what's interesting to me is that the julia runtime will be separated from the llvm codegen; https://github.com/JuliaLang/julia/pull/41936 https://github.com/JuliaLang/julia/pull/41936 the immediate effect is to allow small static binaries without a huge runtime (namely the LLVM ORC), but the side effect is probably that the interpreter will also get better in cases where you don't want JIT.
- hpcjoe 5y ago
  Most definitely not single threaded. From one of my codes # Threaded inner loop, each thread has no dependence upon others Threads.@threads for t=1:Nthr inner_gen_cpu1!(psum,ms,me,cls,2) end That's all you need. You don't need pthread create/join, you don't need installable language extensions, you don't need to appeal to external tools/libraries to enable threading. Its built in to Julia. And it is trivial to use.
  - bjourne 5y ago
    But is it real kernel threading or the same kind of cooperative threading that Python also supports?
    - elcritch 5y ago
      It's real kernel threads. Julia also supports cluster computing too.
      - bjourne 5y ago
        According to this discussion thread, Julia requires the number of kernel threads to be specified at startup: https://discourse.julialang.org/t/does-multithreading-require-a-new-process/45056/3 https://discourse.julialang.org/t/does-multithreading-requir... This seem to be more like pyprocessing and much more limited than the pthreads interface.
        ddragon 5y ago
        I didn't go deep on Julia's multithreading, but what he is saying is that Julia uses an MxN threading (I think nowadays if you don't specify it at startup it will just use one for each cpu thread), which is the same as a language I did most of distributed programming (elixir/erlang), and as far as I know it's the same as Go. Having 1 kernel thread for each CPU thread means that your program can use all available CPU threads at the same time (so you get all the parallelism available within the machine), and having a language based scheduler for each thread means you can have minimal overhead (no need to do a system call) to create a new concurrent execution (meaning lightweight/green threading similar to what python allows, except being automatically distributed by the language within all kernel/cpu threads). In Elixir this means you can create millions of processes even though the OS will only see one thread per logical cpu thread, and I never felt the limitation of this abstraction over multiprocessing (of course, Julia is definitely nowhere near as mature - and maybe never will due to stuff like preemptive scheduling and parallel garbage collection that is easier to implement in a language with only immutable types, though it seems to be moving along, and in Julia 1.7 the processes being able to move between kernel threads solving the issue mentioned in that discussion you linked).
- huitzitziltzin 5y ago
  https://docs.julialang.org/en/v1/manual/multi-threading/ https://docs.julialang.org/en/v1/manual/multi-threading/
- RemoteControlr 5y ago
  As has been pointed out, Julia is not limited to a single thread. It's actually got a pretty good support for parallelism both at the thread and process level. And no, Julia is not too similar to Python. Julia has multiple dispatch, Python does not.
  - xbpx 5y ago
    Another point that is often lost is how mathematical Julia code can look, especially for matrix functions. Yeh this is superficial, but so are 200 dollar sneakers and they do just fine. Honestly there is a real pleasure writing code that looks like it could be on the blackboard. The numpy / numba world in Python just feels... not great.
    - Tarq0n 5y ago
      I actually consider that a negative. Mathematical notation is fine when you're dealing with limited space on a blackboard, but if you're programming please name your name variables and take the time to model your domain explicitly.
      - chaxor 5y ago
        I don't understand - what is wrong with condensing the python representation `sum_of_lambda_for_each_psi` to `Σλ∀φ`? It seems that 4 symbols is much quicker and easier to read than a slew of snake case stuff.
        TheRealKing 5y ago
        So, one-letter English labels were deemed bad coding-style for decades, but suddenly one-letter Greek labels are good because some X-language (Julia) supports it. Seriously? How about single-letter Chinese labels? because that is my background and that is what I am comfortable using.
        fault1 5y ago
- Mikeb85 5y ago
  Julia is much, much faster than Python. For numeric code it's almost as fast as C++. They've used lots of cool tricks to become crazy fast on numeric workloads. It's also definitely got support for multithreading, clusters, etc...
  - longqzh 5y ago
    For numeric code, comparing to pure python makes no sense, since people use numpy+numba to do that. Is julia much much faster than numba? I don't think so :)
    - dnautics 5y ago
      yeah, then you try to use numba + scipy and then sure many things work but you're never too far away from a tableflip and wanting to curse your fucking life out.
    - jolux 5y ago
      Probably not faster in an absolute sense but things like loops in Julia can be properly optimized and will sometimes be more readable than structuring your program entirely around NumPy constructs.
      - longqzh 5y ago
        For numpy, it's correct. But numba can optimize the loop. So optimized and readable loop is not an advantage of julia compare to numba.
        ChrisRackauckas 5y ago
        Not in real-world contexts. This is spelled out in Julia for Biologists (https://arxiv.org/abs/2109.09973 https://arxiv.org/abs/2109.09973) which does the operation counting to show why using Numba with SciPy is still an order of magnitude slower in scientific operations like solving differential equations compared to Julia. An order of magnitude on widely used scientific analyses is pretty significant!
- edgyquant 5y ago
  I do like JS quite a bit, I was a hater until a few years ago when I had to start working with it more than a snippet here and there, but I still prefer python on the backend. I think JS makes a lot of sense for frontend with the way everything is async.
  - mrtweetyhack 5y ago
    But if you can use just one why bother learning two?
KptMarchewa 5y ago
>rapid replacement of backends in JavaScript Really? I thought that was a ~2017 thing.
- xbpx 5y ago
  Ha it's still going strong. Now bifurcated between node+next and the rise of Deno. It won't stop either because the road between between JS client dev and JS server dev is so smooth. Path of least resistance type thing.
  - nicoburns 5y ago
    It’s not really bifurcated. Hardly anyone is using demo.
    - searchableguy 5y ago
      I think Slack is using deno now. https://api.slack.com/future/tools/cli https://api.slack.com/future/tools/cli
  - oefrha 5y ago
    One has to be in a pretty tiny bubble to believe there’s rapid replacement of Java backends with Deno, of all things.
    - sigzero 5y ago
      That was my first thought in reading the "JavaScript backend" thing.
jstx1 5y ago
I don't know, x being a potential replacement for y doesn't say all that much. You could have been writing Java or C++ for the past 25 years and got loads of stuff done, solved problems, shipped software, made money etc. Languages are fun to think about but you don't always need to be concerned with every vocal minority of programmers that like to talk about how their language is better than yours. Sometimes that replacement is better and sometimes those people are wrong. But even when they're right, being marginally better isn't that big of deal, or nearly enough to make for a viable rewrite or change of language.
- xbpx 5y ago
  I wholeheartedly agree. X instead of reasonably-similar-Y isn't convincing in and of itself. I'm not even convinced Julia will be the dominant numerical programming language. That said I'd like it if it develops a robust and large ecosystem because I personally like coding in it. It has built-in matrix ops, parallel ops, dynamic dispatch etc that are really nice to work with in the numerical space. Like Matlab but well rounded and fast. So I admit my comment is less argument and more cheerleading. "Hey folks let's make this the case so us numerical people can have a slightly improved experience". In the grand scheme of things this is as noble or ignoble as any.
  - chaxor 5y ago
    ** like Matlab - but free and open source ** Perhaps an important aspect that allows it to be relevant
  - punnerud 5y ago
    I think Python is used by a lot of people now because elementary schools and universities teaching it, easy to start with and you can gradually convert to more advanced (compact) language, you can prototype easily without having to remember a lot of syntax, and you come a long way without an IDE (+ Jupyter Notebook is great). I love that Torch is converted to Python. I think it’s more importantly with a large ecosystem than the most efficient language.
- xvilka 5y ago
RemoteControlr 5y ago
> it needs faster time to plot Time to plot is much improved in 1.6 and should continue to improve in 1.7. It's definitely being addressed.
6gvONxR4sf7o 5y ago
Python’s strength isn’t being the best at anything. Its strength is being top 2/5/whatever in a ton of things. Moving to julia for this just trades some pain points for others.
- driscoll42 5y ago
  100% this. I love that in python I can handle most all problems reasonably well. I don't need perfect, I need a good, versatile language that I know how to code. Even if Julia is better in some things, the switching cost of learning the language, libraries, nuances, the massively fewer online resources, just is not there.
  - fault1 5y ago
    I've been using C++ and Python since the early 2000s. Julia these days is my go to free time language to hack together stuff in, partially because I've been impressed with what comes out of that ecosystem despite the smaller community. I think this is at least a testament with how composable things are relative to C++ or python. I love many things about Julia, but there are definitely growing pains for the language and I can see why it may be a hard sale to people used to modern python or C++, both of which have improved since Julia came out. However, Julia has it's own goals that might make certain communities veer towards it. It'll be interesting to see if it gets more adoption in industry.
    - chaxor 5y ago
      The way I see Julia now is how I saw python ~12 years ago
      - tfehring 5y ago
        I agree, but it's probably closer to 20 years IMO, which makes sense given that Python has been around for 21 years longer. By 2009 Python was already in widespread use at Google/YouTube and (I think) Mozilla, plus startups like Reddit and Dropbox. Hell, Steve Huffman wrote "Lots of people have written web applications in Python, and there's plenty of code from which to learn" as one justification for Reddit's Python rewrite in 2005 [0]. No one is saying that about Julia today, it's seeing very little use in the private sector at this point. [0] http://web.archive.org/web/20051230163903/http://reddit.com/blog/2005/12/on-lisp.html http://web.archive.org/web/20051230163903/http://reddit.com/...
deleted 5y ago
[deleted]
de6u99er 5y ago
I think Python is great for exploration and method development, while I would prefer something more efficient like Julia for production systems. On the other hand, Julia requires compilation while Python allows open-heart surgery on the production system (for the masochists among us). I personally don't like Python that much because every library does things differently and sometimes it feels like learning a completely new (sub) language. E.g. NumPy DataFrames allow to do the same thing in multiple ways (e.g. adding an index column, or removing a column). Often when I need to look up how to do a particular thing I end up finding many solutions that simply don't function with the version I am working with. Sometimes looking even into old code of mine doesn't work any more and requires either me using an older library of relearning how to do things. That being said, a friend of mine has been quite fond of Julia lately. Which put Julia on the top of my list of programming languages to do a deep dive.
- longemen3000 5y ago
  Just to be clear Julia is "AOT-JIT", that means that the methods are compiled when used the first time. With Revise.jl (a package for interactive development) you can make a fully interactive Julia process, rewriting things on the fly, while benefiting from fast code
  - freemint 5y ago
    Running Revise in production sounds unwise (sorry for the pun). Also you can very much not redefine functions on the fly due to world age (assuming the caller doesn't pay for invoke-latest).
    - ChrisRackauckas 5y ago
      You're not doing interactive development on production. Production is the case where you just build a system image and deploy it without compile times. This is done all of the time, for example with Pumas.
      - freemint 5y ago
sivakon 5y ago
Clojure has a high performance data frame library that leverages new JVM vector API and high quality apache arrow protocol. Talk related - https://youtu.be/5mUGu4RlwKE https://youtu.be/5mUGu4RlwKE https://github.com/zero-one-group/geni-performance-benchmark https://github.com/zero-one-group/geni-performance-benchmark
pjmlp 5y ago
> Java has a massive ecosystem yet we continue to see rapid replacement of backends in JavaScript (Node now Deno) and Golang. I guess in some startup scene, it has been Java and .NET over here and no signs of changing, despite the occasional junior projects that eventually get rewritten back into Java/.NET stacks when they move on.

by xbpx 5y ago

zz865 5y ago

Wow I hadn't seen deno before, looks great. I dont like js/ts, but if you have to learn it for front end dev, it makes sense to use it at the back too. I'm not sure what advantage Julia has over Python. Yeah it has some typing and can be faster, but its too similar. Still single threaded.

adgjlsfhk1 5y ago
this is just false. Julia has partir based threading (like go).
ur-whale 5y ago
> I'm not sure what advantage Julia While I'm really not a fan of 1-based indexing, Julia's multiple dispatch is not something easy to match in Python. [EDIT]: one thing that's still not solved in Julia is code startup time. Many people will sell you some sort of workflow that works around the problem, but it's the same old tired arguments people would use to defend traditional compiled languages, and I'm not buying. I really wish they would find a way to truly solve this.
- Mikeb85 5y ago
  > [EDIT]: one thing that's still not solved in Julia is code startup time. > Many people will sell you some sort of workflow that works around the problem, but it's the same old tired arguments people would use to defend traditional compiled languages, and I'm not buying. I mean, Julia has a REPL so you can basically edit code as the process runs, which definitely makes startup time less of an issue. The fact Julia can produce such fast code is also pretty nice. Starting a new process every time you want to run a snippet of code isn't getting the best out of a dynamic language...
- fault1 5y ago
  I would say the almost every version of Julia 1.x has better in terms of code startup. as in 1.7 > 1.6 > 1.5 > 1.4 > 1.3 > etc... it's especially goten way better since julia 1.5, so really mostly in the last few years. In julia 1.8, what's interesting to me is that the julia runtime will be separated from the llvm codegen; https://github.com/JuliaLang/julia/pull/41936 https://github.com/JuliaLang/julia/pull/41936 the immediate effect is to allow small static binaries without a huge runtime (namely the LLVM ORC), but the side effect is probably that the interpreter will also get better in cases where you don't want JIT.
hpcjoe 5y ago
Most definitely not single threaded. From one of my codes # Threaded inner loop, each thread has no dependence upon others Threads.@threads for t=1:Nthr inner_gen_cpu1!(psum,ms,me,cls,2) end That's all you need. You don't need pthread create/join, you don't need installable language extensions, you don't need to appeal to external tools/libraries to enable threading. Its built in to Julia. And it is trivial to use.
- bjourne 5y ago
  But is it real kernel threading or the same kind of cooperative threading that Python also supports?
  - elcritch 5y ago
    It's real kernel threads. Julia also supports cluster computing too.
    - bjourne 5y ago
      According to this discussion thread, Julia requires the number of kernel threads to be specified at startup: https://discourse.julialang.org/t/does-multithreading-require-a-new-process/45056/3 https://discourse.julialang.org/t/does-multithreading-requir... This seem to be more like pyprocessing and much more limited than the pthreads interface.
      - ddragon 5y ago
        I didn't go deep on Julia's multithreading, but what he is saying is that Julia uses an MxN threading (I think nowadays if you don't specify it at startup it will just use one for each cpu thread), which is the same as a language I did most of distributed programming (elixir/erlang), and as far as I know it's the same as Go. Having 1 kernel thread for each CPU thread means that your program can use all available CPU threads at the same time (so you get all the parallelism available within the machine), and having a language based scheduler for each thread means you can have minimal overhead (no need to do a system call) to create a new concurrent execution (meaning lightweight/green threading similar to what python allows, except being automatically distributed by the language within all kernel/cpu threads). In Elixir this means you can create millions of processes even though the OS will only see one thread per logical cpu thread, and I never felt the limitation of this abstraction over multiprocessing (of course, Julia is definitely nowhere near as mature - and maybe never will due to stuff like preemptive scheduling and parallel garbage collection that is easier to implement in a language with only immutable types, though it seems to be moving along, and in Julia 1.7 the processes being able to move between kernel threads solving the issue mentioned in that discussion you linked).
huitzitziltzin 5y ago
https://docs.julialang.org/en/v1/manual/multi-threading/ https://docs.julialang.org/en/v1/manual/multi-threading/
RemoteControlr 5y ago
As has been pointed out, Julia is not limited to a single thread. It's actually got a pretty good support for parallelism both at the thread and process level. And no, Julia is not too similar to Python. Julia has multiple dispatch, Python does not.
- xbpx 5y ago
  Another point that is often lost is how mathematical Julia code can look, especially for matrix functions. Yeh this is superficial, but so are 200 dollar sneakers and they do just fine. Honestly there is a real pleasure writing code that looks like it could be on the blackboard. The numpy / numba world in Python just feels... not great.
  - Tarq0n 5y ago
    I actually consider that a negative. Mathematical notation is fine when you're dealing with limited space on a blackboard, but if you're programming please name your name variables and take the time to model your domain explicitly.
    - chaxor 5y ago
      I don't understand - what is wrong with condensing the python representation `sum_of_lambda_for_each_psi` to `Σλ∀φ`? It seems that 4 symbols is much quicker and easier to read than a slew of snake case stuff.
      - TheRealKing 5y ago
        So, one-letter English labels were deemed bad coding-style for decades, but suddenly one-letter Greek labels are good because some X-language (Julia) supports it. Seriously? How about single-letter Chinese labels? because that is my background and that is what I am comfortable using.
        fault1 5y ago
Mikeb85 5y ago
Julia is much, much faster than Python. For numeric code it's almost as fast as C++. They've used lots of cool tricks to become crazy fast on numeric workloads. It's also definitely got support for multithreading, clusters, etc...
- longqzh 5y ago
  For numeric code, comparing to pure python makes no sense, since people use numpy+numba to do that. Is julia much much faster than numba? I don't think so :)
  - dnautics 5y ago
    yeah, then you try to use numba + scipy and then sure many things work but you're never too far away from a tableflip and wanting to curse your fucking life out.
  - jolux 5y ago
    Probably not faster in an absolute sense but things like loops in Julia can be properly optimized and will sometimes be more readable than structuring your program entirely around NumPy constructs.
    - longqzh 5y ago
      For numpy, it's correct. But numba can optimize the loop. So optimized and readable loop is not an advantage of julia compare to numba.
      - ChrisRackauckas 5y ago
        Not in real-world contexts. This is spelled out in Julia for Biologists (https://arxiv.org/abs/2109.09973 https://arxiv.org/abs/2109.09973) which does the operation counting to show why using Numba with SciPy is still an order of magnitude slower in scientific operations like solving differential equations compared to Julia. An order of magnitude on widely used scientific analyses is pretty significant!
edgyquant 5y ago
I do like JS quite a bit, I was a hater until a few years ago when I had to start working with it more than a snippet here and there, but I still prefer python on the backend. I think JS makes a lot of sense for frontend with the way everything is async.
- mrtweetyhack 5y ago
  But if you can use just one why bother learning two?

KptMarchewa 5y ago

>rapid replacement of backends in JavaScript Really? I thought that was a ~2017 thing.

xbpx 5y ago
Ha it's still going strong. Now bifurcated between node+next and the rise of Deno. It won't stop either because the road between between JS client dev and JS server dev is so smooth. Path of least resistance type thing.
- nicoburns 5y ago
  It’s not really bifurcated. Hardly anyone is using demo.
  - searchableguy 5y ago
    I think Slack is using deno now. https://api.slack.com/future/tools/cli https://api.slack.com/future/tools/cli
- oefrha 5y ago
  One has to be in a pretty tiny bubble to believe there’s rapid replacement of Java backends with Deno, of all things.
  - sigzero 5y ago
    That was my first thought in reading the "JavaScript backend" thing.

jstx1 5y ago

I don't know, x being a potential replacement for y doesn't say all that much. You could have been writing Java or C++ for the past 25 years and got loads of stuff done, solved problems, shipped software, made money etc. Languages are fun to think about but you don't always need to be concerned with every vocal minority of programmers that like to talk about how their language is better than yours. Sometimes that replacement is better and sometimes those people are wrong. But even when they're right, being marginally better isn't that big of deal, or nearly enough to make for a viable rewrite or change of language.

xbpx 5y ago
I wholeheartedly agree. X instead of reasonably-similar-Y isn't convincing in and of itself. I'm not even convinced Julia will be the dominant numerical programming language. That said I'd like it if it develops a robust and large ecosystem because I personally like coding in it. It has built-in matrix ops, parallel ops, dynamic dispatch etc that are really nice to work with in the numerical space. Like Matlab but well rounded and fast. So I admit my comment is less argument and more cheerleading. "Hey folks let's make this the case so us numerical people can have a slightly improved experience". In the grand scheme of things this is as noble or ignoble as any.
- chaxor 5y ago
  ** like Matlab - but free and open source ** Perhaps an important aspect that allows it to be relevant
- punnerud 5y ago
  I think Python is used by a lot of people now because elementary schools and universities teaching it, easy to start with and you can gradually convert to more advanced (compact) language, you can prototype easily without having to remember a lot of syntax, and you come a long way without an IDE (+ Jupyter Notebook is great). I love that Torch is converted to Python. I think it’s more importantly with a large ecosystem than the most efficient language.
xvilka 5y ago

RemoteControlr 5y ago

> it needs faster time to plot Time to plot is much improved in 1.6 and should continue to improve in 1.7. It's definitely being addressed.

6gvONxR4sf7o 5y ago

Python’s strength isn’t being the best at anything. Its strength is being top 2/5/whatever in a ton of things. Moving to julia for this just trades some pain points for others.

driscoll42 5y ago
100% this. I love that in python I can handle most all problems reasonably well. I don't need perfect, I need a good, versatile language that I know how to code. Even if Julia is better in some things, the switching cost of learning the language, libraries, nuances, the massively fewer online resources, just is not there.
- fault1 5y ago
  I've been using C++ and Python since the early 2000s. Julia these days is my go to free time language to hack together stuff in, partially because I've been impressed with what comes out of that ecosystem despite the smaller community. I think this is at least a testament with how composable things are relative to C++ or python. I love many things about Julia, but there are definitely growing pains for the language and I can see why it may be a hard sale to people used to modern python or C++, both of which have improved since Julia came out. However, Julia has it's own goals that might make certain communities veer towards it. It'll be interesting to see if it gets more adoption in industry.
  - chaxor 5y ago
    The way I see Julia now is how I saw python ~12 years ago
    - tfehring 5y ago
      I agree, but it's probably closer to 20 years IMO, which makes sense given that Python has been around for 21 years longer. By 2009 Python was already in widespread use at Google/YouTube and (I think) Mozilla, plus startups like Reddit and Dropbox. Hell, Steve Huffman wrote "Lots of people have written web applications in Python, and there's plenty of code from which to learn" as one justification for Reddit's Python rewrite in 2005 [0]. No one is saying that about Julia today, it's seeing very little use in the private sector at this point. [0] http://web.archive.org/web/20051230163903/http://reddit.com/blog/2005/12/on-lisp.html http://web.archive.org/web/20051230163903/http://reddit.com/...

deleted 5y ago

[deleted]

de6u99er 5y ago

I think Python is great for exploration and method development, while I would prefer something more efficient like Julia for production systems. On the other hand, Julia requires compilation while Python allows open-heart surgery on the production system (for the masochists among us). I personally don't like Python that much because every library does things differently and sometimes it feels like learning a completely new (sub) language. E.g. NumPy DataFrames allow to do the same thing in multiple ways (e.g. adding an index column, or removing a column). Often when I need to look up how to do a particular thing I end up finding many solutions that simply don't function with the version I am working with. Sometimes looking even into old code of mine doesn't work any more and requires either me using an older library of relearning how to do things. That being said, a friend of mine has been quite fond of Julia lately. Which put Julia on the top of my list of programming languages to do a deep dive.

longemen3000 5y ago
Just to be clear Julia is "AOT-JIT", that means that the methods are compiled when used the first time. With Revise.jl (a package for interactive development) you can make a fully interactive Julia process, rewriting things on the fly, while benefiting from fast code
- freemint 5y ago
  Running Revise in production sounds unwise (sorry for the pun). Also you can very much not redefine functions on the fly due to world age (assuming the caller doesn't pay for invoke-latest).
  - ChrisRackauckas 5y ago
    You're not doing interactive development on production. Production is the case where you just build a system image and deploy it without compile times. This is done all of the time, for example with Pumas.
    - freemint 5y ago

sivakon 5y ago

Clojure has a high performance data frame library that leverages new JVM vector API and high quality apache arrow protocol. Talk related - https://youtu.be/5mUGu4RlwKE https://youtu.be/5mUGu4RlwKE https://github.com/zero-one-group/geni-performance-benchmark https://github.com/zero-one-group/geni-performance-benchmark

pjmlp 5y ago

> Java has a massive ecosystem yet we continue to see rapid replacement of backends in JavaScript (Node now Deno) and Golang. I guess in some startup scene, it has been Java and .NET over here and no signs of changing, despite the occasional junior projects that eventually get rewritten back into Java/.NET stacks when they move on.