My favorite things that are coming with Julia 1.0

So Julia is typed ( I think) but it's not a mistake in any way to have null in a dynamic language by this argument.

Null is a thing and if you don't have it you reinvent it, it's the typesystem breaking that's the problem, maybe monads effectively have nulls it's just that they then get protected by the typesystem.

Javascript is even better as it has 3 (null, undefined and NaN, and while NaN is available in most every language it is pretty common in JS as its conversion APIs tend to return NaN instead of error).

From Swift for Tensorflow doc:

Julia is another great language with an open and active community. They are currently investing in machine learning techniques, and even have good interoperability with Python APIs. The Julia community shares many common values as with our project, which they published in a very like-minded blog post after our project was well underway. We are not experts in Julia, but since its compilation approach is based on type specialization, it may have enough of a representation and infrastructure to host the Graph Program Extraction techniques we rely on.

I think the sort of pacakges showcased here is a good indication of the sorts of niches julia is worming its way into.

[0] https://discourse.julialang.org/t/what-package-s-are-state-o...

What killed me with Go was lack of generics (a lot of copied code to implement exactly the same integration approach for real and complex functions; different accuracies, etc.); clumsy way to express formulas (no operator overloading to provide a clean syntax for matrix operations) was a pain as well.

I have seen many times that the use cases of scientific computing would benefit from the functional programming paradigms, efficiency with basic math operations and ability to define operations that match standard scientific notation (matrix algebra, convolutions, etc.), but there are few languages that do well in all of those.

For anything else that requires long-term maintainability and has a business or someone's job depending on it, Julia is a risky choice to make. Few, if any, large organizations have done so yet, and usually don't want to go first.

Well after 1.0, if Julia Computing (who employ almost all of the core developers) is on sustainable financial footing and any large organizations have made investments into adopting and supporting Julia, it might make some sense for non-academic use cases.

It like the getfield overloading and a few other things really deserve a post of their own, so I wasn't going to try and push them into this one.

https://medium.com/@sdanisch/compiling-julia-binaries-ddd6d4... -> notice that's a third party package.

That said, once you're up and running, plots (and everything else) are super snappy. When I'm doing plotting stuff, I'm usually doing it interactively, and when I'm scripting it, it's because I'm plotting hundreds or thousands of things (and then the startup time is vanishingly small).

But maybe I'm wrong here. It seems that "use the right tool" turns into use Python or JS or Excel for all the things.

Python had a long history of web server development. I think, aiohttp may be considered state of the art now. Let's measure its performance:

    from aiohttp import web
    
    async def handle(request):    
        return web.Response(text="Hello")
    
    app = web.Application()
    app.add_routes([web.get('/', handle),])
    
    web.run_app(app)

    $ wrk -t1 -c1000 -d30s http://127.0.0.1:8080/
    Running 30s test @ http://127.0.0.1:8080/
      1 threads and 1000 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency   164.59ms   17.12ms 537.35ms   83.97%
        Req/Sec     6.05k     0.95k    7.74k    74.33%
      180749 requests in 30.08s, 26.72MB read
    Requests/sec:   6008.75
    Transfer/sec:      0.89MB

Now let's measure Julia's HTTP.jl server:

    using HTTP

    HTTP.listen() do request::HTTP.Request
       return HTTP.Response("Hello")
    end

    $ wrk -t1 -c1000 -d30s http://127.0.0.1:8081/
    Running 30s test @ http://127.0.0.1:8081/
      1 threads and 1000 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency   105.95ms  108.35ms   1.99s    98.40%
        Req/Sec     9.65k     1.69k   13.66k    80.21%
      271917 requests in 30.09s, 16.10MB read
      Socket errors: connect 0, read 0, write 0, timeout 274
    Requests/sec:   9035.73
    Transfer/sec:    547.67KB

This doesn't include any routing, input data parsing, header or cookie processing, etc., but it amazes me how good the server is given that web development is NOT considered a strong part of the language.

The downside of Julia web programming is the number of libraries and tools (e.g. routers, DB connectors, template engines, etc.) - they exist, but are quite behind Python equivalents, so gotchas are expected. Yet I'm quite positive about future of web programming in Julia.

