Julia is probably the next best bet, according to the Swift for Tensorflow team - https://github.com/tensorflow/swift/blob/master/docs/WhySwif...

This is exactly what I thought as well. Julia is born for this use case.

Except for the 1-indexing part.

Been wanting to try Julia out for a while, but the 1-based indexing is perennially putting me off. I can't see how I can avoid spending a large chunk of time (and endless frustration) unlearning years of 0-index muscle memory (nor I see why should I, for the sake of adapting to a single language that, at least initially, I will be just toying with).

It was probably a good marketing move on their part, a wink towards the Fortran/Matlab crowd, but it certainly damages the language's appeal for potential converts from C, C++ and Python.

It's not that bad in practice. I wrote Matlab for 12-years and Python for 15-years and seamlessly switch between 0 and 1 indexing.

I know the arguments for 0 vs 1 indexing, but in practice it's not really an issue since they're both just book-keeping. The only time where things might get interesting is for certain complex recursive expressions (recursive in the mathematical sense) where you want your code to match the equations, but in those cases I just create a new offset-index and work off that. (edit: just learned from another comment that Julia supports custom indices.)

Note: caveat -- my use of indices is mathematical. I don't do any kind of low-level stuff.

Then challenge yourself to write some code completely agnostic to the indexing, which will force you to learn some neat features. Doing pointer arithmetic with your bare hands (however much muscle memory they have) is very seldom necessary, computers are pretty good at that stuff.

I thought one of Julia's compelling features is the ability drop down to the level of index arithmetics without losing performance (as Python does, once you start writing manual for loops).

If I want to stick with higher-level construct for dealing with "collections of numbers", I can use numpy arrays in Python, the STL in C++, etc.

Do you think Julia's high-level constructs are much better than the competition? E.g., how do they compare with C++20 ranges?

Maybe I phrased that poorly: you can indeed write the loops yourself (without a speed penalty) as advertised, to do things which are hard/ugly/impossible in numpy. But very often you can do this without dropping all the way down to explicit pointer arithmetic, where you'd have to care about base-0/1 and off-by-one errors (again without penalty). This in-between zone is what I was trying to suggest is worth exploring. See for example https://julialang.org/blog/2016/02/iteration for a taste.

Someone more polyglot than I am will have to comment on C++ comparisons.

You can do some pretty interesting things with indexing in Julia: https://julialang.org/blog/2016/02/iteration

I mean, how much time are we really talking about here?

LoL. It's 2019. There's no reason why start index should be fixed... Treat arrays as optimised hashmaps, and let users pick a default!

Edit: ah, a sibling comment (now deleted) mentions Julia does have some support for arbitrary indices ("offset arrays").

https://docs.julialang.org/en/v1/devdocs/offset-arrays/

sigh: this doesn't matter, this is a library provided feature not a language feature (like Ada) so if you try to use something else than 1-based array you'll find lots of incompatible libraries..

I didn't use offset arrays, but I don't expect lots of incompatible libraries if they implemented the proper array interfaces. Julia has duck typing, and thanks to multiple dispatch they can just specialize the few relevant methods that actually use the new type special properties.

Many of the most used Julia types are defined outside of the standard library, such as StaticArrays (for fixed size arrays) and CUArray (for GPU processing).

You can use any indexing scheme you like now.

Arrays can start at [-100] if you feel like it.

https://docs.julialang.org/en/v1/devdocs/offset-arrays/

It is not typesave and doesn’t really support programming in the large. I think the best bet is something like Swift or Microsoft could come out with a C#/F# compatible thing.

I was curious about Julia, mostly to experiment with the Flux machine learning library. I tried some ‘general purpose’ Julia programming: network IO, consuming RDF data, some natural language processing/text processing, etc.

I was specifically interested in the question ‘could Julia be my general purpose language?’. In reality, I am too much into Lisp languages, Haskell, etc. to seriously want a new language, so this was just a two evening experiment.

> In reality, I am too much into Lisp languages, Haskell, etc. to seriously want a new language, so this was just a two evening experiment.

But what did you think of Julia?

Julia is a very nice language. Still, I would not use it for a large project with many developers: similar situation as Python.

Julia is typesafe as both of c# / swift. Supporting programming in large has no meaning at all.

