HackerTrans
TopNewTrendsCommentsPastAskShowJobs

markkitti

no profile record

Submissions

Anthropic partners with Allen Institute and HHMI for life sciences research

anthropic.com
4 points·by markkitti·hace 5 meses·0 comments

comments

markkitti
·hace 19 días·discuss
No, of course not. I am totally not a bot. I just like to connect together unrelated events to see trends at scale.
markkitti
·hace 19 días·discuss
I think a strategy for Qualcomm would be to use Mojo and Max as a software platform to drive AI inference on ARMv9 chips such as Snapdragon either at the edge (your smartphone) or in the cloud.
markkitti
·hace 19 días·discuss
> what kind of programming language would a person with as much experience and good taste as Chris Lattner come up with if there were no such external pressures?

Swift
markkitti
·hace 19 días·discuss
I do not think Julia ever intended to be a Python clone. Julia was created in 2009 when Python was not as popular as today.

I think the statement is a strange one to make about a language that emerged from a PhD thesis. While one could say the objectives of Julia's design were academic (e.g. multiple dispatch) and more attention could have been paid to the practical application of the approach (e.g. where and how do we cache all this machine code we are generating), I find it incredulous to say a six year long PhD dissertation process was not a design phase.

The thesis in question can be found here: https://github.com/JeffBezanson/phdthesis/blob/master/main.p...
markkitti
·hace 19 días·discuss
It is not the only solution to that technical problem though. Past attempts at this have shown a clear preference for solutions that actually are extensions of CPython rather than distinct tool chains.
markkitti
·hace 19 días·discuss
I'm not really sure if Mojo has lost or not, but the community has felt quite different than other language communities I have encountered. The development feels less organic and more driven by venture capital. This is most acutely felt in the current closed source development of mojo itself, which seems like it will continue into the near future.

I look forward to seeing open source mojo and the community that will bring.
markkitti
·hace 20 días·discuss
Yesterday, LineShine a supercomputer in China emerges as #1 in the Top500 using ARM v9 based chips and no GPUs. Today, Qualcomm a premier designer of ARMv9 licensed chips in the United States acquires Modular, who has been creating a compiler stack that provides an alternative to NVIDIA's CUDA stack.

Are you ready for Qualcomm ARMv9 powered inference running Mojo/MAX written kernels doing low-cost inference at scale for AI?
markkitti
·hace 2 meses·discuss
Gemini CLI for Enterprise will continue.

> If your organization uses Gemini CLI or our IDE extensions via a Gemini Code Assist Standard or Enterprise license, or if your organization uses Gemini Code Assist for GitHub through Google Cloud, your access remains unchanged.
markkitti
·hace 3 meses·discuss
I had the exact same experience.
markkitti
·hace 4 meses·discuss
Thank you for listening.
markkitti
·hace 4 meses·discuss
Is Python dying? /s
markkitti
·hace 5 meses·discuss
When I need to do serious math, I use Julia.
markkitti
·hace 5 meses·discuss


    $ julia --lisp
    ;  _
    ; |_ _ _ |_ _ |  . _ _
    ; | (-||||_(_)|__|_)|_)
    ;-------------------|-----    ------------------------------    -----------------------
    > (+ 1 2)
    3
markkitti
·hace 5 meses·discuss
There is now a Julia plugin for JetBrains IDEs: https://plugins.jetbrains.com/plugin/29356-flexible-julia
markkitti
·hace 5 meses·discuss
> it’s better to choose Rust for software engineering and Python for scripting.

Rust and Python work in some scenarios but not all. Unless the native components are all developed already, you will need a Rust programmer on your team. Rust expertise may be available to organizations of a sufficient size and a narrow focus. In my experience, this sort of arrangement requires a team with dedicated resources.

What I encountered more frequently are attempts to use Python as a full stack language. People are not just using it to implement the scripting frontend interface but also trying to implement the backend that does the heavy processing and the numerical computation. As a developer this is a terrible experience. I'm in the middle of replacing for loops in Python with vectorized numpy code but most of my efficiency gains are erased because I still need Python tuples in the end. Yesterday, I had to consider whether exceptions I throw in Cython code can be caught properly in Python.

Research software engineering is one field where you really do need a full stack language. That kind of software engineering requires high performance with limited resources. Julia with some initial patience does deliver a better developer experience in this scenario than the equivalent Python experience for me partly because I do not need to play vectorizarion games, and I can do everything in one integrated environment.

