Very excited to see this. I thought that speed does not matter much for python tooling, but then I tried uv, and realized that I was wrong. The experience is just better. Looking forward to see more high performance quality tooling for Python.
I really do want to learn and love it. It seems I love all the things which are told about it, but, I think JJ has a tutorial problem. I would really want something which focuses on concepts of it rather than workflows. May be some diagrams? I know that JJ-ists think that it is very easy to understand wall of cli printed text, with ascii trees and hash prefixes in bold, but it really isn't. Especially for target audience of tutorials (folks new to JJ).
https://jj-for-everyone.github.io is the most approachable jj tutorial I've seen. I wouldn't say it focuses on workflows, but it does take a "learn by doing" approach a bit more than the "data model first" approach it sounds like you might prefer.
It's still a young tool, it's not surprising that tutorials are a bit lacking (honestly there are surprisingly many for its age). Maybe be the change you want to see in the world and make one? (Which would be an... interesting... way to learn the tool for sure).
Same. It's how I learned Docker and Kubernetes, study the concepts, then I can ask "what's the specific command to do A,B,C" instead of an open ended "how do I do X".
Have you tried it yet? I found the tutorials a bit convoluted. But just giving it a go for a couple of days gave me more in practice than reading docs for a week could. It's not to say the docs couldn't be better - just maybe it's not as much of a barrier as you think.
I think this is weirdly resonated with me. I used moved to Rust from C for embedded programming, and realized that my whole paradigm shifted on how I write programs.
Rust is much more than safe(r) C, it is different approach of architecting apps to have safer relations between components. Now that I am looking at my old code, I see how it would benefit from this paradigm.
And it also a 'problem' with Rust - it requires one to think differently. You can write Rusty code in C, and indeed results are just better, but trying to write Rust in C style would lead to fighting compiler and suffering.
Other languages, like Zig or Go, they chose different approach - to decorate C with modern features, and that works too.
IMO Ubuntu Mono and Ubuntu Sans Mono are two of the best fonts ever made, comparable to Consolas, which I think it's still the best monospace font... talking about monospace fonts.
I could consider anti-DEI sentiment that 'people jumping the lane' as morally acceptable (valid by itself but based on wrong assumptions), but this, this is just evil. Like why would you change font because it is harder to read for someone?
The biggest reason against Rust is 3 year old article from personal blog. Trying to reproduce benchmark result from it result in failure because Zig code fails to compile.
Meanwhile Rust compiles just fine. Even updating toolchain to newest causes no issues and benchmark still runs. All I had to do is remove pinning to old toolchain, and bump language version to latest. Also changing dependency version to latest worked without an issue.
You'd think that performing all advanced memory manipulations you would want all the safety you want, but hey. Zig is cool this days.
I've written a fair amount of code in Rust and D and a little less in Zig. In my opinion, Zig was not ready for prime time when I used it -- too many bugs -- and that may still be true. Rust is hard to learn and even after you do, it gets in the way a lot. D is very nice if you like C, but there are a lot of problems with the project and the tooling.
I'm about to say something that will likely surprise you; it surprised me: have you folks thought about Ada? I was around, working on (D)ARPA contracts at BBN, when Ada was designed. We didn't use it, so I had no opinion of it at the time. I thought it had dried up and blown away in the decades since, like PL1.
Well, it's now #17 on the Tiobe index and climbing. So I gave it a try for a small project. My reaction is very positive. The language is well-designed, obviously having learned a lot of lessons from the mistakes of C, among other things. The compiler, gnat, is built on gcc. Compilation times are very fast, execution times are fast, it works well with gdb, and it's well documented. It avoids many of the traps of C (no pointer arithmetic, no automatic type conversions) and it just feels carefully engineered. It's been used to build a lot of applications in areas like train control and aviation where you just can't screw up because people may die if you do.
Based on my experience with writing and debugging a little over a thousand lines of code (so not a lot), I'm very impressed -- it's surprisingly good. I'd suggest giving it consideration if/when the opportunity presents itself.
I downvoted because I'm interested in charitable, non-disparaging conversation. I post this so the above commenter doesn't confuse a downvote (1 bit of information) as validation of their claim. I'm personally uninterested in spending much time looking at Zig right now, but I'm keeping an eye on it and generally interested in the progression of languages over time.
reply