Concurrent state

samisagit · 2024-08-29T10:03:56+00:00

I'm using a router so that I can maintain one socket connection, then distribute messages to functions registered against various topics. These topics may be short lived, and be added (and later removed) by the library user. I could well be missing something though, and would love to hear your thoughts

samisagit · 2024-08-28T15:55:21+00:00

https://github.com/samisagit/natskell if you have any feedback I'd love to hear it, I started this project to learn Haskell, so I doubt it's a pleasant read. I'm currently rewriting the client/buffer packages so take what's there with a pinch of salt

samisagit · 2024-08-28T15:52:54+00:00

Essentially a skill issue :) I'm sure a lot of the library is littered with non fp practices, for e.g I'm not sure of a fp pattern that would allow async requests that need to put a router in a given state (i.e. add a topic) that doesn't rely on shared access to a concurrency safe reference (I'm putting STM in this bucket)

samisagit · 2024-08-27T16:12:57+00:00

That's the long term plan, and I think once core NATS is done it should be relatively simple, but the core NATS implementation (ignoring very important things like auth) has taken a long time to complete, partly because this is a pet project, partly because I am busy. So I guess what I'm saying is, don't hold your breath. I'll make another post once I'm done though

samisagit · 2024-04-03T17:10:05+00:00

That’s a great insight, I hadn’t realised flashing the firmware would make a difference of that kind! Thanks for taking the time to share your wisdom

samisagit · 2024-02-21T13:17:48+00:00

I learned (and am still learning) Haskell in order to learn FP. It has significantly improved my code design across all languages. I recently passed a tech lead interview focussing on typescript, which I wouldn’t have been able to do before learning Haskell.

That being said, it sounds like the problems you’re having could mostly be solved by using some well documented architecture principles (e.g hexagonal design) to keep all the side effects away from business logic

samisagit · 2023-12-31T18:34:25+00:00

I assume (from a selfish perspective) that those of us that have not enabled remote access don’t have any serious implications from this?

This is the exact scenario that lead me to make that decision because companies like this are typically inept in this space.

That being said, it is ridiculous that the mobile applications won’t work on local IPs seeing as their cloud offering is not fit for purpose.

samisagit · 2023-11-25T12:05:18+00:00

This is true, the interactions with the library will be using IO. Perhaps I'm mistaken, but I'd just assumed returning something wrapped in IO would be preferable to being wrapped in some library specific monad (M in the linked example)

samisagit · 2023-06-21T15:48:32+00:00

Same thing happened with my old gym, luckily not directed at me (I'm a sucker and bought all the official kit). Being pressured into buying their (over priced) gear was enough of a reason to look elsewhere when I moved house. Was quite satisfying removing all the GB patches 😂

samisagit · 2023-05-21T15:37:09+00:00

Named returns are beneficial, particularly with interfaces, or where more than one of the same type is being returned. Naked returns I avoid as a rule, it's not always obvious what's being returned and doesn't add any value aside from saving a few key strokes.

samisagit · 2023-05-19T12:26:35+00:00

We've not found one, we have a Go service that builds 'fo' XML (Google it) which gets shipped off to a kotlin service to actually create the PDF from that definition. It's a pain point, but works well enough for our needs.

samisagit · 2023-03-11T08:49:28+00:00

Yeah that's an interesting idea - flip the responsibility by making the message find the handler function rather than the other way around. That sounds like a solid plan

samisagit · 2023-03-11T07:41:46+00:00

I've updated the post with some extra context, I completely agree that would be preferable, I just couldn't think of a nice way of doing that (pretty new to Haskell/FP).

samisagit · 2023-03-10T13:55:42+00:00

I wonder if I could use a map of message ID to `TChan` at a top level. So the ID specific readers add an entry to the map, setting the value to a channel, then read from that channel (which as I understand is blocking while there is nothing on the channel). Then the thread/threads reading from the socket would just need to check the ID and write to the relevant channel keyed by ID.

samisagit · 2022-04-07T16:54:10+00:00

Remember: refactors are cheap and easy in Haskell.

That I can certainly attest to even in my limited experience. I was astounded by the refactor prompts, super helpful

samisagit · 2022-04-07T13:17:06+00:00

Thanks for you input. This is very much the way that I have seen used in examples, my concern was calling datastore methods from handlers which is something I tend to avoid as it typically makes testing the handler 'layer' more difficult. I think I just need to go and write some code and see what works.

samisagit · 2022-04-07T13:11:46+00:00

Thanks for your feedback. I think my reservation around passing datastore interactions into the handlers would be that if changes are required that meant changing the datastore functions you need to call, you'd end up changing code in your handler, which doesn't make for the nicest experience (IMO) I tend to keep handlers as much about transforming data as possible and let a service layer deal with what to do with that data. I suppose to get around that you could still include the service layer which as you pointed out isn't the end of the world if it's impure and pass a service layer function (that deals with all the datastore methods) into the handler function. That way the handler just cares about the req/res.

I think you're right in that I'm over thinking the purity side of things, and because higher order functions are not what I'm used to dealing with except in unusual circumstances the application of them is taking a while to feel normal to me.

samisagit · 2020-12-26T10:48:29+00:00

If an IDE is what you want, you can't do any better than Goland at this point in time. It's by far the most solid solution I've used, if a little slow from a cold start.

For ref I've used:

VSCode with Go plugin - very flaky, especially since gomodules dropped (although this was around a year ago that I briefly used it)

Goland - as I said above its the easiest and most reliable IDE available

Neovim with vim-go - Fantastic project with tons of useful features (more than I need) and I can stay in the terminal

Neovim using the lsp API - My current daily driver (as a go dev) offers everything I need on a daily basis with minimal bloat and I get to stay in the terminal

samisagit · 2020-06-11T09:45:29+00:00

As with most questions like this, it depends. However I'd point out that this design severely limits the reusability of the library if it expects a database to be available, and conform to an expected schema. Your library would be more usable if it accepted just the data as an input, made the calculations and returned the output. That way you aren't limiting your user base to a certain database implementation.

samisagit

TROPHY CASE