Qual a maturidade do projeto de linguagem científica computacional “Julia”?

Estou pensando em aprender uma nova linguagem para usar em projetos de modelagem numérica / simulação, como uma substituição (parcial) para o C ++ e Python que atualmente uso. Me deparei com Julia , o que parece perfeito. Se ele fizer tudo o que afirma, eu poderia usá-lo para substituir o C ++ e o Python em todos os meus projetos, pois ele pode acessar o código da biblioteca de computação científica de alto nível (incluindo o PyPlot), além de executar loops em uma velocidade semelhante a C. Eu também me beneficiaria de coisas como corotinas adequadas que não existem em nenhum dos outros idiomas.

No entanto, é um projeto relativamente novo, atualmente na versão 0.x, e encontrei vários avisos (publicados em várias datas no passado) de que ainda não está pronto para o uso diário. Consequentemente, gostaria de obter algumas informações sobre o status do projeto agora (fevereiro de 2014 ou sempre que uma resposta for publicada), a fim de me ajudar a avaliar se eu pessoalmente consideraria investir tempo para aprender esse idioma nesta fase.

Eu apreciaria respostas que se concentrem em fatos relevantes específicos sobre o projeto Julia ; Estou menos interessado em opiniões baseadas na experiência de outros projetos.

Em particular, um comentário de Geoff Oxberry sugere que a API Julia ainda está em um estado de fluxo, exigindo que o código seja atualizado quando for alterado. Gostaria de ter uma idéia de até que ponto esse é o caso: quais áreas da API são estáveis ​​e quais podem mudar?

Eu acho que normalmente eu estaria principalmente fazendo álgebra linear (por exemplo, resolvendo problemas próprios), integração numérica de ODEs com muitas variáveis ​​e plotagem usando PyPlot e / ou OpenGL, bem como processamento de números de baixo nível no estilo C (por exemplo, para simulações de Monte Carlo ) O sistema de bibliotecas de Julia está totalmente desenvolvido nessas áreas? Em particular, a API é mais ou menos estável para esses tipos de atividades ou eu descobriria que meu código antigo tenderia a quebrar após a atualização para uma nova versão da Julia?

Finalmente, existem outras questões que valeriam a pena considerar ao decidir usar Julia para trabalhos sérios no momento?

Julia, neste momento (maio de 2019, Julia v1.1 com v1.2 prestes a sair) é bastante madura para a computação científica. A versão v1.0 significava o fim da quebra anual de código . Com isso, muitas bibliotecas de computação científica tiveram tempo de simplesmente crescer sem interrupções. Uma ampla visão geral dos pacotes Julia pode ser encontrada em pkg.julialang.org .

Para a computação científica central, a biblioteca DifferentialEquations.jl para equações diferenciais (ODEs, SDEs, DAEs, DDEs, simulações de Gillespie etc.), Flux.jl para redes neurais e a biblioteca JuMP para programação matemática (otimização: linear, quadrática, número inteiro misto, etc.) são três dos pilares do ecossistema de computação científica. A biblioteca de equações diferenciais, em particular, é muito mais desenvolvida do que o que você veria em outros idiomas, com uma grande equipe de desenvolvimento implementando recursos como integradores EPIRK , Runge-Kutta-Nystrom , equação diferencial de atraso rígido / diferencial-algébrico eintegradores de equações diferenciais estocásticas rígidas e adaptáveis , juntamente com vários outros itens, como análise de sensibilidade adjunta , DSLs de reação química , Newton-Krylov sem matriz e compatibilidade GPU completa (sem transferência de dados), com treinamento de equações diferenciais neurais , tudo com resultados fantásticos de benchmark (aviso: sou o desenvolvedor líder).

O que é um pouco desconcertante sobre o amadurecido ecossistema Julia é a sua composibilidade. Essencialmente, quando alguém cria uma função de biblioteca genérica como a de DifferentialEquations.jl, você pode usar qualquer tipo AbstractArray / Number para gerar um novo código rapidamente. Portanto, por exemplo, existe uma biblioteca para propagação de erros ( Measurements.jl ) e quando você o cola no solucionador de ODE, ele compila automaticamente uma nova versão do solucionador de ODE que realiza a propagação de erros sem amostragem de parâmetros . Por esse motivo, talvez você não encontre alguns recursos documentados porque o código para os recursos se gera e, portanto, é necessário pensar mais sobre a composição da biblioteca.