That said, my personal favourite thing about julia is not actually its speed but the fact that it's an incredibly expressive, flexible and composable language (I'd say julia learned all the mot important lessons lisp had to teach). If I had to guess, I'd think that building the infrastructure for devs to work on web servers from the ground up may very well be easier in julia than in most other langauges, including python. I may be off the mark though.

One other note since it was mentioned elsewhere, there actually is work being done right now to have julia compile to WebAssembly code which could be pretty cool!

However, it was pretty actively discouraged. I suspect they didn't want a lot of voices influencing the direction of the language while it was still being formed. A lot of what make R a poor general purpose language help make it effective in its specific domain for its specific users.

It might be worth people taking another look at it after 1.0 is released, as long as they have low expectations about influencing the direction of the language's development.

What is the specific context for this? Serving concurrent users? Or raw processing?

If it's the former, there are ways around this. If you'd like to replace Python for this, I'd look at something like Go rather than Julia.

If it's the latter, Julia might help, but there are a bunch of tradeoffs to consider. Julia is a language that was primarily designed for numerical computation.

I used to call Fortran code from Python for a particularly complex function (Mittag-Leffler function) from Python, I then rewrote everything in Julia and it runs approx 10-20x faster. So there you go, I'm a primary source.

Edit: just for clarity: The Mittag-Leffler function itself runs just ever so slightly faster in Julia than Fortran-called-from-Python (due to the probably inefficient way I was sending and receiving the data to/from a Python subprocess, which itself is an example of the difficulty of combining two languages). It is the program as a whole which runs 10-20x faster.

The 10% figure comes from a comparison of the performance of the codes whose logic has been left virtually unchanged, of course.

What is awesome is the ability to run codes within Jupyter (like Python), and the ability to run "for" loops on large arrays fast and with little memory consumption (unlike Python). The 10% increase in computational time is fully absorbed by the reduced development/validation time!

About the second quote: this is not about Julia being slower than Python; it's about avoiding cache misses. Obviously you should exploit contiguity of the data in memory. Secondly, the 'decorators' like "@inbounds" just ensure that Julia does not redundantly checks bounds, otherwise the inner loop has branches and cannot exploit SIMD.

[1] https://tk3369.wordpress.com/2018/02/04/an-updated-analysis-...

What matters to me is that it is actually really nice to write. The syntax is elegant, the community is excellent, and the core of the language's semantics being multiple dispatch is a game changer.

I think that the ML community's decision to write core operations in C or C++ and provide Python wrappers is the way to go about it if you want the flexibility of scripting.

This is not necessarily a bad thing. Just an observation from me translating my Python code to Julia.

Thats a deceptive and unhelpful 'benchmark', especially when the C++ compilation time was not included in its benchmark. Julia compilation and statup times are slow if you are expecting the feel of the Python interpreter, however, julia's compilation and statup time add a finite, constant overhead to its preformance and so are completely irrelevant for high performance numrical computing.

If you were wanting to spawn many julia instances and make them execute a single command then exit, yes julia would be a terrible choice of that (unless you turn of compilation and use its interpreter or statically compile your program) but for the most part measuring startup time just isn't relevant unless it takes a minute or something absurd.

In julia the only libraries I know of that take a minute to load are plotting libraries (once you make your first plot the library is blazing fast again) and thats been considered such a big issue that a new plotting library Makie is well under way which is supposed to be fully statically compiled in julia in order to slash the first time to plot.

exp.(v.^2) .+ (10 .* u)

can be written as

@. exp(v^2) + (10 * u)

with no added runtime cost.

Edit: To add, Julia is now my go-to language for any scientific/numeric programming and would be my number 1 suggestion to anyone else doing similar work.

Unfortunately, it doesn't take much negative energy to spoil a community, even if it comes from just one person. That it was a language co-creator is troubling but not necessarily a reason to avoid the language if the rest of the community is nice (which maybe it is, maybe it isn't).

However one thing I have noticed is that most language communities do tend to follow an attitude set by the language creator(s). This seems to have played out quite a bit for Clojure, Python, Elm, Elixir, and other languages where, at least to me, the overall shared perspective of the community is closely aligned to the personal attitudes and opinions of the language author(s).