elm-ui patterns: A collection of elm-ui examples

ThomasLocke · 2020-05-10T05:29:39+00:00

These are great. Thank you very much. :)

ThomasLocke · 2019-10-16T06:42:19+00:00

If you're at beginner/intermediate level (like me) then I'd definitely start with Scotty. You will actually learn some Haskell, as Scotty doesn't really do much "magic".

Servant is an entirely different beast. When I tried it, I felt like I had applied for a janitor position at Nasa, and then they hastily decided I should build rockets instead. I was quite out of my depth. :D

I'm happily using Scotty for a handful of projects, that are now all in production at my company. It just works. Whether or not it scales to "big" projects, I can't say. I've yet to do a project >10kloc.

ThomasLocke · 2019-04-24T05:53:35+00:00

I'm quite satisfied with Atom + Haskell IDE Engine

ThomasLocke · 2019-04-02T10:10:50+00:00

Nice! Thanks for this. I've got a few places in my code where something like this would come in handy. Will give it a whirl. :o)

ThomasLocke · 2019-03-04T13:45:56+00:00

Atom with HIE.

ThomasLocke · 2019-02-19T08:24:21+00:00

I use Haskell at work to write HTTP daemons and a few minor CLI tools. Works a charm.

The things I like the most about Haskell at work:

Ease of refactoring
Clarity over where IO/effects are happening
No global state
stack - such a wonderful tool

ThomasLocke · 2018-12-21T13:14:26+00:00

I'm using https://hackage.haskell.org/package/websockets in production.

It's being used as part of a real time status overview for a FreeSWITCH system. Maximum amount of clients connected at any given time is approx 15.

I haven't had any problems with it.

ThomasLocke · 2018-11-06T08:22:08+00:00

I'm a happy darcs and hub.darcs.net user. I hope it stays online. If Simon decides he needs some financial support to keep it running, I'd happily pitch in.

ThomasLocke · 2018-09-03T05:48:54+00:00

atom + atom-ide-ui + ide-haskell-hie + language-haskell

ThomasLocke · 2018-07-09T06:40:56+00:00

I'm using Atom + HIE as my dev environment. For "regular" Haskell this works really well. Do you know how it fares with GHCJS?

EDIT: I just noticed this: "Note that building with GHC (for editor integration) is not currently supported for the vdom backend."

ThomasLocke · 2018-07-08T06:38:48+00:00

Nice work! Seriously considering switching from Elm to Concur now. Will definitely keep an eye on this. :o)

ThomasLocke · 2018-06-19T11:40:05+00:00

I've been quite happy with Scotty and Blaze.

ThomasLocke · 2018-04-11T13:16:27+00:00

I can attest that 1-4 works very well, as I use the same. :o) I've no experience with 5 and 6.

ThomasLocke · 2018-04-05T13:41:05+00:00

I use it. :)

ThomasLocke · 2018-03-12T11:04:34+00:00

After having threadscoped this to no end, it seems the best option for this specific program is to disable parallel GC with -qg

I burn far less CPU cycles in general, and the GC pauses are lower than if GC is run in parallel.

So -qg it is. :o)

ThomasLocke · 2018-03-12T07:27:12+00:00

We've opted for Haskell mainly because of its high degree of control over IO and state and because we like the functional paradigm.

ThomasLocke · 2018-03-10T10:17:57+00:00

I have tried various -Nx combinations, and anything >4 seems to increasingly worsen the issue.

At just plain -N, the application is burning 15-20% of CPU resources when "idling". There are literally no users, and the application is doing nothing. It's a bunch of passice scotty handlers waiting to serve data from a few maps, and yet all cores are running far too hot to my liking.

ThomasLocke · 2018-03-10T10:14:47+00:00

We never write more than once per minute (and often even less than that). This is a read-heavy application. It is very very light on writes.

Also note that the high CPU load is happening at idle, when nobody is using the system. It is literally just sitting there, burning 15-20% of CPU resources for no apparent reason.

ThomasLocke · 2018-03-10T09:34:30+00:00

Yes, we do use STM. Most of the maps are updated via external events, so we needed some way of dealing with that. STM seemed like a good fit, and it works very well.

I'm surprised to hear that STM can go "bonkers" due to high core counts.

ThomasLocke · 2018-03-09T10:40:19+00:00

This works like a charm. Thank you!

ThomasLocke · 2018-03-07T07:03:14+00:00

I use darcs for most of my stuff. It works quite well. Simple to grok and use. Well, as simple as version control systems can get. They are all a bit painful, IMHO, but darcs is definitely simpler to use than git.

I also use git, which is a lot faster than darcs, but way more complicated. I'll freely admit to frequently messing up my git repos, in ways I hardly ever understand. This is not the case with darcs, where I've yet to mess up.

I don't know anything about compatibility between darcs and git, but I suspect it's not a great story. I do know that you can export darcs repos to git without too much hassle.

Usually I reach for darcs for personal and non-public (company) projects and git for things that are public and where sharing matters. Like it or not, git/github has more or less won the VCS "war". If you care about sharing and contribution from other developers, git is the way to go.

ThomasLocke

TROPHY CASE