-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
> On these programs, the overhead is usually somewhere around 2-3x.
Nice!
> It's also possible that the way I'm compiling things down to Racket is defeating optimizations, but I haven't yet dug in.
Part of the secret of the reimplementation Racket on top of Chez Scheme is that there are many macros pretending to be functions. The optimization pass inlines some of the functions, but sometimes the heuristic is not good enough, and you must cheat using a macro. (And sometimes the "obvious" improvements are wrong, and using a macro to force the expansion of the code has a worse result.)
For example in https://github.com/Bogdanp/racket-lua/blob/master/lua-lib/pr... I'd try using a macro to inline the fast case where both numbers are exact integers, and then call a real function for the slow cases. (Is it common that someone wants to use 7.0 to do bit operations? Perhaps it's better to inline more. That's the tricky part, understanding which is the best split. I'm not sure. Probably only Matthew knows.)
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
Haxe is great for when you want to write an entire application in Haxe, then transpile to multiple targets, and then care about the target platform only to the extent that you want your application to just work.
The various haxe game engines are a good example of this kind of use case, where they transpile your haxe code to C++ or JavaScript and then your transpiled code combines with JavaScript code that the game engine provides or with C++ code that the game engine provides and the result is that everything "just works", both natively and in the browser.
I also have high hopes for this approach in relation to GUI programming (HaxeUI, FeathersUI, etc. are very interesting).
But my usecase was different: I wanted to make an API for my business logic that would transpile to Python, JavaScript and Java, and give a developer on each target platform a native look and feel, as if they were interacting with a native Python API or Java API, etc.
Basically, when you do that, you'll discover that Haxe is too much of a leaky abstraction.
For example when your API requires passing an iterator over Strings or returns an iterator over Strings, you'll discover that this doesn't automagically turn into java.util.Iterator when you transpile to Java. Rather Haxe has its own implementation (haxe.Iterator) that transpiles to some weird Java object that a Java developer will have a difficult time interacting with. ...this is true not just for iterators but for a lot of very basic things like collections, exceptions, etc.
Haxe does expose target-specific things on the Haxe-side, so you can write Haxe code that will accept java.util.Iterator or return java.util.Iterator, but, obviously, java.util.Iterator will not be available when you try to transpile to something other than Java. So whenever you want to just use an iterator, your code is going to be full of "if this platform then behave like x, if that platform then behave like y, ..."
Outside of development around the main Haxe-based game engines, you'll also find that the community is just too thin to properly maintain standard libraries. For example, several libraries that implement very basic things haven't been touched in years and I discovered that the HashMap implementation in the Haxe standard library is just broken and no one seems to care or notice. It just doesn't handle collisions [1]. ...the only way I can explain that to myself is by assuming that nobody on Haxe really uses HashMaps because the game engines provide something else that displaces that functionality or that games are just the kinds of applications where the errors that result from hash collisions aren't noticeable.
It's a pity, because the Haxe language is great, and the ideas behind the architecture are great, but the current implementation just hasn't yet made enough progress on the journey it embarked upon.
[1] https://github.com/HaxeFoundation/haxe/blob/development/std/...
I've had some success with https://github.com/TypeScriptToLua/TypeScriptToLua
Luau may be an alternative as well, haven't tried it.
I love Lua, but at larger scales it's unmanageable.
I think your reasoning makes total sense and agree with the criticisms of the JS ecosystem. Just to throw out an alternative embedded-JS option for you or anyone else looking to do something similar though, there’s QuickJS from Fabrice Bellard (author of ffmpeg and more) which seems to have a very Lua-like vibe to it in terms of intended use.
Only used it for throwaway/toy code myself, but it’s been a generally pleasant and frictionless experience.
https://bellard.org/quickjs/
I want to like Teal, but the lack of nil checks[1] is a pretty big sacrifice in the name of "staying true to Lua idioms".
>>> Every type in Teal accepts nil as a valid value, even if, like in Lua, attempting to use it with some operations would cause a runtime error, so be aware!
I know you can use (or implement your own in about 8 lines) strict mode, but that just seems like such a shame to omit nil checks from a gradual type system. I still follow the project, but I put a little more hope in Pallene's[2] development, although the aims are slightly different.
[1]: https://github.com/teal-language/tl/blob/master/docs/tutoria...
[2]: https://github.com/pallene-lang/pallene