Uma das maneiras pelas quais a composição é mais útil é na álgebra linear. Os solucionadores de ODE, por exemplo, permitem que você especifique jac_prototype, permitindo que você especifique o tipo de jacobiano que será usado internamente. Claro que há coisas na biblioteca padrão LineraAlgebra como Symmetrice Tridiagonalvocê pode usar aqui, mas dada a utilidade de composibility no tipo de algoritmos genéricos, as pessoas têm até agora ido e construiu bibliotecas de tipo matriz inteira. BandedMatrices.jl e BlockBandedMatrices.jl são bibliotecas que definem tipos de matriz em faixas (Block) que possuem lusobrecargas rápidas , tornando-os uma boa maneira de acelerar a solução de discretizações MOL rígidas de sistemas de equações diferenciais parciais. PDMats.jlpermite a especificação de matrizes positivas-definidas. Elemental.jl permite definir um jacobiano esparso distribuído. CuArrays.jl define matrizes na GPU. Etc.

Então você tem todos os seus tipos de números. O Unitful.jl verifica a unidade no momento da compilação, portanto é uma biblioteca de unidades sem sobrecarga. O DoubleFloats.jl é uma biblioteca rápida e de alta precisão, juntamente com o Quadmath.jl e o ArbFloats.jl . O ForwardDiff.jl é uma biblioteca para diferenciação automática no modo de avanço que usa aritmética de número duplo. E eu posso continuar listando isso. E sim, você pode jogá-los em bibliotecas Julia suficientemente genéricas como DifferentialEquations.jl para compilar uma versão especificamente otimizada para esses tipos de números. Mesmo algo como ApproxFun.jlque funciona como objetos algébricos (como Chebfun) trabalha com esse sistema genérico, permitindo a especificação de PDEs como ODEs em escalares em um espaço de funções.

Dadas as vantagens da composibilidade e a maneira como os tipos podem ser usados ​​para gerar código novo e eficiente nas funções genéricas de Julia, tem havido muito trabalho para obter implementações da funcionalidade básica da computação científica na Julia pura. Optim.jl para otimização não linear, NLsolve.jl para resolver sistemas não lineares, IterativeSolvers.jl para solucionadores iterativos de sistemas lineares e sistemas eigensistemas, BlackBoxOptim.jl para otimização de caixa preta, etc. Até a biblioteca de rede neural Flux.jl apenas usa CuArrays. Compilação automática de código de jl na GPU por seus recursos de GPU. Essa composibilidade foi o núcleo do que criou coisas como equações diferenciais neurais no DiffEqFlux.jl. As linguagens de programação probabilística, como o Turing.jl, também estão bastante maduras agora e fazem uso das mesmas ferramentas subjacentes.

Como as bibliotecas de Julia são tão fundamentalmente baseadas em ferramentas de geração de código, não deve ser surpresa que haja muitas ferramentas em torno da geração de código. O sistema de transmissão de Julia gera kernels fundidos em tempo real que são sobrecarregados por tipos de matriz para fornecer muitos dos recursos mencionados acima. O CUDAnative.jl permite compilar o código Julia nos kernels da GPU. O ModelingToolkit.jl desassocia automaticamente os ASTs em um sistema simbólico para transformar código matemático. Cassette.jlpermite "overdub" a função existente de outra pessoa, usando regras para alterar sua função antes do tempo de compilação (por exemplo: altere todas as suas alocações de matriz para alocações estáticas de matriz e mova operações para a GPU). Trata-se de ferramentas mais avançadas (não espero que todo mundo que faz computação científica assuma o controle direto do compilador), mas é assim que muitas ferramentas da próxima geração estão sendo construídas (ou melhor, como os recursos estão sendo escritos por eles mesmos).

Quanto ao paralelismo, mencionei GPUs, e Julia integrou multithreading e computação distribuída . O multithreading de Julia usará muito em breve uma arquitetura PARTR (runtime de tarefas paralelas) que permite o agendamento automatizado de multithreading aninhado . Se você quiser usar MPI, você pode apenas usar MPI.jl . E, claro, a maneira mais fácil de fazer uso de tudo isso é usar apenas uma configuração do tipo AbstractArray para usar o paralelismo em suas operações.

