2 ms·

I get it's frustrating but ... do you expect any Lua to run in every environment Lua is used in? AFAICT no 2 Lua's are alike and nearly ever use of it has it's

I get it's frustrating but ... do you expect any Lua to run in every environment Lua is used in? AFAICT no 2 Lua's are alike and nearly ever use of it has it's own APIs and quirks. I have the same issue with C. You can find some C that will run anywhere. You can also find lots of C that is platform specific and unless you're an expert you'll be just as frustrated trying to get it to run on a different platform. Seems the same to me.

aeturnum 4y ago
> do you expect any Lua to run in every environment Lua is used in? I do not, but again - I think "I should be able to run any version of a language in any place" is not related to "it is strangely hard to run a given Javascript file." I actually think Lua is a great example for comparison that illustrates the point! Different Luas support different features, but the basics (import statements, etc) are syntactically valid (and singular) in all of them. If you try to import a library that doesn't exist in the version you've embedded, you will get an import error. In Javascript - there are multiple import systems for different ecosystems. Getting an import error might mean you need to install the library, it might mean you're using the wrong convention, it might mean that the version of the library has a compilation error....etc. Javascript does not really help you resolve this. What this means is that there's a clean separation between environment and language. If your Lua deploy supports all the features your script uses, you are good - there are no "families" of Lua script that use different conventions for importing libraries or interop or whatever. A given piece of Javascript, however, has an arbitrary number of deployment-specific setup actions that require pretty advanced ecosystem knowledge to identify. Like, look back at the errors listed in the article. There's nothing "wrong" with the restrictions, but the language ecosystem does an unusually bad job of helping you understand and navigate them. Like, you can have two or three different import mechanisms for different environments...but if you want to do that you should be more helpful in pointing out when you're using the wrong one.

aeturnum 4y ago

> do you expect any Lua to run in every environment Lua is used in? I do not, but again - I think "I should be able to run any version of a language in any place" is not related to "it is strangely hard to run a given Javascript file." I actually think Lua is a great example for comparison that illustrates the point! Different Luas support different features, but the basics (import statements, etc) are syntactically valid (and singular) in all of them. If you try to import a library that doesn't exist in the version you've embedded, you will get an import error. In Javascript - there are multiple import systems for different ecosystems. Getting an import error might mean you need to install the library, it might mean you're using the wrong convention, it might mean that the version of the library has a compilation error....etc. Javascript does not really help you resolve this. What this means is that there's a clean separation between environment and language. If your Lua deploy supports all the features your script uses, you are good - there are no "families" of Lua script that use different conventions for importing libraries or interop or whatever. A given piece of Javascript, however, has an arbitrary number of deployment-specific setup actions that require pretty advanced ecosystem knowledge to identify. Like, look back at the errors listed in the article. There's nothing "wrong" with the restrictions, but the language ecosystem does an unusually bad job of helping you understand and navigate them. Like, you can have two or three different import mechanisms for different environments...but if you want to do that you should be more helpful in pointing out when you're using the wrong one.