this post was submitted on 29 Jan 2026
37 points (97.4% liked)

Programming

25079 readers
222 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

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 2 years ago
MODERATORS
 

I hear they are good, make it easier to maintain code-bases. Most often I reach for python to get the job done. Does anyone have experiences with functional languages for larger projects?

In particular I am interested to learn more on how to handle databases, and writing to them and what patterns they come up with. Is a database handle you can write to not ... basically mutable state, the arch-nemesis of functional languages?

Are functional languages only useful with an imperative shell?

you are viewing a single comment's thread
view the rest of the comments
[–] dneaves@lemmy.world 5 points 5 days ago

To answer the headline: Functional languages are as useful in pretty much any context non-functional ones are, they just need to be handled a little different.

Functional languages' goal tend to lean towards static or predictable typing and reduction of clandestine mutable state changes. State has to change in a program, it's just about how its handled, and this is more about reducing referential update behavior.

Like in Python, you can have a list, pass that to a function that returns None, but deep inside that function appends to the list, and you may be surprised that your list is different as a result. This would (typically) not happen in an FP language, you would have to explicitly return the changed list up the stack of functions, and as a dev you could see from a glance that the list could change as a result of the function, leading to less surprises.

"IO" is of course an outlier, as it's leaving the safety bubble the language provided. I could read the same database row twice in 60 seconds and get a different result, because someone else could make a transaction in that time. But once I have read the row and parsed it into a data-model, I can expect that my model in-code won't change unless I tell it to.