Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I tried Haskell for 5 years

metarabbit.wordpress.com

Post reply on HN
Print view View original

231–240 of 273 posts

Re: I tried Haskell for 5 years

#231

Post by Confusion »

arnon wrote: post #74

We have a code base of roughly 200,000 lines of Haskell code, dealing with high performance SQL query parsing, compilation and optimizations. I only remember one situation over the past 5 years that we had a performance issue with Haskell, that was solved by using the profiling capabilities of GHC. I disagree that performance is hard to figure out. It could be better, yes - but it's not that different than what you'd…

I find that incredibly hard to believe. I wonder whether you are looking at history through rose-tinted glasses or you simply don't know because other people quietly solved those problems. I ran into such problems several times in 50 line programs and not because my code was non-idiomatic or wrong. #haskell agreed it was non-trivial to get the code to perform well.

Re: I tried Haskell for 5 years

#232

Post by mavelikara »

tetrep wrote: post #50
hzhou321 wrote: post #13

> 1. There is a learning curve. Time and experience can cover up anything. So this does not say much about Haskell other than it is all negative without time and experience. > 2. Haskell has some very nice libraries So does NodeJS and (on an abstract level) Microsoft Word. Libraries are infrastructures and investments that (like time and experience) can cover up any shortcomings. > 3. Haskell libraries are sometimes…

> The line that if it compiles, it’s probably correct is often true. That is the meat of why Haskell is so great. I've never so reckless refactored code as much as I do in Haskell, I just wait for the compiler to tell me what I missed and go back and fix it up. I'd never do that in C, C++, Java, etc; it'd be suicide. And while that's still not a great fleshed out explanation, it's a great oversimplification of the sy…

> That is the meat of why Haskell is so great. I've never so reckless refactored code as much as I do in Haskell, I just wait for the compiler to tell me what I missed and go back and fix it up. I'd never do that in C, C++, Java, etc; it'd be suicide.

I work on Java projects and do big re-factorings using IntelliJ, relying on the compiler. So this is a bit project-dependent.

Java chooses two wrong defaults - nullability by default, and mutability by default. If your project consciously chooses to not opt into these defaults, from my experience, you can use javac to guide you in fearlessly making large refactorings.

Re: I tried Haskell for 5 years

#233

Post by shusson »

arnon wrote: post #110
knz42 wrote: post #105

Earlier quoted context omitted.

Hi can you tell us a bit more about this SQL-related project? I'm rather practically interested.

I work for www.sqream.com, and our main product is SQream DB. SQream DB is a GPU SQL database for analytics. Everything was written in-house - from the SQL parser all the way down to the storage layer. We're designed to deal with sizes from a few terabytes to hundreds of terabytes, and we use the GPU to do most of the work. It is the compiler (written in Haskell) however, that decides about specific optimizations and…

Any chance SQream DB will be open sourced or a demo version? It seems every Column based GPU DB I find is behind a paywall and targeting enterprise levels.

Re: I tried Haskell for 5 years

#234

Post by eximius »

zzalpha wrote: post #106
arnon wrote: post #74

We have a code base of roughly 200,000 lines of Haskell code, dealing with high performance SQL query parsing, compilation and optimizations. I only remember one situation over the past 5 years that we had a performance issue with Haskell, that was solved by using the profiling capabilities of GHC. I disagree that performance is hard to figure out. It could be better, yes - but it's not that different than what you'd…

but it's not that different than what you'd get with other programming languages. Until you have to solve a (maddeningly common) space leak issue. That's a problem unique to lazily evaluated languages (basically Haskell) and is godawful to debug. It reminds me of solving git problems... you suddenly find yourself having to tear back the abstraction layer that is the language and compiler and start thinking about thun…

I find this response a little ironic because we don't really see complaints about knowing the C runtime and C compiler when performance becomes a problem, which is also jarring and frustrating. But, ultimately, sometimes languages have failings and we need to peek under the hood to figure out how to address it - we're just more comfortable with the relatively common and direct mapping of the C runtime.

I am not experienced enough with Haskell to know whether peeking under its hood involves a more complicated model or not. It might be more frustrating. But its certainly not a unique experience - it's costs are just less distributed over other runtimes.

Re: I tried Haskell for 5 years

#235

Post by arnon »

shusson wrote: post #233
arnon wrote: post #110

Earlier quoted context omitted.

I work for www.sqream.com, and our main product is SQream DB. SQream DB is a GPU SQL database for analytics. Everything was written in-house - from the SQL parser all the way down to the storage layer. We're designed to deal with sizes from a few terabytes to hundreds of terabytes, and we use the GPU to do most of the work. It is the compiler (written in Haskell) however, that decides about specific optimizations and…

