HNHacker News
TopNewBestAskShowJobs

markkitti

214 karma · joined March 11, 2021

submissionscomments
markkitti··on GNU Octave
Octave is nice, but I never found it very compelling as an open source but lesser version of MATLAB. In part, this is because I have been privileged to have someone else cover the costs for me.

Numpy and Julia are alternative open source projects that cover some of the same use cases, but also add some additonal value. Numpy works with the Python ecosystem and its API has been emulated for distinct applications. Julia shares some of MATLAB and Octave's syntax, adds an advanced algebraic type system, and has expanding native code generating capabilities.

markkitti··on Startups are building with the Julia Programming Language
We bring up these posts every time Julia is mentioned on HN. I've become reticent to respond to these comments. It seems like any response that does not sound like it came from a customer service representative, e.g. "Thank you for expressing your concerns. We acknowledge there are issues, and we are working on it.", will get interpreted as being dismissive or arrogant. I frankly prefer to hear technical responses to the critiques and about how specific issues are being addressed even if they may not be to my satisfaction. Still though, it is important to continue a conversation about this. We should encourage a dialog rather than suppress it.

What's clear to me is that the current state of Julia is not for everyone, and that's fine. There are many other solutions in this space with extensive funding or experience that are likely a better fit for many. For some, incremental improvements on existing technology are more appropriate than a new language introducing new paradigms. Working with Julia is a participatory process, and I understand not everyone has time for that. I thank the pioneers for trying, even if they have decided its not for them at this stage. At the same time, some circumstances require more than incremental change.

On one hand, the comments here posit that nothing is changing and that Julia is slow. Perhaps more precisely the complaint is about its compilation latency: 1. "It has been a constant complaint and a constant broken promise." 2. "every couple of years I try julia again, and every time it's still slow"

On the other hand, these comments are replying to a post about a pull request [1] addressing "time to first X" (TTFX) by providing infrastructure to cache native code on a per package basis. For further background, please refer to a prior pull request merged last month which tackles the prerequisite step of supporting external linkage in system images [2]. The recent pull request also contains an evaluation from a "non-core" developer who is reviewing the pull request, sharing his real world experience with graphs, measurements, and comments about the documentation. To me this pull request is exemplary of how Julia development should work and how users can contribute to the process. Referring to the original article, I also notice that many of the companies and startups mentioned are involved with the development of the Julia language itself rather than merely the application of the language. Perhaps this ability to participate in Julia development at this stage is seen as a feature to these organizations.

I'm unclear what the critique is here with rehasing these comments in response to a pull request. Should that pull request take another approach? Is code review on that pull request progressing too slowly? Is it that the priority should shift away from the compiler to provide further infrastructure for correctness, traits, or some other feature? There's a lost opportunity here to actually expand the conversation rather than reiterating the same arguments.

Nonetheless, I thank thetwentyone for posting news about a substantive pull request addressing compilation based latency. I hope to hear more about these ongoing efforts.

[1] https://github.com/JuliaLang/julia/pull/47184 [2] https://github.com/JuliaLang/julia/pull/44527

markkitti··on Startups are building with the Julia Programming Language
What is the HN type audience? HN is a news feed run by Ycombinator, a "startup accelerator". While many people around here have deep technical expertise, given the name "Hacker News", I always thought the main purpose was to make news and technical discussions more accessible to non-technical co-founders and startup executives.
markkitti··on Ask HN: Programming without a build system?
I appreciate that the Julia base install and standard library includes dependency management and that compilation happens on the fly. The entire experience involves Julia itself modifying a few TOML files. It really helps when almost everyone using the language is using the same package management system.
markkitti··on Ask HN: Why hasn't the deep learning community embraced Julia yet?
> My example of this is the Colors.jl package. Images, rather than being 3D arrays of floats/ints, instead become 2D arrays of RGB/HSV. But you can't do any arithmetic on RGB/HSV values, you need ColorVectorSpace.jl for that. I'm sure it makes sense, but I can't help but feel as if sense is taking precedence over the programmer's experience in many of these packages.

If you just used Images.jl, it would load both Colors.jl and ColorVectorSpace.jl.

Let's say you obtained one of the matrices of RGB values, but you wanted a 3D array of numbers. `channelview` will provide you with a no-copy representation of the image as exactly that.

``` julia> using Images, TestImages

julia> img = testimage("barbara_color.png");

julia> typeof(img) Matrix{RGB{N0f8}} (alias for Array{RGB{Normed{UInt8, 8}}, 2})

julia> channelview(img) |> ndims 3 ```

While it took getting used to, have an image processing framework that explicitly has a concept of color instead of generically mapping everything into an array is actually quite useful. Having a 2D array representing a 2D image is conceptually quite nice.

Also you can do arithmetic on RGB or HSV types directly.

``` julia> (RGB(1,0,0) + RGB(0,1,0))/2 RGB{Float32}(0.5f0,0.5f0,0.0f0) ```

markkitti··on Ask HN: Why hasn't the deep learning community embraced Julia yet?
Try `println(1)`
markkitti··on Technical Preview: Programming Apple M1 GPUs in Julia with Metal.jl
It's amazing how adaptive Julia is to incorporating new technologies.
markkitti··on My Experiences with Julia
You could use Julia in an interpreted mode (or a compiler with low optimization) and then statically compile it for production.

The JIT involved is really a static compiler that has been adapted for use as a JIT compiler: https://llvm.org/docs/ORCv2.html

https://juliadebug.github.io/JuliaInterpreter.jl/stable/ https://julialang.github.io/PackageCompiler.jl/stable/apps.h... https://github.com/tshort/StaticCompiler.jl

