after using the mikrotik scripting language I wonder why Mikrotik holds on to this archaic and painful language. It is widely known that there are small and useful alternatives like LUA or Micropython. I saw that LUA was supported in some Betas and then again dropped in some 4.X release. Is there anybody with more insights into this topic and could explain why in 2023 we seem to be stuck in the 80s with what we get for scripting? Having TCL on the Cisco back in the days was more comfortable than what we have here. And even if there needs to backward compatibility there seems to be enough flash in all newer devices with 7.x to have LUA or Micropython as an alternative.
You’re talking to a guy who bought his first Mikrotik specifically because I loved the idea of Lua being integrated with config. But since they didn’t update their web pages, the unit I got didn’t support Lua anymore…but totally unclear if your just read the wiki/webpage.
But I personally find the current scripting language one the greatest assets of RouterOS. It completely integrated with config scheme, which is a set of tables that you manipulate it. If you knew functional programming like LISP etc, their language makes a lot more sense. That just do go all the way, and left things at 80% done, like a lot of the other features.
So agree it’s missing a few functions to make it more “user friendly” – no argument – but add some and fix it! You’d have to change how all CLI works for some newer scripting language, and it that may come out worse (see the new BGP scripting language). It hard to both be a good script language and also have a good REPL at same time (see JavaScript).
And, I think the container so this need today – use what ever language. Most modern languages have a library for both REST and API & unless you explain how you’d doing normal CLI config with micropython or Lua, I’m skeptical.
What is about the current scheme that is so limiting that requires wholesale replacement, vs add some missing functions (like JSON, unicode)? How are you sure it wouldn’t be worse…
Add few built-in functions for convenience, find a way to provide more feedback on errors than silent death, and I’ll be willing to say that it’s ok.
The problem with containers is that they are not supported on all architectures and especially switches that lack enough ram and flash.
I tried to implement a mechanism where mikrotik network devices are deployed with a set of tools that allow them to connect to a central controller, look for its config, apply what is given (in this case json data) and apply this to the local device. The controller supports many more platforms than mikrotik so staying with a provider independent format (json) was a given requirement. When trying to implement a robust solution the current scripting language really showed - at least for me - that the lack of sane error handling, the way functions and variable handling is done, the data structures available, … just make this potentially simple task very hard. That said writing the same code in python or lua is a really fast, save and pleasant experience. But YMMV/
I think folks forget some of these devices have very low memory/disks, which makes adding stuff tricky. And there is no busybox under-the-covers to even expose. busybox assumes the underlying files/system is exposed, which hasn’t been Mikrotik’s philosophy to allow. Kinda think if managing the underlying OS is what you want to do, flashing OpenWRT seems like a better approach…than trying to make RouterOS more like OpenWRT.
NOW if you asking if Mikrotik should map more of the POSIX/“busybox” into RouterOS equivalents, different question. And think some progress on the multiyear request list for more built-ins function into the scripting language would go a long way to making the scripting better, than replacing it.
Proper support for functions would be greatly appreciated. I could not get the current “variable calling” to work with nested “function calls”.
I have seen devices 100 times more primitive running Lua. Of course it is easy to say “just add bindings”, but well… Even the task of filtering simple ip lists becomes a North Pole expedition on Routeros, it should not be so.
This cannot go on indefinitely. Devices with only 16MB of storage should not hinder the evolution of RouterOS. Decisions made in 2015 should not stand in the way of further development.
I would gladly give up 100 to 150 KiB of my flash for the LUA interpreter. In exchange, you can move SMB entirely into the ROSE package.
