Languages
C.
Frameworks
C.
That said, Python and Rust are great for setting up "starting up" / "small task" apps and growing up from there.
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
Languages
C.
Frameworks
C.
That said, Python and Rust are great for setting up "starting up" / "small task" apps and growing up from there.
There's nothing to really grow. It's mostly just small helpers. Aggregate sensor data, pull data from A and push it to B every hour, a small dashboard, etc.
C is too involved for my case , I want to be productive after all.
Rust is already rather low level, though there are some cool looking frameworks.
If you've so far been able to do this stuff in Java, then presumably all your hardware has an OS and such and you don't need this, but a colleague has been having a lot of fun with Rust and proper embedded development.
It's very different from regular development, as you've got no OS, no filesystem, no memory allocations, no logging. It can most definitely be a pain.
But the guy always has the biggest grin on his face when he tells that he made a custom implementation of the CAN protocol (TCP is too complex for embedded 🙃) and that he had to integrate an LED to output error information and stuff like that. At the very least, it seems to be a lot less abstract, as you're working directly with the hardware.
Go, you get small static binary, easy to code, and good performance.
If you want something with a small footprint I would personally go for Rust, but anything that compiles to a static binary is going to be better than something that needs a dedicated runtime.
Python is what I use for small one-time scripts and utility stuff that doesn't need to run long, but it may be worse than Java..
Go is quite nice for this, generally low traffic services are less than 100mb used memory if you're using the standard lib stuff and it's not a huge jump from the JVM to Go.
Scala compiles either to native, js or jvm - obviously the IO / interface options vary between these envs, but the lang is the same. Recently Scala 3.5 incorporates a simple-to-use CLI which makes it easier to compile to native (or just run a small file as a script, or experiment with a repl), native binaries are small and fast, and there are some simple io libraries. Since you can also compile to jvm to interop with java, that might help with transition.
But that would mean either using Graal/native image or going full Scala, right?
I only used Scala for Gatling, where it's obviously very java-y.
Indeed to use scala-native you'd need pure-scala libraries, but the core lib re-implements most java lib, and there are now small simple external libs available for common tasks like file management, database, etc. - for example check out the lihaoyi suite.
I mainly use scala-js (to make this) which was formerly a java app - as it compiles to both js and jvm (cross-project) can gradually convert stuff you already wrote. I've tried native for stuff like pre-processing data files.
Other couple ideas to consider if job ambitions aren't a major thought:
Nim-lang / Mummy. Neat in being high level like python but compiled and can do low level stuff. Small ecosystem but good interoperability with c and Python. Can also compile to js. Target embedded to web, very flexible.
Also php. Some people say modern php looks more like java. Either way, lots faster than it used to be. Wildly productive language for web stuff. Laravel or Symfony frameworks.
MicroPython is good for limited hardware projects.
Not that limited. Limited means an old thin client, not a microcontroller. I already set up a small web server on a pi pico with mpy, so it's quite impressive. But from what I understand, the interop with "MacroPython" is not that great.
Did you use mpy for x86 devices? Are the limitations worth it?
I feel like in a lot of ways, most languages are great candidates for this, for lots of different reasons!
Buuuuut, Rust's compilation can be pretty resource intensive, so if you're actually developing on limited hardware:
Then there's the fact that it's a home server, so always on, meaning you actually have generous resources in some ways, because any available CPU is kinda just there to use so:
And then why not go whole hog into the world of experimental languages:
And then we're forgetting about:
But that doesn't factor in:
Plus:
Edit: My actual serious answer is that Rust + Rocket would be great fun if you're interested in learning something new, and you'd get very optimised code. If you just want it to use less memory that java and don't want to spend too much time learning new things then python is probably fine and very quick to learn. Go is a nice halfway point.
Hmm, I've never looked too much at benchmarks for this, but is there reason to believe Python would use less memory for a similarly complex project? It still needs a runtime, and it has to do a larger interpretation step at runtime (i.e. it needs to start from human-readable code rather than from bytecode)...
Python caches bytecode, so the translation happens only once.
Java loads everything immediately and keeps it in memory. All beans, all connections, etc. That takes up a ton of memory.
Python / FastAPI will be better than Java in your situation and is easy to learn. Go should be even better and is also relatively easy to learn!
Have you tried tuning your jvm settings? 200mb is a lot for a simple app. You can get that pretty dang low just by proper tuning of jvm settings.
Go will be easy enough to get the job done, then you will have plenty of time rewrite it with whatever language you like.
That's at least my case. I have a cloud server that hosts a few services for news, weather, LLM client, etc.. Most of them, if not all, took me just 2-3 hours to get it up and running, and a couple hours more the following day to fine tune. Now I have a working service and I can move on to rewrite it in (in my case) Rust as a learning opportunity.