markkitti

Summary: They fixed Python packaging by not having to run Python to resolve dependencies. Also, they used Rust.

Moral of the story: Use less Python. Use declarative configuration and other langauges instead.

>> you can literally write python wrappers of Julia compiled libraries like you would c++ ones. > Yes, please. What do I google? Why can't julia compile down to a module easily?

Try JuliaC for compiling shared libraries if that is what you mean by a "module": https://github.com/JuliaLang/JuliaC.jl

That said Julia's original design focused on just-in-time compilation rather than ahead-of-time compilation, so the AOT process is still rough.

> I don't understand why there's so much friction between julia and python. You should be able to trivially throw a numpy array at julia and get a result back.

You can throw a numpy array at Julia and get a result back. See https://juliapy.github.io/PythonCall.jl/stable/juliacall/

> I wish there was a way to specify the offset base with something like a C #define or compiler directive.

Julia has OffsetArrays.jl implementing arbitrary-base indexing: https://juliaarrays.github.io/OffsetArrays.jl/stable/

The experience with this has been quite mixed, creating a new surface for bugs to appear. Used well, it can be very convenient for the reasons you state.

  julia> A = collect(1:5)
  5-element Vector{Int64}:
   1
   2
   3
   4
   5

  julia> B = OffsetArray(A, -1)
  5-element OffsetArray(::Vector{Int64}, 0:4) with eltype Int64 with indices 0:4:
   1
   2
   3
   4
   5

  julia> A[1]
  1

  julia> B[0]
  1

I tried this in Julia with TidierData.jl, and it looks quite similar to the R version.

  using TidierData, DataFrames
  using PalmerPenguins: load

  penguins = load()

  @chain penguins begin
    DataFrame
    @drop_missing(body_mass_g)
    @group_by(species, island)
    @summarize(
      body_weight_mean =
        mean(body_mass_g),
      body_weight_std =
        std(body_mass_g)
    )
    show(_, allrows=true)
  end

> Unfortunately, there's no alternative, and I don't see R as much easier, there are plenty of ugly things as well there.

Have you tried Polars? It really discourages the inefficient creation of intermediate boolean arrays such as in the code that you are showing.

> There's Julia -- it has serious drawbacks, like slow cold start if you launch a Julia script from the shell, which makes it unsuitable for CLI workflows.

Julia has gotten significantly better over time with regard to startup, especially with regard to plotting. There is definitely a preference for REPL or notebook based development to spread the costs of compilation over many executions. Compilation is increasingly modular with package based precompilation as well as ahead-of-time compilation modes. I do appreciate that typical compilation is an implicit step making the workflow much more similar to a scripting language than a traditionally compiled language.

I also do appreciate that traditional ahead-of-time static compilation to binary executable is also available now for deployment.

After a day of development in R or Python, I usually start regretting that I am not using Julia because I know yesterday's code could be executing much faster if I did. The question really becomes do I want to pay with time today or over the lifetime of the project.

It sounds like there are many Python users who have acclimated to the situation of needing three or more tools to work with Python and do not see the benefit or value of being able to do this all with one potentially faster tool.

While I understand that some have acclimated well to the prior situation and see no need to change their methods, is there really no objective self-awareness that perhaps having one fast tool over many tools may be objectively better?

What tooling do you use?

The creators got burned on Swift for TensorFlow, their first MLIR project. One of the problems with that first venture under Google was that the language was not Python.

The Python superset concept was always a gimmick. The goal was always to juxtapose Python with a language that superficially looks like Python in order for you to completely migrate from Python to Mojo. It is just providing a smooth ramp for you to do so in the same Apple migrated folks from Objective-C to Swift.

Embrace. Extend. Extinguish.

Please come up with better names for these models. This sounds like the processor in my Mac Studio.

It looks like JuliaHub is going to take on Simulink with Dyad Studio under a source-available license.

Agreed. This should have been Python 4.

It's funny how much easier GPU support, especially vendor agnostic GPU support, is in Julia.

Even the term "oversampling" implies that sampling beyond Nyquist rate is excessive. I think you would agree that one is not being excessive. It is necessary to sample well beyond accepted "Nyquist rate" in order to reconstruct the signal.

MATLAB® by MathWorks

Apparently ChatGPT does pretty well with Julia. https://www.stochasticlifestyle.com/chatgpt-performs-better-...

It does take some asking around to discover the optimal Julia workflow with Revise.jl, PkgTemplates.jl, VSCode settings/debugger, Pluto.jl, but now it's probably my best development experience. Julia 1.10 improves much of this as well.

