FacelessJim

This reminds me of Patrician III so much. The sailing battles had the same wind mechanics. It’s amazing, so many memories unlocked.

You could take a stab at Julia.

It’s still dynamic in nature. But you can tune how much staticity you want. The spectrum goes from Python to C in terms of staticity. And with tools like JETLS.jl maturing you get a lot of the benefits static analysis.

The data pipeline ecosystem is starting to rival that of R and Python. The fact that you can just use Julia functions while keeping the performance allows you to avoid those weird vectorization gymnastics. The ML ecosystem is also in a great state. JUMP.jl, Touring.jl, the whole SciML ecosystem, autodiffing and gpu computing are all close to best in class in terms of quality. The NN side of ML is a a bit weaker, but just for lack of developer time investment into that side of the ecosystem.

I’ve landed on a very similar usage in my last pet project. I’ve used the llm mainly as a glorified refactoring tool/LSP/rubber duck. I can define custom skills that act as specific passes over the codebase that are hard to do with traditional tools, I am using Julia, so I have a skill that is only about doing a semantic and type analysis pass to catch potential type instabilities. Or another that is just about documentation reporting. The workflow for me is always: talk the problem to death/get a report. Triage, decide what I can and should do on my own, what can be left to the llm as mundane boring refactoring tasks, what instead needs me to figure out the correct shape first and then ask the llm to propagate the new pattern in the codebase. Then act. A lot of the time I am implementing the llm suggestion by hand on my own to get a feel of how the codebase is shifting under my feet and stay on top of things. This indeed makes things more slow, but allows for an overall higher quality codebase. Especially the refactoring part.

Might want to take a look at WasmTarget.jl it’s rather new and experimental but could be what you’re looking for!

I would definitely love a glass of smoked cyber

As a sibling comment mentions, yes it does. Just don’t expect to have code that runs as fast as C without some effort put into it. You still need to write your program in a static enough way to obtain those speed. It’s not the easiest thing in the world, since the tooling is, yes, improving but is still not there yet.

If you then want to access fully trimmed small executables then you have to start writing Julia similarly to how you write rust.

To me the fact that this is even possible blows my mind and I have tons of fun coding in it. Except when precompiling things. That is something that really needs to be addressed.

This was supposed to be under a different post. Not the main article. Whops.

That post is 10 years old, stale, with all issues resolved and more.

Waving around an outdated blogpost as if it would automatically invalidate everything is just silly at this point.

Checkout PythonCall.jl and juliacall (on the python side). Not to mention that now you can literally write python wrappers of Julia compiled libraries like you would c++ ones.

Yeah, it didn’t have the explosive success that rust had. Most probably due to a mixture of factors, like the niche/academic background and not being really a language to look at if you didn’t do numerc computing (at the beginning) and therefore out of the mouth of many developers on the internet. And also some aspects of the language being a bit undercooked. But, there’s a but, it is nonetheless growing, as you probably know having read the releases, the new big thing is the introduction of AOT compilaton. But there’s even more stuff cooking now, strict mode for having harder static guaratees at compile time, language syntax evolution mechanisms (think rust editions), cancellation and more stuff I can’t recall at the moment. Julia is an incredibly ambitious project (one might say too ambitious) and it shows both in the fact that the polish is still not there after all this time, but it is also starting to flex its muscles. The speed is real, and the development cycle is something that really spoiled me at this point.

aot will help a lot. In cases of simple programs you can also start Julia with no optimizations, which trade off the startup latency for runtime speed.

You should give Julia a go, can be written completely static if desired (not as static as rust of course, but compared to python it’s miles ahead). Can be made fast, very fast. AOT compilation with trimmed executables is coming in 1.12

It is often the case, that one’s perspective is a personal synthesis of external ideas. The act of quoting great past authors is also a way of recognizing where your influences come from. To describe by association how you think, or aspire to.

These are very difficult topics to properly talk about and correctly express all the nuance in the feeling that you try to convey, and many authors are quoted because they nailed a particular description, evocative of the feeling an author is trying to express and that he feels he can’t do a better job at explaining.

Similarly to how you can narrate a story through a sequence of pictures you can narrate an idea through a sequence of raw concepts, encapsulated in quotes.

This reminds me of a little project [1] I had fun with to try and compute the sharpness of a position and/or evaluate whole lines. Indeed, the notion of sharpness (which I believe it’s different from complexity) although easy to intuit I’ve never found a satisfactory implementation.

[1] https://github.com/ghyatzo/stockfish-line-sharpness

I did something very similar some years ago while learning metal [1], I recall them being called "boids". I spent days just playing with the various parameters, luckily my implementation was not as pretty as the one offered in the OP, otherwise I would have lost weeks instead.

[1] https://github.com/ghyatzo/metalplay?tab=readme-ov-file

This site is unreadable on mobile. Too many nested bullet points

You should give Julia a shot. That’s basically that. You can start with super dynamic code in a REPL and gradually hammer it into stricter and hyper efficient code. It doesn’t have a borrow checker, but it’s expressive enough that you can write something similar as a package (see BorrowChecker.jl).

The “proportionality constant” is doing a lot of work in that claim. A lot of “constant” parameters are swept under the rug. If you fix enough stuff that claim is indeed correct, although I agree a bit simplistic

This feels a bit disingenious. All the languages brought as an example need some sort of handling of the `not found` case. In C++ and Go you need to check against null pointers (or don't but then encounter segafults), Haskell and Rust you are forced to unwrap the value. C also has to check against the error code or incur in errors down the line or worse subtler logic errors.

Missing this types of checks is also source of errors in dynamic languages, adding `1+None` as well as `1+nothing` will return an error if not handled properly. If you are absolutely sure your element will be in the array you have to encode it, for example

x = something(findindex([1,2,3], val)) # return value is Int now, or an error.

or even

x === nothing && error("oh no")

are enough for the compiler to correctly infer that x will just be an Int, and remove the Union.

Also, the claim that the only way to check for unfavourable Union types is to visually scan each function is just plainly false. There are many tools to do this sort of checks, just to name a few: @code_warntype, Cthulhu, DispatchDoctor

I do agree though that Julia has mainly users from academia, and therefore is less polished on the more pure software engineering aspects and tooling. But the disclaimer at the end feels just like the author is dismissing the whole language on false premises due to frustration with lack of support/ecosystem for his specific use case.

This is something that I have always strived for, and try to practice every living moment. You put in clearer and more detailed words what I have been trying to develop by myself.

I will be forever grateful for the time I spent practicing martial arts when I was younger. I was lucky enough to find a master that did not teach the practice as a means to reach agonistic goals but instead as practicing mindfulness and self observation. It was never explicitly told or explained in detail how to do it, it was simply practiced over and over again, indirectly, by checking the positions of your body, legs and arms, are they in the correct position? Am I engaging the correct set of muscles? Does the position feel powerful? Is my attention (ki) flowing in the correct direction, in the right spot? Am I aware of my surroundings and perceptive of my practice partner? We were slowly taught to pay attention, by means of watching ourselves trying to perfect something. Later in life I realized how much of an impact this had on my ability to concentrate, be present, not only in the physical sphere but also in the mental and spiritual or emotional sphere. I slowly began to realize that the real practice of the martial art and striving for the perfect form were always a mean to the real goal of instead practicing mindfulness and perseverence.

To me that is the “art” in martial arts. I am not trying to put them on a pedestal, I believe that this “art” is proper of any activity a human can do, that can become art when it is a means to practice this kind of mindfulness.