Julia também possui o ecossistema básico subjacente que você esperaria de uma linguagem de uso geral usada para aplicações científicas. Possui o Juno IDE com um depurador embutido com pontos de interrupção , e possui o Plots.jl para fazer todo tipo de plotagem . Muitas ferramentas específicas também são boas, como Revise.jl atualiza automaticamente suas funções / biblioteca quando um arquivo é salvo . Você possui o DataFrames.jl , as bibliotecas de estatísticas etc. Uma das bibliotecas mais agradáveis ​​é a Distributions.jl, que permite escrever algoritmos genéricos para a distribuição (por exemplo:rand(dist)pega um número aleatório de qualquer distribuição que foi passada) e há uma carga inteira de distribuições univariadas e multivariadas (e, é claro, o envio acontece em tempo de compilação, tornando tudo tão rápido quanto codificar uma função específica da distribuição). Existe um monte de ferramentas de manipulação de dados , servidores da web etc. Neste ponto, está maduro o suficiente para que, se houver uma coisa científica básica e você espere que ela exista, basta pesquisar no Google com .jl ou Julia e ela aparecerá.

Depois, há algumas coisas a ter em mente no horizonte. O PackageCompiler procura criar binários a partir das bibliotecas Julia, e ele já tem alguns sucessos, mas precisa de mais desenvolvimento. O Makie.jl é uma biblioteca inteira para plotagem acelerada por GPU com interatividade, e ainda precisa de mais trabalho, mas está realmente procurando se tornar a principal biblioteca de plotagem em Julia. O Zygote.jl é uma biblioteca de diferenciação automática de fonte a fonte que não apresenta os problemas de desempenho de um AD baseado em rastreamento (Tracker do Flux, PyTorch, Jax) e que procura trabalhar em todos os códigos Julia puros. Etc.

Em conclusão, você pode encontrar muito movimento em muitos lugares, mas na maioria das áreas já existe uma biblioteca sólida e madura. Não está mais em um lugar em que você pergunta "será adotado?": Julia foi adotada por pessoas o suficiente (milhões de downloads) que tem o momento de permanecer por perto para sempre. Ele tem uma comunidade muito boa, então se você quiser apenas falar sobre computação paralela ou equações diferenciais numéricas, algumas das melhores salas de bate-papo estão no Julialang Slack . Se é um idioma que você deve aprender é uma pergunta pessoal e se é o idioma certo para o seu projeto é uma questão técnica, e essas são diferentes. Mas é uma linguagem que amadureceu e tem o apoio de um grande grupo consistente de desenvolvedores? Isso parece ser afirmativo.

Caso contrário, é possível fornecer uma estimativa aproximada da ordem de magnitude por quanto tempo devo esperar antes de considerá-la novamente?

Minha estimativa aproximada e em ordem de magnitude de quanto tempo as linguagens da ciência computacional levam para amadurecer é de cerca de uma década.

Exemplo 1: SciPy iniciado em 2001, aproximadamente. Em 2009, o Scipy 0.7.0 foi lançado, e o integrador ODE tinha uma interface para o VODE (que é o equivalente a ode15s, aproximadamente; ode15sé baseado em NDF, o VODE é BDF / Adams-Bashforth, dependendo). Com o SciPy 0.10.0, uma interface para dopri5, que é aproximadamente o equivalente do MATLAB ode45, um método de 4ª ordem de Runge-Kutta normalmente introduzido como o primeiro método prático de integração numérica para alunos de graduação. O SciPy 0.10.0 foi lançado em dezembro de 2011 e demorou cerca de 10 anos para incluir um recurso do MATLAB apresentado a todos os estudantes de engenharia que eu conheço.

Exemplo 2: O Mathworks foi fundado em 1984. Em seu primeiro lançamento, eles usaram uma porta LAPACK para C chamada JACKPAC (em homenagem a Jack Little, um engenheiro do MathWorks que a escreveu). Eles não o substituíram pelo LAPACK até 2000.

Julia pode levar menos tempo, mas eu estimaria cerca de 10 anos desde a fundação para se tornar mainstream. (Já faz um ano ou mais; talvez 9 a 10 anos, então?)

O sistema de bibliotecas de Julia está totalmente desenvolvido nessas áreas? Em particular, a API é mais ou menos estável para esses tipos de atividades ou eu descobriria que meu código antigo tenderia a quebrar após a atualização para uma nova versão da Julia?

