[oblique63]

> Julia is filling in as a great substitute for scientific coding in a single language stack, and Go / Rust / Haskell for the other stuff.

I've been wondering about why so many python devs have migrated to using Go recently instead of Julia, given that Julia is a lot closer to python and has performed as good as, if not better than, Go in some benchmarks [1]. Granted I've really only toyed with Julia and Go a few times as I've never really needed the performance much myself, but I'm curious about your preference of Go/Rust over Julia for "the other stuff".

What would you say makes Julia less suitable (or Go more suitable) for nonscientific applications? Is it just the community/support aspect? Cause that seems like an easy tide to overturn by simply raising more awareness about it (we see Go/Rust/Haskell blog posts on the front page of HN every week, but not too many Julia posts).

Just curious cause I'm not nearly experienced enough with any of these young languages yet to know any better, and have only recently started to consider taking at least one of them up more seriously.

[1] http://julialang.org/benchmarks/

[vertex-four]

The sorts of Python developers who have migrated to Go are not the sorts of Python developers who use it for scientific purposes. Julia is rather targeted towards the scientific crowd in its marketing[0], so it's likely not even on most Python developers' radars. Marketing means a lot.

[0] http://julialang.org/

[Osmium]

You can write Julia code in an IPython notebook, which is great. And (as I recently learnt) there's a PyCall package to easily call Python functions from within Julia, so you can take advantage of Python packages too.

I'm yet to try Go, but Julia is great for me: it's like all the good parts of Python + extra speed. You get the interactivity, the good documentation, the community, the packages, and all bundled into something that's easy to use and gives you code that runs many times faster than native Python with no real extra effort.

[wting]

Static typing is a boon when refactoring large codebases, even with >90% test coverage.

I'm migrating an in house ORM to SQLAlchemy. Lack of compiler support and/or static code analysis makes the transition more difficult than it needs to be.

Dynamic typing allows one to defer error handling to the future, essentially creating technical debt for the sake of developer speed and convenience. For many use cases this is an acceptable trade off.

However as a codebase grows in complexity, it's better to handle errors as early as possible since the cost of fixing an error grows exponentially the farther it is from the developer (costs in ascending order: editor < compiler < testing < code review < production).

[igouy]

Tools matter:

A very large Smalltalk application was developed at Cargill to support the operation of grain elevators and the associated commodity trading activities. The Smalltalk client application has 385 windows and over 5,000 classes. About 2,000 classes in this application interacted with an early (circa 1993) data access framework. The framework dynamically performed a mapping of object attributes to data table columns.

Analysis showed that although dynamic look up consumed 40% of the client execution time, it was unnecessary.

A new data layer interface was developed that required the business class to provide the object attribute to column mapping in an explicitly coded method. Testing showed that this interface was orders of magnitude faster. The issue was how to change the 2,100 business class users of the data layer.

A large application under development cannot freeze code while a transformation of an interface is constructed and tested. We had to construct and test the transformations in a parallel branch of the code repository from the main development stream. When the transformation was fully tested, then it was applied to the main code stream in a single operation.

Less than 35 bugs were found in the 17,100 changes. All of the bugs were quickly resolved in a three-week period.

If the changes were done manually we estimate that it would have taken 8,500 hours, compared with 235 hours to develop the transformation rules.

The task was completed in 3% of the expected time by using Rewrite Rules. This is an improvement by a factor of 36.

from “Transformation of an application data layer” Will Loew-Blosser OOPSLA 2002

http://portal.acm.org/citation.cfm?id=604258

[cnbuff410]

As a Pythoner previously I have big interest in learning Julia and it indeed looks nice. But based on some small project I tried, it didn't show a significantly improved performance vs. Python. On the other hand, it doesn't have all the Python eco-system which is super nice for anybody who don't want to reinvent the wheel. Therefore, I don't have strong motivation to switch from Python to it for algorithm/learning related task.

Moreover, the benchmark you listed here are still mostly scientific computation related. Just from the benchmark, I'm not convinced enough that Julia beat Go from the perspective of a backend system, which is what I primarily use Go for.

Go and Julia really serves totally different purpose. Go want to replace Python in backend and the Python ecosystem matters little here. Julia want to replace Python in scientific computing and Python ecosystem matters a LOT here.

[pygy_]

> As a Pythoner previously I have big interest in learning Julia and it indeed looks nice. But based on some small project I tried, it didn't show a significantly improved performance vs. Python.

Are you sure you were using the language properly?

Some constructs are still slow, and others prevent type inference, which can also slow things down...

[awda]

Just a few guesses:

    - It doesn't have Google / Thompson / Rsc / etc behind it
    - It looks more like Ruby than C (say what you will about C-like syntax, but I
      think the success of Java and C++ has proved that point)

But you're right, I ought to look into it.

[film42]

I can't find the source, but I recall Rob Pike talking about how the Go language and syntax are designed to "scale". Naturally, Mr. Pike would opt for a C style syntax, but with tools like go fmt and the package manager built in to the tooling from day 1, he kind of has a point.

[coolsunglasses]

I'd rather expand the numerics support/coverage in Haskell, get a nice and easy-breezy type system, nicer refactoring/static analysis, and a more powerful language.