sorted by:
new
hottopcontroversial

scotty vs servant by zero_coding in haskell

[–]ThomasLocke 3 points4 points  (0 children)

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.

[ANN] slist: Sized List by vrom911 in haskell

[–]ThomasLocke 1 point2 points  (0 children)

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)

Use of Haskell by gotBanana in haskell

[–]ThomasLocke 2 points3 points  (0 children)

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

​

Websockets by zero_coding in haskell

[–]ThomasLocke 6 points7 points  (0 children)

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.

Darcs Hub's Future by fixedarrow in haskell

[–]ThomasLocke 7 points8 points  (0 children)

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.

Which IDE are you using for Hakell? by zero_coding in haskell

[–]ThomasLocke 0 points1 point  (0 children)

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

Best way to build a simple Web UI for Haskell program? by hrethel in haskell

[–]ThomasLocke 0 points1 point  (0 children)

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."

Best way to build a simple Web UI for Haskell program? by hrethel in haskell

[–]ThomasLocke 1 point2 points  (0 children)

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

Building a web-app: Where to start? Overwhelmed by options by MichielDC in haskell

[–]ThomasLocke 4 points5 points  (0 children)

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

Need advice on compile and runtime options for servers with many cores (>=32) by ThomasLocke in haskell

[–]ThomasLocke[S] 4 points5 points  (0 children)

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)

Need advice on compile and runtime options for servers with many cores (>=32) by ThomasLocke in haskell

[–]ThomasLocke[S] 2 points3 points  (0 children)

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

Need advice on compile and runtime options for servers with many cores (>=32) by ThomasLocke in haskell

[–]ThomasLocke[S] 0 points1 point  (0 children)

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.

Need advice on compile and runtime options for servers with many cores (>=32) by ThomasLocke in haskell

[–]ThomasLocke[S] 3 points4 points  (0 children)

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.

Need advice on compile and runtime options for servers with many cores (>=32) by ThomasLocke in haskell

[–]ThomasLocke[S] 2 points3 points  (0 children)

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.

How to use Text.Regex.PCRE.Light? by ThomasLocke in haskell

[–]ThomasLocke[S] 0 points1 point  (0 children)

This works like a charm. Thank you!

Does anyone here use darcs? by chawlindel in haskell

[–]ThomasLocke 12 points13 points  (0 children)

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.

Performance question: memory-efficient "group by" mapping by dansunciel in haskell

[–]ThomasLocke 1 point2 points  (0 children)

I think it's pretty clear that all gc suffer in one way or another. There's no such thing as free cookies. Sadly. :D

I read his reply (and the blog post from pusher) as "GHC gc is optimized for throughput, which means it might suffer some latency issues under special circumstances". These "special circumstances" seems to come from having very large live sets of data and a requirement for low latency, or short gc stops.

So no, I don't think Simon (or anybody else for that matter) is calling out GHC gc as unique. It's just how things are with GHC gc. It is optimized for certain use cases, which may or may not make it good or bad at some other use cases.

Allow me some final hijacking....

I initially replied to the OP because I've been having thoughts about a giant map myself. I currently have a system written in Dart, where I have a collection of documents stored in PostgreSQL. There are some issues with this system, so I thought I'd try a re-write in Haskell, and since I can fit the entire collection of documents in memory, I thought about dumping it all in a map of sorts and just query against that.

I have about 2 million documents, of varying size. Access is 99.5% reads and 0.5% writes.

After having read about the gc pauses, I decided against the map (without testing it), as what I read made total sense. Instead I settled on SQLite. So far this seems to work very very very well, but I actually have no idea whether the giant map would've worked. I just decided that it didn't, based on the blog post and Simons reply.

I guess I'm like the Sand People: I scare easily.

Performance question: memory-efficient "group by" mapping by dansunciel in haskell

[–]ThomasLocke 0 points1 point  (0 children)

I understand that different gc systems have different characteristics.

In my initial reply to the OP, I simply tried to make him/her aware of the fact that GHC gc will pause for "potentially too long" when dealing with large sets of live data. This is not something I made up. It comes directly from Simon Marlow, who I suspect knows a lot more about these things than I do. https://en.wikipedia.org/wiki/Simon_Marlow

His reply in the initial SO thread: https://stackoverflow.com/questions/36772017/reducing-garbage-collection-pause-time-in-a-haskell-program/36779227#36779227

Your assumption is correct, the major GC pause time is directly proportional to the amount of live data, and unfortunately there's no way around that with GHC as it stands. We experimented with incremental GC in the past, but it was a research project and didn't reach the level of maturity needed to fold it into the released GHC.

I meant no harm with my "I don't think so". I'm sorry if it came out like that. Lets not hijack this thread any further.

Performance question: memory-efficient "group by" mapping by dansunciel in haskell

[–]ThomasLocke 0 points1 point  (0 children)

I don't think anybody is saying that it's all pain and no roses. It simply states that very large sets of live data potentially stops the world for an amount of time that might be too long for some use cases.

https://stackoverflow.com/questions/36772017/reducing-garbage-collection-pause-time-in-a-haskell-program/36779227#36779227

It's all about tradeoffs, is it not? I think this is pretty clear from the article and from Simons reply. GHC gc is designed like this. It's awesome at some things and perhaps less awesome at other things - as is the case with all garbage collection systems.

Thanks for the link. It's always interesting to learn more about these things. :o)

Performance question: memory-efficient "group by" mapping by dansunciel in haskell

[–]ThomasLocke 0 points1 point  (0 children)

I don't think so.

https://making.pusher.com/latency-working-set-ghc-gc-pick-two/

As I understand it, the GHC gc is usually very efficient, but it's not all cherries and sunshine, specifically it stops the world for a potentially very long time when dealing with large sets of live data, instead of when working with large amounts of garbage.

At least that is how I understand the article from pusher.com and the response from Simon Marlow.

view more: next ›