3 ms·
I don't think the impediment to adoption is the syntax - that's straightforward enough - it's the ecosystem / tooling / network effects. I love this, even thou
by Philpax 2y ago
I don't think the impediment to adoption is the syntax - that's straightforward enough - it's the ecosystem / tooling / network effects.
I love this, even though I don't interact with Go on a regular basis, but I recognise that I'd be locking myself out of a lot of the standard Go tooling if I adopted this wholesale. For better or for worse, there's a high ecosystem barrier that most languages must overcome to be adopted, and the vast majority of efforts never get to that.
- nine_k 2y agoWhat standard tooling would fail, given that the translation goes via a a generated Go source? I suppose there must be some borgofmt that handles the particular syntax. Certainly debuggers would have to be updated to show the corresponding Borgo code line at least. What else?
- autarch 2y ago> What else? Any and all linters for Go, to start. In theory, you could run them on the transpiled source, but the results would be very hard to apply to the original Borgo code. And they'd probably produce lots of false positives for things that the Borgo compile ensures are safe, even if they're not linting-correct. And syntax highlighting, refactoring tools, an LSP server. I'm sure there are more things along these lines I'm failing to think of.
- lmm 2y agoIDEs, profilers, instrumentation agents, code coverage tools... essentially any tooling really.