Eu não uso Julia, então pegue o que digo com um pouco de sal, já que eu só vi Jeff Bezanson fazendo apresentações sobre Julia. Eles se curvaram para trás para facilitar o link e o uso de bibliotecas de C, Python e Fortran. Se você não conseguir encontrar uma biblioteca Julia que faça o que deseja, escreva um calço Julia para uma biblioteca em um idioma mais estabelecido. Consequentemente, não acho que a falta de bibliotecas seja uma preocupação. Eu acho que uma preocupação será garantir que as alterações nos principais recursos da linguagem não o incomodem. Se você observar os marcos no repositório Julia Git, verá que a tag "breaking" é usada bastante (12 vezes na versão 0.2, 5 vezes na versão 0.3). Para mim, isso sugere que a linguagem principal ainda está evoluindo, e é por isso que hesito em usar a linguagem agora.

EDIT: Aurelius traz um bom ponto:

O que faz você supor que Julia realmente se tornará mainstream, e não apenas desaparecer na obscuridade, como tantas outras línguas? SciPy / numpy tinha / tem o apoio de uma comunidade python cada vez maior, que Julia não tem.

Na resposta original, decidi evitar a pergunta "Julia conseguirá se tornar popular?" tanto quanto possível. Falhar é fácil; o sucesso é difícil. Acho que a melhor comparação de Julia é com linguagens técnicas de computação como MATLAB, R e Octave. As linguagens HPC (Chapel, Fortress, UPC etc.) têm um público mais restrito do que as linguagens técnicas de computação, e as linguagens de uso geral (C, Python, C ++ etc.) têm uma audiência mais ampla que as linguagens técnicas de computação.

Algo que acho que ajuda Júlia é projetar para o desempenho sem sacrificar a expressividade. Julia é muito mais competitiva com linguagens compiladas como C do que MATLAB, R ou mesmo Python. Esse objetivo de design também é um recurso que pode atrair pessoas de idiomas existentes, como:

• As pessoas que se preocupam muito com o desempenho e vêm de linguagens como C e Fortran, mas estão dispostos a sacrificar um minúsculo pouco de desempenho (talvez um fator de 2ish) para ir de linguagem compilada para menos linhas de linguagem interpretada (junto com um REPL para desenvolvimento e teste mais rápidos).
• Pessoas que se preocupam com alta produtividade e vêm de linguagens como Python, R e MATLAB, mas desejam mais desempenho. Quando se trata de execução, Python puro, MATLAB puro e R puro são lentos. Os desenvolvedores nessas linguagens fizeram o possível para agrupar bibliotecas em linguagens compiladas, mas você não pode agrupar tudo e, em algum momento, a linguagem principal vai atrasá-lo. O Core Julia é mais rápido, o que permite fazer mais ciência com mais rapidez.
• Pessoas que se preocupam com software livre. Julia é interpretada e gratuita (assim como Python, Octave etc.); MATLAB não é.

Julia também está tentando facilitar o paralelismo; Não me sinto muito qualificado para expandir esse ponto, e não acho que seja o principal atrativo da linguagem, mas acho que é um ponto de venda no qual eles estão trabalhando, e espero que outros possam esclarecer isso.

No entanto, mesmo com o mérito técnico do lado deles, os criadores de idiomas precisam fazer o trabalho braçal para promover o idioma e evangelizar. Jeff Bezanson, Alan Edelman, Stephen Karpinski e Viral Shah estão trabalhando muito para tornar o idioma bem-sucedido. Alan Edelman tem laços profundos com a comunidade de ciências computacionais e já trabalhou em projetos no nível da linguagem (principalmente a extensão Star-P para o MATLAB). Jeff Bezanson faz o circuito da conferência para promover Julia a cientistas e engenheiros da computação há um tempo. No MIT, eles têm feito um bom trabalho ao recrutar estudantes e funcionários (principalmente Steven G. Johnson) para contribuir adicionando bibliotecas a Julia. Eles têm um artigo na Wired e conseguiram obter um artigo da Wikipedia para si, depois de apenas um ano. O repositório Git tem milhares de estrelas, centenas de garfos, e centenas de relógios, de acordo com os padrões de código aberto, o projeto deles foi um sucesso. Eu acho que eles fizeram todas as coisas certas até agora, então é uma questão de sustentar esse esforço e criar uma comunidade. Eles ainda podem falhar, mas chegar até aqui sugere que eles têm uma chance razoável de sucesso.

