lua-languages VS pylance-release

This post inspired me to look for an ML-like language that compiles to lua and I found this useful list: https://github.com/hengestone/lua-languages

There's a complete list of languages that compile to Lua available here: https://github.com/hengestone/lua-languages

There are a ton of different ways to do this but you haven't given enough information to give useful advice. What kind of language do you want to make? "as a module of smth else" doesn't really mean anything. https://github.com/hengestone/lua-languages

There's also gpanders/nvim-moonwalker, which advertises Fennel in it's readme but works for any x->lua language you return the lua code for, ie: teal, moonscript, uh... others?

I went on a several-weeks-long fact finding mission (the longest of its kind I've ever done in my 10 years as a professional software developer).

The option that won was to write all business logic (a few thousand lines of code) in Lua, then write the GUI in each platform's native language+ui-library combination and re-use the same business logic by embedding Lua.

Another option that made the shortlist was using Haxe instead of Lua, but after several weeks, it became clear that that was a bad idea, and with Lua, the developer experience is now so much better.

I definitely plan on continuing to use Lua as my main programming language.

This comes after 20 years of having python as my main programming language because I'm displeased with feature creep and bloat on python. With lua, I find that I barely miss any features/abilities from the vastly more complex python while the simplicity of lua means my code gets to "go places" where python can't go.

With lua, you find casual implementers making fully compatible alternative implementations (e.g. NeoLua for C#, Luna for Java, fengari for JavaScript, ...) With Python, alternative implementations seemingly just can't keep up with the pace at which CPython is introducing unnecessary new features and CPython-compatbility is de-facto the only meaningful python standard there is. Jython and IronPython would make the platform so much more appealing, but they appear dead in the water. Python implementations for the browser pop up every couple of years only to quietly disappear again.

What's more: Once you've settled on Lua as am embedding language, developers of Lua logic are free to use not just Lua, but they can pick from a host of cool transpile-to-Lua languages [1].

[1] https://github.com/hengestone/lua-languages

However, there are many languages to which this doesn’t apply (before Fennel I’ve tried to write Minetest mods in Haxe without success).

Maybe most of them are also small projects, but there are a lot of projects that compile other languages to Lua: https://github.com/hengestone/lua-languages .

Doubtful, but there is TypescriptToLua: https://typescripttolua.github.io/

Here's a whole list of languages that compile to Lua (many of them statically typed): https://github.com/hengestone/lua-languages

That's just because there are lots of lua transpilers. https://github.com/hengestone/lua-languages

One of the things that comes to mind here is the fact that the default Python extension for VS Code is, perhaps surprisingly to many, not open source. https://github.com/microsoft/pylance-release

While it's possible to fork VS Code, it is not possible to fork VS Code and provide a seamless onramp towards a Python editing experience that is fully open source, because users are used to the nuances of the closed-source Pylance experience in VS Code proper. You could use the minified/compiled Pylance plugin in your fork, but you'd have no way to expand its capabilities to new hooks your fork provides. Microsoft's development process would always be able to move faster than a fork, because it could coordinate VS Code internal API development with its internal Pylance team, and could become incompatible with forks at any time.

It's worth re-reading the quote from J Allard in https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... with this modern example in mind.

(Also worth mentioning https://github.com/detachhead/basedpyright?tab=readme-ov-fil... which is a heroic effort to derisk this, but it's an uphill battle for sure!)

Anyone know how can we fix this issue if we build the vscode locally

Do any of these issue tickets explain the behaviour you're seeing? https://github.com/microsoft/pylance-release/issues/4341, https://github.com/microsoft/pylance-release/issues/4071

Maybe they "are the same thing" in terms of behavior (I don't know), but "A uses B" doesn't mean that "A is B".

One important difference in this case is that while "Pylance leverages Microsoft's open-source static type checking tool, Pyright" [1], Pylance itself is not open source. In fact, the license [2] restricts you to "use [...] the software only with [...] Microsoft products and services", which means that you are not allowed to use it with a non-Microsoft open source fork of VS Code, for example.

The license terms also say that by accepting the license, you agree that "The software may collect information about you and your use of the software, and send that to Microsoft" and that "You may opt-out of many of these scenarios, but not all".

[1] https://github.com/microsoft/pylance-release

[2] https://marketplace.visualstudio.com/items/ms-python.vscode-...

There's this one: https://github.com/microsoft/pylance-release/issues/4174 (rules don't apply properly, and ovverrides don't work even after being set, this is especially for the more generic ones like )

The example is not .NET in general, but that specific event when Microsoft reneged on open development tooling[1]. For some people, that was the moment they stopped trusting "new Microsoft" to keep their word (though for me, it was when the Python language server was replaced with a DRM-locked, LSP-noncompliant one[2] a bit before that; unlike .NET hot reload, they didn't backtrack there). I can think the company makes great open .NET tools and at the same time not trust them to close it down on a whim.

Does anyone know where the open xlang reimplementation of MIDL went[3], by the way? (Unlike 1990s MIDL, you can't reimplement this one from the language grammar in the docs, because there is no language grammar in the docs.)

[1] https://dusted.codes/can-we-trust-microsoft-with-open-source and links there

[2] https://github.com/microsoft/pylance-release/issues

[3] https://github.com/microsoft/xlang/pull/529