I really like this, I think I'd find it useful fairly often and I like the idea of just making something that I use irregularly but not that rarely a bit better.
But then I found it's in C#. And apparently the CLI app isn't even published any more (apparently nobody wanted it? Surprises me but ok). Anyway, I don't think I want this enough to install .NET to get it, so that's that. But I'd have liked a version in Go or Rust or whatever.
I'm the maintainer of FracturedJson. The decision to stop publishing a binary for the CLI version was made a long time ago: fewer features, fewer users, less mature .NET tooling (as far as I knew). And as you say, .NET isn't a common language for distributing CLI tools.
I plan to take a new look at that when I have the time. But a port to a more CLI-friendly platform could probably do a better job.
I think yes? I fairly often find that I have something in JSON, which probably is from some system to system comms, and I'm trying to read it. Once it's not trivially small I often pipe it through jq or python -m json.tool or whatever, I like the idea of something that just does a better job of that.
I don't think uv makes distribution simple? Unless I've missed something, it doesn't do anything out of the box to help you produce a standalone artifact - it builds wheels but those are only useful for a user that already has python and pip, and don't do anything to deal with Python version drift etc.
uv can install a version of python of your choosing in addition to pulling the specific versions of libraries specified in your lockfile. it's extremely dummy-resistant.
Right, but that means the end user has to have (or install) uv, and then you ship them all your code, and then they can use uv to run that. That's a development workflow - and exactly what I meant when I said that uv didn't solve distribution in the way a language like Go or Rust does by producing a single binary.
Why? It's not well suited to it - fundamentally the language semantics lead to very large distributions, slow startup and expecting a runtime on the machine. Okay, I hear this can be solved by Graal, but that's a whole piece of its own complexity that you'd never have to worry about with a tool written in something like Go.
Python has many similar properties, but at least there I can understand that Python is a 'pretty' language to write things in. Java has never been something that I have ever wanted to choose, and far, far less so when there's a big hill to climb like this.
I guess I fundamentally disagree with all the statements in the article like "This needs to change". I don't think it does. I would much rather than people wrote CLIs in Go or Rust than Java, 100% of the time the latter has been more painful for me to consume.
Regarding slow startups, I am not sure this applies to any use cases I can think of where it would not also be a concern in python, etc. JVM startup times have never meaningfully impacted my workflow in the last 15 years.
The why is quite simple, in my opinion. I see java devs reaching for other accepted tools for such things and opening a whole can of worms by introducing a new language that is only "required" by convention. I would love a rich java ecosystem of TUI/CLI libraries to reuse all of my existing business logic and company libraries. The lack of extremely streamlined wrappers is the only barrier. In my work environment, this would be a great addition.
Right, as I said I also think Python has similar issues with startup time.
I've used a limited amount of Java CLIs, the most obvious ones are things like Gradle which never felt snappy to use - it is annoying when even doing basic things takes 2+ seconds. I guess not the end of the world, but that seems suboptimal to me compared to a system that feels fast to use and hence well engineered.
Its not necessarily fair to use past experience with programming languages that have been seeing major updates year over year. Java as a command line environment has been pretty painless for me, particularly Saxon. Just need to alias the command to include a path to the jre binary.
Python has been much more painful :) no shade on go, of course having a binary built for your system is the most painless.
He might not since it comes via a friend. Or he's forgotten since.
Also seems not unreasonable for an employee like him not to specifically name and shame hardware partners. Maybe it'd all be fine, but I wouldn't blame him at all for not wanting to risk it.
> PyPy doesn't do anything to help startup time. In fact, it's typically a bit slower to start up than CPython.
Considerably slower on my machine. Yes, that was my point. If the community doesn't care about startup time, you'd expect more adoption of an implementation that sacrifices that startup time for later performance.
> Linux systems commonly already provide an outdated system Python you don’t want to use
They can be a bit long in the tooth, yes, but from past experience another Python version I don't want to use is anything ending in .0, so I can cope with them being a little older.
That's in quite a bit of contrast to something like Go, where I will happily update on the day a new version comes out. Some care is still needed - they allow security changes particularly to be breaking, but at least those tend to be deliberate changes.
This doesn't sound like the kind of portability anyone is really worried about. I get that the docs on the linked site are written in standards-ese and are complicated by macro replacement, but I don't think the outcome of sending your credit card details away is gonna be an outcome. If it was, an uncharitable implementation with access to your card details would be free to do that any time you gave it input invoking undefined behaviour (which is of course not uncommon, especially in incorrect code).
which makes me consider an interesting distinction, undefined behavior refers to the behavior of the compiler output, does the C standard "allow" compilers to do compile-time code executions with undefined behavior? is the runtime behavior of the compiler even in scope for the standard in general?
You can also do it using ld - it's something like ld -r --format binary -o out.o <file>, although you do want some build system assistance to generate header files allowing you to access the thing (somewhat similar to the assembly example here). It's a bit of a performance but I strongly prefer it to generating header files in the earlier options - those header files can end up being _very_ large (they generally multiply up the size of the embedded file by 2-4x) and slow to compile.
All a bit less relevant now since recent C++ versions have this built in by default. Generally something languages have been IMO too slow on (e.g. Go picked this up four or so years ago, after a bunch of less nice home-grown alternatives), it's actually just really useful to make things work in the real world, especially for languages that you can distribute as single-file binaries (which IMO should be all of them, but sadly it's not always).
But then I found it's in C#. And apparently the CLI app isn't even published any more (apparently nobody wanted it? Surprises me but ok). Anyway, I don't think I want this enough to install .NET to get it, so that's that. But I'd have liked a version in Go or Rust or whatever.
reply