Acredito que Julia vale a pena aprender. Usei-o para produzir alguns códigos de elementos finitos de pesquisa e produzi-los muito rapidamente. Fiquei muito satisfeito com a minha experiência.

Julia ativou para mim um fluxo de trabalho que achei difícil de alcançar com outros idiomas. Você pode usá-lo como uma linguagem de prototipagem como o MATLAB, mas, diferentemente do MATLAB, quando você tem um código de trabalho e está passando por iterações de criação de perfil para acelerá-lo, substituir os pontos de acesso pelo código C é indolor. Eles fizeram da interface com C (e Python) uma prioridade no design.

Assim, a linguagem me permitiu passar muito rapidamente de minhas formulações matemáticas para código funcional e, em seguida, de código funcional para código de alto desempenho. Eu acho que esse recurso de Julia está com uma sub-venda, mas agrega um valor tremendo.

Em muitos casos, obtive desempenho C (comparado ao meu próprio código C) em questão de horas após a produção de um código de elemento finito funcional. Até agora, se eu usar apenas os recursos de Julia, normalmente chego a ~ 3X mais lento que C. Depois disso, substituo os pontos de acesso por funções C (Julia vem com um perfilador de amostragem de pilha para ajudar a identificá-los). Muitas vezes, isso requer apenas a substituição das linhas de código do ponto de acesso ofensivo por uma "chamada", com Julia lidando com qualquer empacotamento.

Acho que as principais coisas que Julia está perdendo agora, embora isso me faça hesitar em considerá-lo para projetos maiores, são a falta de um depurador totalmente suportado e um suporte ruim para plotagem (no momento, sua melhor aposta na plotagem é na verdade apenas uma interface para o matplotlib que eu tive que quebrar mais frequentemente do que não). O feedback imediato sobre o código é realmente importante. Também não sei como sobreviver sem a depuração interativa e, nesse aspecto, sou muito mimado pelo MATLAB e GDB.

Da minha experiência, Julia ainda não está pronta para o uso diário (científico) (estou falando da versão estabilizada 0.4 de março de 2016). A linguagem em si é agradável, apresenta recursos ricos e consistentes; um passo refrescante do matlab e do python. Certamente há casos de uso em que Julia é uma boa escolha, mesmo nesta fase inicial. Mas se você precisar de bibliotecas científicas confiáveis ​​e maduras, não posso recomendar a mudança agora. Os principais problemas que encontrei são:

• Os pacotes fora do núcleo de Julia não são confiáveis. Eles quebram com atualizações, mudam, são substituídos, às vezes são incompletos ou simplesmente quebrados.
• Os recursos de paralelismo de Julia (os recursos mais promissores do matlab em potencial) são imaturos. Você encontrará falhas de segmentação, vazamentos de memória, falhas e desempenho decepcionante. Às vezes, eles não funcionam bem com outras partes do julia, por exemplo, alguns dos solucionadores de sistemas lineares ou pacotes fora do núcleo. Embora esses recursos pareçam promissores, eles geralmente falham para mim. Quase nunca bastava escrever @parallelna frente do loop for, onde em teoria deveria.
• Muitas pequenas coisas, pequenos bugs e problemas com os quais se pode conviver: rastreios de pilha de chamadas não tão agradáveis ​​e às vezes errôneos, um pouco de histórico de interpretadores de bugs, carregamento lento de pacotes, mau desempenho de um ou outro pacote / função etc. O que me incomodou o mais é o pacote PyPlot, um wrapper para o matplotlib, atualmente não há alternativa a ele. É realmente ótimo que ele esteja lá e funcione principalmente. Mas se você precisar plotar dados, esteja preparado para problemas e desempenho muito lentos.

Tudo isso vai melhorar. Estou confiante de que algum dia julia será superior ao matlab e python em quase todos os aspectos. Há grandes chances de que pacotes inovadores sejam desenvolvidos para isso. Parece que já existe uma grande comunidade. Mesmo agora, existem diversos pacotes com casos de uso que variam de opencl a servidores da web. O uso de bibliotecas python ou c é muito fácil; portanto, você provavelmente não encontrará uma barreira em termos de disponibilidade da biblioteca. Uma grande força de Julia será o esforço com o qual é possível colar a funcionalidade de alto desempenho de várias fontes em uma linguagem moderna e consistente de alto nível (consulte as respostas acima). Mas como um todo, achei que não era maduro nem estável o suficiente para ser usado produtivamente.