While, yes, interfaces and static tooling could be better, I do think the situation has gotten better over time. There are interface schemes available and additional static tooling is available.

Julia could deliver a better user experience though. Admittedly, the Python tooling to deploy complex solutions has significantly improved lately via tools such as pixi. Julia tools could deliver generic binary code with packages to ease the initial user experience. Advanced users could re-precompile packages to optimize.

The most promising success I have had with Julia is putting notebook interfaces in front of scientists or deploying web apps. My observation in this scenario is that Julia code can be presented as simple enough for a non-professional programmer to modify themselves. Previously, I have only seen that work well with MATLAB and Python. I have not seen this happen with Rust, and I do not expect that to change.

The other observation is that users appreciate the speed of Julia in two ways. 1. Advanced data visualizations are responsive to changes to data. In Python, I would typically need to precompute or prerender these visualizations. With Julia, this can be done dynamically on the fly. 2. Julia user interfaces respond quickly to user input.

While I think Julia has plenty of room to improve, I do think those improvements are possible. I have also greatly appreciated how much Julia has improved in the past five years.
markkitti
·hace 5 meses·discuss
The 0 or 1 based indexing is actually a very superficial debate for people not very familiar with Julia. Note that 1-based indexing is a standard library feature not inherent to the Julia language itself.

The real indexing issue is whether arbitrary-base abstraction is too easily available.

    # Correct, Vector is 1-based
    function mysum(v::Vector{T}) where {T <: Integer}
        s = zero(T)
        for i in 1:length(v)
            s += v[i]
        end
        return s
    end

    #Incorrect, AbstractVector is not necessarily one based
    function mysum(v::AbstractVector{T}) where {T <: Integer)
        s = zero(T)
        for i in 1:length(v)
            s += v[i]
        end
        return s
    end

    #Correct
    function mysum(v::AbstractVector{T}) where {T <: Integer)
        s = zero(T)
        for e in v
            s += e
        end
        return s
    end
Basically, the concrete `Vector` type is 1-based. However, `AbstractVector` is could have an arbitrary first index. OffsetArrays.jl is a non-standard package that provides the ability to create arrays with indexes that can start at an arbitrary point including 0.
markkitti
·hace 5 meses·discuss
Was there something you did not like about Marimo? It is also open source and can run locally.

I'm still confused about your motivations and how your solution differs.
markkitti
·hace 5 meses·discuss
Jupyter is definitely open source:

BSD 3-Clause license

.https://jupyter.org/governance/projectlicense/

I do not understand the motivation behind this project or how it differs from Jupyter or Marimo, which are open source and run locally.
markkitti
·hace 6 meses·discuss
The pyproject.toml, package.json, and Cargo.toml are declarative project configuration files. While the Rust community refers to Cargo.toml as a manifest, it is not a comprehensive and detailed list of a build. That is the lock file.

While go.mod does not allow for explicit version ranges, the versions given are the minimum versions. In other words, the versions given are the lower bound of the compatibility range.

Go also strictly follows semantic versioning. Thus the implicit exclusive upper bound is the next major version. This assumes that all minor and patch releases are backwards compatibile and not breaking.

Dependency resolution in Go uses minimum version selection. That means the minimum requirements of all dependencies are evaluated and highest minimums are selected. In principle, this minimum version selection should be time invariant since the oldest versions of the compatible dependencies are used

While the minimum versions specified in go.mod are not necessarily the version of the dependencies used, they can be resolved to the versions used irrespective of time or later versions of dependencies being released.

Other languages do not use minimum version selection. Their package resolution often tries to retrieve the latest compatible dependency. Thus a lock file is needed.

Python packages in particular do not follow semantic versioning. Thus ranges are critical in a pyproject.toml.

In summary, the "manifests" files that the original author describes are configuration files. In some languages, or more accurately their package management schemes, they can also be lock files, true manifests, due to version semantics. If those semantics are absent, then lock files are necessary for compatibility.
markkitti
·hace 7 meses·discuss
"overengineered" is not the term I would use to describe Python packaging. I would say it is "under-engineered". As in, "Why engineer a configuration file when you can just do it in code?".

This tendency towards what initially seems like the "simple" solution pervades the Python ecosystem and often requires complex engineering to work around later.