The author here. Marta doesn't perform any network activity besides update checks, which you can disable. If you wish, you can block all network access for the application in your firewall.
It seems that quite a lot of people use Lua.
I liked the language, it's tiny and well-made. However, I wasn't happy about the tooling support. IDE plugins, documentation generators, lint checkers – all of this seem abandoned.
Is there any similar language (embeddable, good C interoperability) with better tooling besides JavaScript?
If you want Lua under the hood, but a more industrial-strength language on top, you might have a look at Haxe. It can compile to Lua (among other languages/platforms).
The language looks really nice. I especially like its strong-typing nature. It seems, though, that it won't be easy to embed – Nim compiler requires either gcc or clang.
Well, I'm not a big fan of JavaScript :) I like the direction ECMAScript is going. However, the clumsy things are going to stay because of backward compatibility.
Also, QuickJS is a good initiative, but I afraid it's not production-ready yet. It doesn't even have versioning and/or changelog.
You can choose what parts of the standard library scripts allowed to use. Just exclude os/debug libraries, and that's it. Newer versions of the Programming in Lua book contain detailed instructions.
Lua 5.4 has a new feature called to-be-closed variables. It is intended to allow for deterministic freeing of resources, even in the face of possible runtime exceptions. (Sort of like RAII in C++).
The canonical example is that you can mark a variable holding a file handle as to-be-closed and then as soon as you exit the variable's scope the file gets automatically closed (including if exit early due to break, return, or error).
But what is supposed to happen if you are inside a coroutine and pause the execution before reaching the end of the scope, and never resume again? If there are any to-be-closed variables their destructors will never run! Or they might only run after the containing coroutine gets garbage collected, which is not a timely solution. To cover this situation, Lua 5.4 introduced a new coroutine.close function that kills a paused coroutine and runs the destructors of any to-be-closed variables inside it, if there were any.
Marta is not inspired by fman. The Action panel (I think it's called a Command palette in fman) is likely to be the only common thing between our products – and we both took it from Sublime Text. But it's not really important.
The "doesn't feel native" is not the main problem for me. I use a number of non-native apps (such as IJ IDEA) – and I'm okay with it.
fman is a just slow app without features. It was ok if it was in alpha stages, but why it is a paid product then? Come on, there's still no way to cancel the copy process! And you need to install a third-party plugin to swap panes. I wonder how you made such a small progress since the last year, considering that you work on fman full-time.
You're focused on "features". Given your limited time, that makes sense. But a successful project requires more. I have been working on many things that are less visible (besides the fact that I'm supporting three times as many platforms). This affects things like the number of plugins contributed by users (fman has 10x those of Marta). Or the activity on the issue tracker (compare fman's [1] with Marta's [2], where - except for the past 24 hours - virtually all issues are by you). You're right that fman can improve in terms of features and speed. It will. But those things are just the tip of the iceberg.
Well, until Swift introduces ABI compatibility, this is definitely a problem, as both Marta API and a plugin need to be built with the same version of Swift.
Depending on the Swift release roadmap, I'll postpone 1.0 until the release of Swift 5, or make the API ObjC-compatible.
I also have plans for making a "lightweight API" (possibly in Lua). It will support only the subset of features available in the "full API", but if that would be sufficient, nothing prevents it from becoming the "right" way of writing plugins for Marta. (In any case, Swift API won't disappear).
> both Marta API and a plugin need to be built with the same version of Swift
As far as I’m aware, this isn’t a problem, since your communicating between the two using the Objective-C runtime, which is resilient to the underlying ABI because it essentially overlays its own. The issue arises when you have two plugins with incompatible versions of Swift: in this case, each will load its own standard library, which will lead to conflicts since for any given function in the shared library one of the implementations has to “win out”. This will cause at least one of the plugins to be unable to interface with the standard library correctly.