After looking at Mojo, I appreciated all the paradigms that Julia was pushing forward even more than I did before. Mojo's greatest asset and curse is focusing on being a better Python. Julia's greatest asset and curse is trying to do a lot more.

Are there solid C interfaces that can be used?

A large part of why I started using Julia is because calling into other languages through the C FFI is pretty easy and efficient. Most of the wrappers are a single line. If there is not existing driver support, I would pass the C headers through Clang.jl, which automatically wraps the C API in a C header.

https://github.com/JuliaInterop/Clang.jl

I most recently did this with libtiff. Here is the Clang.jl code to generate the bindings. It's less than 30 lines of sterotypical code.

https://github.com/mkitti/LibTIFF.jl/tree/main/gen

The generated bindings with a few tweaks is here:

https://github.com/mkitti/LibTIFF.jl/blob/main/src/LibTIFF.j...

I'm not sure that's a fair description at this point. They have distributed some SDKs at this point.

I really do wish it were open source already though. I know they have laid out a roadmap for opening the source.

Using Cython via pure Python mode seems pretty compelling if you all you need is compilation. Compilability is just the beginning though.

There is https://github.com/FluxML/Torch.jl. There are also Julia native frameworks such as FluxML, https://fluxml.ai/ .

One of my favorite things recently is using JS/TS with Julia, usually via a Pluto.jl notebook.

There are also some nice demonstrations showing Julia compiled to web assembly. https://tshort.github.io/WebAssemblyCompiler.jl/stable/examp...

How about a 16K Hello World?

  julia> using StaticTools, StaticCompiler
  
  julia> hello_world() = printf(c"Hello World\n")
  hello_world (generic function with 1 method)
  
  julia> compile_executable(hello_world, (), "./")
  "~/hello_world"
  
  shell> ./hello_world
  Hello World
  
  shell> du -h hello_world
  16K hello_world

See https://github.com/brenhinkeller/StaticTools.jl for further details and limitations.

For discovering methods you can do

  julia> ?("hello", 1, 2.0)[TAB]
  broadcast(f, x::Number...) @ Base.Broadcast broadcast.jl:844
  readuntil(filename::AbstractString, args...; kw...) @ Base io.jl:520
  ...

See the Tab Completion section of the REPL documentation, https://docs.julialang.org/en/v1/stdlib/REPL/#Tab-completion .

Using recent features of WebAssembly such as the garbage collector, Tom Short provides a new demonstration of compiling Julia to WebAssembly via binaryen along with three live examples: the Lorenz model with OrdinaryDiffEq, making interactive SVGs via Observables, and plotting the sum of sine waves with the graphics system Makie.

> do I want integers like Python or integers like C? Yes.

Julia has BigInt and Cint. Maybe there could be a more Pythonic implementation that scales between machine types and BigInt. That would not be hard to implement in Julia. I just have not found a good use case.

What I like about Julia is that I can do both the high level and low level in Julia. Abstract code becomes concrete due to late binding.

You can access Libc.malloc and Libc.free if needed. See GPUCompiler.jl

The effect system exists. If you can prove no side effects, eager finalization is also possible. That is the finalizer and deallocation will run deterministically. It's new though so effect analysis is a mostly manual affair at the moment.

I honestly do not understand comments like this with regard to an open source project. The language and its libraries are rather hackable as is with rather powerful packages. While I may not agree with every decision, I do not complain that someone is not implementing my favorite feature. I just do it myself.

I frankly would be concerned if the main contributors were not focused.

You can create a shared library via PackageCompiler.jl today and `@cfunction`. It's just not as modular as it could be.

https://julialang.github.io/PackageCompiler.jl/stable/libs.h...

No. Julia runs natively on ARM.

  julia> versioninfo() 
                                                 
  Julia Version 1.9.3                                                   
  Commit bed2cd540a1 (2023-08-24 14:43 UTC)                             
  Build Info:                                                             
  Official https://julialang.org/ release
  Platform Info:                                                          
  OS: Linux (aarch64-linux-gnu)                                         
  CPU: 6 × Cortex-A55                                                   
  WORD_SIZE: 64                                                         
  LIBM: libopenlibm                                                     
  LLVM: libLLVM-14.0.6 (ORCJIT, cortex-a55)                             
  Threads: 1 on 8 virtual cores

I run it via Termux and proot-distro: https://discourse.julialang.org/t/how-to-set-up-julia-on-and...

A Pluto.jl notebook is also a regular file. You need to use a package for precompilation caching though.