Any chance SQream DB will be open sourced or a demo version? It seems every Column based GPU DB I find is behind a paywall and targeting enterprise levels.

I think it's unlikely at this point...

We too are currently during some large projects for enterprises...

We will be releasing a community version on AWS and Azure in the near future which should be cheap or free, other than the instance cost on the respective cloud provider.

Re: I tried Haskell for 5 years

#236

Post by arnon »

dllthomas wrote: post #184
knz42 wrote: post #105

Earlier quoted context omitted.

Hi can you tell us a bit more about this SQL-related project? I'm rather practically interested.

If you want more generic SQL tooling in Haskell, my project was just recently open sourced ( https://github.com/uber/queryparser ). It currently has support for Vertica, Hive, and Presto; adding support for more dialects isn't complicated. I'm working on cleaning it up for hackage.

Very interesting! Do you do any sort of typechecking in this?

FWIW, HsSqlPpp also supports various dialects. In SQream DB we use a custom dialect, while HsSqlPpp is mostly Postgres.

Re: I tried Haskell for 5 years

#237

Post by mands »

seabrookmx wrote: post #222
mands wrote: post #103

Earlier quoted context omitted.

We're using Haskell to produce an entire compute platform for building, composing, and running type-safe containerised micro-services for data science. This certainly touches on a lot of the areas that Haskell is traditionally known for being good at, e.g. building DSLs, type systems, interpreters, etc. However, the work also includes a runtime platform that is more low-level, including building our own container sys…

Any particular reason you're building your own container system instead of leveraging LXC or Docker? For the massively parallel workloads you find in data science, it seems like you'd benefit a lot from the wealth of container orchestration tools around Docker (swarm, Rancher/Cattle, Kubernetes) in order to easily scale out your functions. Especially when many companies already have these set up for their more vanill…

Hi there - we've actually built a lot of our container ecosystem around existing Linux tools, including `systemd-nspawn`, `btrfs` and more rather than creating the whole stack from scratch - and again this is all controlled from Haskell. We experimented with Docker, Kubernetes and more, but found they they made lots of assumptions about what was running inside a container that didn't mesh with our compute model, so using lower-level primitives worked better for us.

We're really lucky also to have one of the main `rkt` developers joining us soon to work on the container side.

Re: I tried Haskell for 5 years

#238

Post by mands »

nickpsecurity wrote: post #167
mands wrote: post #103

Earlier quoted context omitted.

We're using Haskell to produce an entire compute platform for building, composing, and running type-safe containerised micro-services for data science. This certainly touches on a lot of the areas that Haskell is traditionally known for being good at, e.g. building DSLs, type systems, interpreters, etc. However, the work also includes a runtime platform that is more low-level, including building our own container sys…

This work might give you some ideas even though it's a bit dated: http://programatica.cs.pdx.edu/House/ Also, COGENT for lowest-level stuff being wrapped for use in Haskell somehow might be interesting. Used on ext2 filesystem already. https://ts.data61.csiro.au/projects/TS/cogent.pml

Thanks for the pointers - house is great, I remember reading some of the papers a long time ago.

I haven't seen COGENT before - will take a look over the weekend - thanks!

Re: I tried Haskell for 5 years

#239

Post by runeks »

choxi wrote: post #8

If anyone's curious to try out functional programming, I would highly recommend Elm. I haven't been so excited about a language since I went from C to Ruby ten years ago, and Pragmatic Studios has a great course on it (I have no affiliation): https://pragmaticstudio.com/courses/elm

Side bonus to using Elm on the frontend: if your backend is written in Haskell, you can derive Elm types and functions to query your backend, giving you type safety from front to back.

https://hackage.haskell.org/package/elm-export

https://hackage.haskell.org/package/servant-elm

Re: I tried Haskell for 5 years

#240

Post by restalis »

eximius wrote: post #234
zzalpha wrote: post #106

Earlier quoted context omitted.

but it's not that different than what you'd get with other programming languages. Until you have to solve a (maddeningly common) space leak issue. That's a problem unique to lazily evaluated languages (basically Haskell) and is godawful to debug. It reminds me of solving git problems... you suddenly find yourself having to tear back the abstraction layer that is the language and compiler and start thinking about thun…

I find this response a little ironic because we don't really see complaints about knowing the C runtime and C compiler when performance becomes a problem, which is also jarring and frustrating. But, ultimately, sometimes languages have failings and we need to peek under the hood to figure out how to address it - we're just more comfortable with the relatively common and direct mapping of the C runtime. I am not exper…

"we're just more comfortable with the relatively common and direct mapping of the C runtime"

That's a funny way to put it. It's more like the difference between getting results or abandoning the thing altogether due to exploding cost of required effort.

Post reply on HN