4 ms·
In my opinion, we need a statically typed contender to R, Python and Julia. The use case is quite simple. Most data-oriented applications where you need linear
by nextos 6y ago
In my opinion, we need a statically typed contender to R, Python and Julia.
The use case is quite simple. Most data-oriented applications where you need linear algebra, probability theory, statistics do contain a significant amount of data pre-processing and business logic once extended to enter production. Here static typing is advantageous. Keeping the whole codebase in the same language is a significant advantage.
Furthemore, some statically typed languages do have typing features that are advantageous for data analysis. Think F# type providers or type systems where e.g. the shape of arrays is guaranteed to match at compile time.
The question is whether Rust is a good language for this, or we need something more like OCaml or F#. All these languages pop up in job offers for quantitative analysis, insurance risk modeling, etc. So there seems to be a demand.
- sieste 6y ago> In my opinion, we need a statically typed contender to R, Python and Julia. Nim is getting there.
- sp33der89 6y agoYup! I hope it gets more love from the scientific community. https://forum.nim-lang.org/t/5242 https://forum.nim-lang.org/t/5242 Also worth mention would be F#: https://github.com/SciSharp https://github.com/SciSharp
- littlestymaar 6y agoNim has lots of cool things and could probably but it really needs to chose one domain to focus on (and data analysis could be it, even though it sounds like a tough challenge given how much love Julia is getting as the new cool kid in that place). Today it looks like it's chasing too many games at a time with limited success.
- bachmeier 6y ago> we need a statically typed contender to R, Python and Julia. I'm not sure we really need a "contender". We need a complement. I personally use D. I love the language, I can compile my functions into a static library, and I can have R load them the same as it loads a library of C functions. It's worked well for me for years. Should work for plenty of languages, whether that's Rust, Nim, or whatever. There are at least two reasons I've moved away from the idea of a replacement language: - It's pretty easy to do if you already have experience with a compiled language. The benefit of a replacement language is small. - You can move to the new language slowly, to the degree that you want, without giving up or rewriting any already working code. Others can easily use your code without having to move to that language.
- dklend122 6y agoThe core team has plans to add optional static typing to julia..won't be there for a year or two though probably
- eigenspace 6y agoAre you sure it's static typing that you want? I find people often conflate having a powerful type system with static typing. Julia has a very powerful and expressive dynamic type system and I really appreciate it. Static typing is significantly more restrictive, which I think is harmful for the interactive workflows which are so prevalent in exploratory data oriented applications. > Furthemore, some statically typed languages do have typing features that are advantageous for data analysis. Think F# type providers or type systems where e.g. the shape of arrays is guaranteed to match at compile time. For instance, julia can do this with it's type system too. There's nothing here requiring static typing. See StaticArrays.jl[1] which has a SArray type (static size, static contents), a MArray type (static size, mutable contents) and a SizedArray type (is a statically sized wrapper for a regular array (rather than Tuple) making it more appropriate for large arrays) [1] https://github.com/JuliaArrays/StaticArrays.jl https://github.com/JuliaArrays/StaticArrays.jl