Programming

17476 readers

194 users here now

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 programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 1 year ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

What languages/frameworks for small, very low usage apps on limited hardware? (self.programming)

submitted 2 months ago by leisesprecher to c/programming@programming.dev

31 comments fedilink hide all child comments

I have a small homelab running a few services, some written by myself for small tasks - so the load is basically just me a few times a day.

Now, I'm a Java developer during the day, so I'm relatively productive with it and used some of these apps as learning opportunities (balls to my own wall overengineering to try out a new framework or something).

Problem is, each app uses something like 200mb of memory while doing next to nothing. That seems excessive. Native images dropped that to ~70mb, but that needs a bunch of resources to build.

So my question is, what is you go-to for such cases?

My current candidates are Python/FastAPI, Rust and Elixir, but I'm open for anything at this point - even if it's just for learning new languages.

you are viewing a single comment's thread
view the rest of the comments

[–] leisesprecher 9 points 2 months ago (2 children)

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.

[–] xmunk@sh.itjust.works 5 points 2 months ago (2 children)

C is an extremely expressive language. There's a reason it won't die and, while we all love to shit on it for the memes, you can write perfectly safe software in it.

[–] leisesprecher 15 points 2 months ago (3 children)

Of course, but I'm not productive in it.

If I have to do everything myself, it will take more time to get it done. The trade-off is of course always control/speed vs convenience, but C is definitely too inconvenient for me.

[–] xmunk@sh.itjust.works 3 points 2 months ago

That's fair enough.

[–] mysteryname101@lemmy.world 2 points 2 months ago

I’d lean towards C# with AOT compilation if you’re not using reflection, you should be ok.

[–] lambalicious@lemmy.sdf.org 2 points 2 months ago

Yeah definitively sounds like even more support for Rust and/or Python in this sense.

[–] FizzyOrange@programming.dev 8 points 2 months ago

you can write perfectly safe software in it.

In the same way that you can safely walk through a minefield.

I dunno what you mean about it being an expressive language either. I would say it is relatively low on the expressiveness scale compared to something like Python or OCaml. It's basically as expensive as Go which is renowned for being unexpressive. Maybe you didn't mean "expressive".

[–] Ephera@lemmy.ml 3 points 2 months ago

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.