this makes me want to move to a haskell (or any hard fp language) shop in 2026..
I've been using Haskell professionally for the last 5 years, I definitely hope I can continue!
Readit Newskephasp commented on Functional programming and reliability: ADTs, safety, critical infrastructure blog.rastrian.dev/post/wh... · Posted by u/rastrian
Db access in rust typically needs some sort of handle and a mutex. Limiting access to the handle makes the rest of the code pure with respect to the db. The handle plays a similar role to the IO type.
Actor-like patterns makes this nice. Message-objects can be passed to/from a module with db-access or other io.
How can you prevent code from creating a handle in a new place?
kephasp commented on Algebraic Effects in Practice with Flix relax.software/blog/flix-... · Posted by u/appliku
I really want effects to shine and thrive, but since this is a very academic topic, only academic people engage with the research and it comes with academic pedantism, perfectionist worldview, strange attraction to beautiful consistency, etc. This automatically places effect research FAR from any practicality and grounded realism. 2 points, as examples:
1. Ever tried adding a simple print statement for debugging purposes while coding in effectful lang? compiler: "NNNOOOOO!!!! THIS IS AN ERROR; I WILL NEVER COMPILE THIS NONSENSE YOU __MUST__ SPECIFY CONSOLE EFFECT WAAARGHH!11"
2. multi-resumable stacks. how many times you really want to implement custom backtracking for multi resumable computations? this is such an obscure nonsensical use case that is hard to nearly impossible to solve efficiently, but everyone wants to support it. supporting this adds enormous complexity and kills any potential for performance. WHYYYYYYYYY. and yet they focus on this as a holy grail feature but whever there is a showcase they use synthetic "choice" example, lol.
Resumable code is extremely helpful and I'm pretty sure you're describing a chicken and egg issue: if resumable code was readily available in general, people would use it a lot more and it would look like a very normal tool that is often the best.
But when it's only a feature available in niche languages or many languages make it unsafe or unreliable, then very few people will get to the point where it naturally pops up in their mind as a solution to their problem.
kephasp commented on Algebraic Effects in Practice with Flix relax.software/blog/flix-... · Posted by u/appliku
putting strong static type system into optional compiler pass. yes, I know this may be null is some cases, let me run my program for now, I know what I am doing. yes, there are unhandled effects or wrong signature, just let me run my test. yes, that type is too generic, i will fix it later, let me run my god damn program.
This is basically what we already have in Haskell. Debug functions that sidestep the typing system can be annotated with a warning and you can make this one an error while compiling for production.
And in a more general sense, you can ask the compiler to forbid escape hatches altogether.
We already have a pragmatic, reliable solution.
kephasp commented on Algebraic Effects in Practice with Flix relax.software/blog/flix-... · Posted by u/appliku
I think it is a cool feature, but I see some practical issues.
For me, encapsulation is a feature. I would like to see that a function uses a network call deep down, but only in a static analysis sort of way. So I don't want to mark something as potentially using a network until it actually uses it. And at the same time I wouldn't want to change every effect of every intermediate function just because I made something use an LLM or Redis cache.
It also seems that cross-cutting components such as observability instruments are just going to contaminate all functions with their need for memory, network, io, files, clock, locale, reflection, etc.
First, you can write a function that's generic on the effects used, so you could write use it in a way that calls an LLM and use it elsewhere in a way that cannot, with the same logic.
But I see the need to change the code as a good thing when it is necessary: I don't want a dependency, inside or outside my codebase, to suddenly add network calls without me knowing it. Same goes for code that was pure and has become stateful. Not knowing this kind of fundamental change is a recipe for a nightmare.
It should be especially apparent with the recent supply chain attacks.
kephasp commented on Copilot broke audit logs, but Microsoft won't tell customers pistachioapp.com/blog/cop... · Posted by u/Sayrus
"would be required on a per user basis or track the access rights along with the content, which is infeasible and does not scale"
Citation needed.
Most enterprise (homegrown or not) search engine products have to do this, and have been able to do it effectively at scale, for decades at this point.
This is a very well known and well-solved problem, and the solutions are very directly applicable to the products you list.
It is, as they say, a simple matter of implementation - if they don't offer it, it's because they haven't had the engineering time and/or customer need to do it.
Not because it doesn't scale.
Do you know papers or technical reports that demonstrate the scalability of authorization-preserving search indexes?
I don't doubt they exist but what we hear about are the opposite cases, where this was obviously not implemented and sensitive data was leaked.
kephasp commented on Copilot broke audit logs, but Microsoft won't tell customers pistachioapp.com/blog/cop... · Posted by u/Sayrus
I am assigned to develop a company internal chatbot that accesses confidential documents and I am having a really hard time communicating this problem to executives:
As long as not ALL the data the agent hat access too is checked against the rights of the current user placing the request, there WILL be ways to leak data. This means Vector databases, Search Indexes or fancy "AI Search Databases" would be required on a per user basis or track the access rights along with the content, which is infeasible and does not scale.
And as access rights are complex and can change at any given moment, that would still be prone to race conditions.
One typical way to resolve this is to use Voluntary Oblivious Compliance (VOC). In this capability-based pattern, every storage service could provide an opaque handler to a user that represents their authorization and it can be used to restrict on which documents indexing is done.
http://wiki.erights.org/wiki/Walnut/Secure_Distributed_Compu...
http://www.skyhunter.com/marcs/ewalnut.html#proofOfPurchase
If the opaque handle is part of the Membrane pattern, you can even avoid most race conditions, because even during the indexing, the capabilities can be used to access documents and that removes the possibility of a TOCTOU race.
http://wiki.erights.org/wiki/Walnut/Secure_Distributed_Compu...
kephasp commented on Functional Programming – How and Why onsclom.bearblog.dev/func... · Posted by u/onsclom
I was trying to evaluate FP one time, try to get it, but I can't envision using it in a pretty complex front-end where many things inter-depend on each other. With imperative programming I can easily step through the code and reason about the flow of execution, looking at FP, I can't help but think the codebase would become very hard to reason about and extend. Side effects are inevitable so if you are going to have side effects in a monad, what's the point anyway, one way or another you have side effects. Unit tests may be easier, but it's still trivial to do mocks. Mutability? I'm using a custom map type for global state entities that helps me deal with it and I'm also very mindful whenever I assign anything to an object property (in JS).
I respect FP, but I don't envision using it personally, and by the way, I don't get how OOP is getting bashed on HN so much. Like google FP + HackerNews and there are articles about FP like this one, google OOP + HN and you get "OOP is not just bad, it's super-duper-hyper-ultra atrocious".
My team builds frontends in Elm and backends in Haskell and we experience the opposite: FP made the code very easy to reason about and plugging things together is easy too.
Will be quite an interesting turn of events if a video game engine can be a driver in promoting functional language adoption.
John Carmack is already advocating for the use of Haskell for video games.
kephasp commented on Why study functional programming? (2012) acm.wustl.edu/functional/... · Posted by u/arkj
Searching wide and far for a data structure that's that niche in implementation is not really sensible, I'd probably have to implement one myself. If the sketch above doesn't satisfy you, that's about the end for me. Have a good one.
You need to sketch it and possibly implement it yourself because actual examples don't exist. QED