markkitti··on My Experiences with Julia
If you really wanted to, you could run PackageCompiler.jl as part of an edit-compile loop: https://julialang.github.io/PackageCompiler.jl/stable/exampl...
markkitti··on Correctness and composability bugs in the Julia ecosystem
If the function signature said `Array` rather than `AbstractArray`, then this code would have been fine. `Array` indexing starts at `1`.

``` julia> function f(A::Array) println(A[1:length(A)]) end f (generic function with 1 method)

julia> f([1,2,3,4]) [1, 2, 3, 4]

julia> f(OffsetArray(1:10, -1)) ERROR: MethodError: no method matching f(::OffsetVector{Int64, UnitRange{Int64}}) ```

You could prevent this problem using Julia's type system. The `AbstractArray` might have been too broad. Based on the chronology of the code that might not have been apparent. See other threads for details.

Another way would be to treat `firstindex` as a trait and dispatch on that. ``` julia> f(A::AbstractArray) = f(A, Val(firstindex(A))) f (generic function with 1 method)

julia> f(A::AbstractArray, firstindex::Val{1}) = println(A[1:length(A)]) f (generic function with 2 methods)

julia> f(A::AbstractArray, firstindex::Val{T}) where T = error("Indexing for array does not start at 1") f (generic function with 3 methods)

julia> f(A::AbstractArray, firstindex::Val{0}) = println("So you like 0-based indexing?") f (generic function with 4 methods)

julia> f([1,2,3,4]) [1, 2, 3, 4]

julia> using OffsetArrays

julia> f(OffsetArray(1:10, 1)) ERROR: Indexing for array does not start at 1 Stacktrace: [1] error(s::String) @ Base .\error.jl:33 [2] f(A::OffsetVector{Int64, UnitRange{Int64}}, #unused#::Val{2}) @ Main .\REPL[5]:1 [3] f(A::OffsetVector{Int64, UnitRange{Int64}}) @ Main .\REPL[3]:1 [4] top-level scope @ REPL[9]:1

julia> f(OffsetArray(1:10, -1)) So you like 0-based indexing? ```

markkitti··on Correctness and composability bugs in the Julia ecosystem
> And Julia provides no way of specifying the behaviour of abstract types.

I'm not sure if "no way" is accurate. There are interfaces and one could use traits. As cited above, we could use `eachindex` or `CartesianIndices` to get a list of the valid indices. The problem is enforcing and testing these interfaces.

markkitti··on Correctness and composability bugs in the Julia ecosystem
For some of these polynomials such as Fourier polynomials, it is natural to think about negative subscripts from a pure mathematical perspective. While these can mapped into non-negative integers, it is often intuitive to use the "negative subscripts" as indexes necessitating methods such as `fftshift`. For many of these polynomials the concept of where they "start" is arbitrary.
markkitti··on Correctness and composability bugs in the Julia ecosystem
The question here is are these merely just bugs or is there something about the language that makes Julia error prone?

There is potential in using Julia's type inference engine to check for correctness. For example see JET.jl. "JET.jl employs Julia's type inference to detect potential bugs."

https://github.com/aviatesk/JET.jl https://www.youtube.com/watch?v=7eOiGc8wfE0

The video brings up some potential difficulties with Julia's metaprogramming facilities for static or lexical analysis, but also shows that these issues are also addressable.

The type inference system could be exploited for further effect. For example, the type system could be extended to check for shape information within the type as demonstrated in this prototype: https://twitter.com/KenoFischer/status/1407810981338796035

Julia has guard rails (e.g. default bounds checking), but also also provides facilities to work outside them (`@inbounds`, `unsafe_*` methods, `ccall`, in-place methods with a `!` suffix). Typically these provide features that trade safety for performance or access to features. Used judiciously one can achieve a balance between performance and safety. Julia is not a language that restricts its users to a sandbox in the name of safety, but it does provide bounds of where the sandbox is and is not.

Another take away from the original blog post is that much Julia development is happening in the open on Github. These issues and their fixes just require a Github account to contribute to. Is this a feature?

markkitti··on Correctness and composability bugs in the Julia ecosystem
Yes, and it is a perfectly fine feature when applied correctly. It would be incorrect to assume that an `AbstractArray` starts at `1` or `0` which is why the updated example now correctly uses `eachindex`: https://docs.julialang.org/en/v1/devdocs/boundscheck/#Elidin...

If you want to assume that an array starts at `1` one needs to require an `Array` rather than an `AbstractArray`.

markkitti··on Python Language Summit: Python Without the GIL
Julia has some excellent interactive front ends.

For example, take a look at the reactive Julia notebook, Pluto.jl: https://plutojl.org/plutocon2021

markkitti··on Julia and the Reincarnation of Lisp (2020)

  $ julia --lisp
  ;  _
  ; |_ _ _ |_ _ |  . _ _
  ; | (-||||_(_)|__|_)|_)
  ;-------------------|------------------------------------ 
 ----------------------
  
  > (+ 1 2)
  3
  
  > (exit)

https://github.com/JeffBezanson/femtolisp
markkitti··on Opticsim.jl: Optical Simulation Software
The last time I talked to him he was trying to write his own discrete Fourier transform so he could avoid shifting around his matrix.

https://github.com/JuliaOptics/Fourier.jl

markkitti··on Julia receives DARPA award to accelerate electronics simulation
If by "metal language" you mean a language that produces machine assembly, then Julia is also a metal language. Both Rust and Julia use the LLVM compiler infrastructure.
← PreviousPage 4 of 4