That is factually incorrect: It offers no static compilation guarantees at all. All it has is some form of duck typing, much like python, there were some discussions on this with Haskell people on the issue tracker that objected to the claim that Julia is dependently typed, when in fact it isn't. Programming in the large has a precise meaning. It is what Programming languages like Rust, OCaml, C#, Java, Swift, Go, Ada were designed for: Languages that facilitate many engineers (100s-1000s) to work on a common project, that requires static types, a sane package or module system and the possibility to separate implementation and interface (go interfaces, swift protocols etc.). None of these features really exist in Julia (in particular no static type system)

I always think these discussions miss the fact that static type systems only give you these benefits if whatever property you're trying to prove is encoded in your type system. E.g. people keep telling me that static type systems will prevent shape mismatch errors at runtime, but then go ahead and give their variables a static type of "Tensor" (without shape information), because encoding that shape information in the static type system is a bit of a pain and nobody really wants to write that (Not always, but it's a surprisingly common pattern).

Meanwhile, we have absolutely no problem statically checking Julia code (and in fact we do when generating code for TPU). It's a bit of a non-standard thing to do and we're working on improving the tooling for this, but putting Julia on the same level as python here ignores a significant aspect of the design of Julia.

As for collaborations among thousands of engineers, it is true that we don't really have Julia projects that large yet (other than Julia itself) and I'm sure we'll undoubtedly find things to improve in the language to support collaboration at that scale, but i really would encourage you to look at things like the new package manager or the documentation system. A significant amount of work has gone into the usability thereof and I think at that point they warrant criticism more detailed than an off hand dismissal.

Yes, it always annoys how much C++ code is "integer typed"..

Julia was created for and by the scientific computing/data scientists folk. It's a very valuable endeavor, I am glad we have another programming language/tool for this field.

What I don't quite get it's the silly insistence of the Julia fanboys to claim Julia is a general programming language, and that as such it should be used for everything. There is nothing wrong with being a focused and discipline specific programming language.

Why is it a silly insistence? What about it is not fit for general programming? Please be specific.

I get that for scientific/numeric applications Julia is probably at a sweet spot and equally well suited if not better suited than many of its competitors (in many ways it feels like Matlab on steroids). Clearly the stuff you're doing with XLA.jl and the ease of implementation of Neural Differential Equations demonstrate the power of Julia's approach to deep learning.

As you probably know it is hard (and in a precise sense actually theoretically impossible) to design type systems that are both convenient to use (have automatic type inference) and incorporate dependent types (such as shapes of tensors). Julia's solution of using multiple dispatch is not a substitute for such a static type system.

Running into an exception, if there is no method for the particular combination of parameter types you have accidentally produced in a 1000 LOC project might be fine, it will make it pretty hard to refactor anything in a larger project. It results in exactly the same challenges that large python / javascript projects have. Those challenges are well documented and are the reason why large companies move away from those languages to statically typed languages.

This is why I believe a statically typed language with good support for numerical computing will eventually win as the language of choice for large production machine learning applications. Leaving (for now) exotic examples such as Neural Differential Equations aside, current machine learning models would probably actually profit more from some of the type safety features let's say Swift has (using structs for example instead of Tensors of certain shapes) than from more comprehensive support of numerical features. For the most part we are talking about very basic linear algebra after all.

The Swift for Tensorflow design documents argue this pretty convincingly as well.

Regarding the package and module system you might be right, but looking at https://github.com/JuliaTPU/XLA.jl/blob/master/src/XLA.jl and comparing this to how you would assemble a user facing module in lets say OCaml https://github.com/janestreet/core/blob/master/src/core_unix... I personally feel like the later gives me a lot more information how I would use the module and a clear separation from the implementation at the same time, similar things can be said about how this would look like in Swift or even a well written C/C++ header. As far as I can tell package management is still roughly at the level of pip in sophistication, not comparable to solutions like cargo or opam.

It's possible to have both the dynamism and static type checking in Julia. Check out this issue: https://github.com/FluxML/Flux.jl/issues/614

exactly this. The module infrastructure of Julia is designed purposefully to be like R which is great for data exploration and statisticians. However, its a horrible architecture for building modular large scale software.

How so, outside of just being a dynamic language? In fact it's probably in the higher end of dynamic languages since the type inference can help tools detect method errors and type instability that cost performance. Multiple Dispatch allows for really good high level abstractions, and the language is really expressive for any domain.