I have this same dream wayyy too often (uunfortunately).

- A language that transpiles down to human readable, idiomatic Go.

- Automatic folding of normal Go code into more concise/functional-style syntax.

- Proper preservation of where every folded token came from for byte-perfect reconstruction of the original code. (Probably involving something like a lockfile).

- On-demand transpilation during VCS checkout, or transpilation can happen directly in your IDE during file load/save.

I think as long as some tricks are done, the in-IDE transpilation could even let you reuse all the existing Go syntax highlighting and autocompletion IDE infra.

I started working on an IDE plugin to prototype transpilation "Go -> new lang". The plugin would replace Go code using IDE "code-folds" so it effectively didn't exist and wouldn't impact autocomplete/highlighting. And then you could use IDE snippets that expand to Go code to "pretend" you were writing in the new language.

But unfortunately, I have too many other wild dreams in my head so it never went anywhere.

> Proper preservation of where every folded token came from for byte-perfect reconstruction of the original code.

I wonder if you could cheat by insisting the original code must have been run through an opinionated formatter so there's a One True Represenation of the source and you can restrict the problem to byte-perfect reconstruction of -that-?

(I have the same dream too sometimes and keep wondering if that would, at least, be a more tractable goal for a version 0.1 if I ever get a round tuit)

That is a really intriguing idea! Not sure if Go has exactly the sort of tool you are talking about, `go fmt` still allows for some minor differences, and I believe the same applies to `gofumpt` as well.

But it still sounds totally doable!

Right, even the most opinionated of modern formatters don't go quite that far.

The only thing I can think of that did is the Interlisp-D editing functionality provided by Interlisp Medley, where your code was stored within the system as parsed S-expr trees and when you opened an editor onto something it reverse engineered a textual expression of the thing according to your configuration.

Tagging every, single, node, with enough data to recreate the indentation and formatting seems theoretically doable, and if you're wanting to let people edit things that are, say, config file shaped, then you're going to have to do that if you want the resulting commit diffs to be sufficiently coherent that people will be willing to use it.

But taking the Medley approach for a first attempt/first release feels a lot more doable, and given the biggest obstacle to such a thing is almost certainly congruent to "being able to make a start over a weekend for the sheer fun of it" I think it's well worth considering :D

> but when pushing to git it would get transpiled to the most common subset.

What about the other direction? I don't think it will be very useful to not be able to read the exact code you wrote after the fact. Feels like writing a book but every sentence you enter is instantly rephrased by ChatGPT to sound more convoluted.

I was assuming that each contributor would have their custom rules on what the code looks in their editors. I agree that we should have a different solution so everyone reads the exact code they wrote in the style and format they wrote it...; Scratch all that, the more I think about it that sounds like a very bad idea, what about pair programming, collaboration, being able to talk about some parts of the code or it's design? Back to Go and Rust for me :)

> when pushing to git it would get transpiled to the most common subset.

That would mean pulling from git would get you code that’s harder to read than what you pushed (if that’s not the case, you wouldn’t have used that transpiler)

There also isn’t agreement on the common subset.

For example, scala has lazy sequences, Rust wants programmers to have control over memory deallocation, go (sort-of) requires threads to have small stacks, Swift has copy-on-write collections, python’s numbers automatically become bignums, many languages really need efficient boxing to have efficient implementations, etc.

Strip all that, and you end up with WASM (or, possibly, even something even smaller), and various language ecosystems would build libraries on top of that that are incompatible with each other (possibly sometimes in non-obvious ways, leading to hard to detect bugs)

This is almost what editing Java in IntelliJ is like. The most verbose multi line constructs are minified to only appear as one line on your screen.