creichert

The -xc runtime option does just that, with a stack trace[0].

  ./app +RTS -xc

I wouldn't exactly say there is a total lack. To name a few:

Thread Scope: https://wiki.haskell.org/ThreadScope

Event Log: https://ghc.haskell.org/trac/ghc/wiki/EventLog (capable of live monitoring)

GHCi Debugger: https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

EKG: https://hackage.haskell.org/package/ekg

I also consider type system features to be a very useful form of tooling:

Typed Holes: https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

Deferring Type Errors: https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

Partial Type Signatures: https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

[0] - Can't direct link, look for -xc here: https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

This is only true when you are becoming familiar with the language (arguably any programming language). Once you're able to get a grasp on how to program in Haskell, it's very possible to hack programs together quickly and refactor with confidence later.

Haskell type classes can make it a bit easier to encode (and infer) interfaces but assume a single implementation per data type. ML modules do not make this assumption and support a higher degree of modularity as a result.

Robert Harper has some extremely good writing out there on this topic (and many more): https://existentialtype.wordpress.com/2011/04/16/modules-mat...

[0] - http://www.mpi-sws.org/~dreyer/papers/mtc/main-long.pdf

    data F = F { fName :: String }
    data P = P { pName :: String }

I implemented a similar experiment with Haskell and Rust[0]. It does some simple math and also passes a Haskell callback function into Rust code. Unfortunately, I think we lose quite a bit of information by passing through C code (e.g. Rust's parametric polymorphism).

[0] - https://github.com/creichert/haskellrustdemo (Careful, it will not compile with rust 1.0 beta (use of unstable library feature 'libc')).

Here are some links which might help:

http://www.haskellforall.com/2014/10/how-to-desugar-haskell-...

https://github.com/kqr/gists/blob/master/articles/simple-syn...

When I'm working with production environments, I build the Haskell executable locally and add that (statically linked) program to the Dockerfile. That should tremendously speed things up. The caveat is that your local and production architecture are the same. I find deploying the static executable much quicker and more simple. You aren't doing it wrong, just thought I would my own preferences.

Some environments like Elastic Beanstalk have timeouts that will kill the build if it doesn't build quickly enough (a problem on smaller VMs). Another issue is potential RAM needed by GHC.

Keep in mind that Haskell executables statically link Haskell libraries and dynamically link system libs (by default). You can find your system library dependencies by running:

    $ ldd dist/build/serials/serials
    [...]

Anything specific? What kind of environments are you deploying in?

Among the companies listed are Facebook and Microsoft.

This list may not be long or exhaustive but it does show a number of companies who are publicly willing to say they use Haskell. It was started in January.

I can personally attest to several companies I have worked with not mentioned in the list which also use Haskell internally. Haskell is not always the bread and butter of the business software. However, it often has an extremely strong presence for developing internal tools, compilers for DSL's, and (micro)services for various tasks.

Scotty would be closer to Sinatra and Flask. Spock is similar to Scotty but comes with a few more built-in features like type-safe routing, sessions, etc.

I recommend Yesod but there are certainly some advanced metaprogramming features (routing, models).

Have you checked out the Yesod scaffold site? https://github.com/yesodweb/yesod-scaffold

Get out and build. Get customers. Change the world. The time and energy spent being nervous about this is not productive.

I don't doubt YCombinator will help in tremendous ways (I also applied), but it's important to keep pushing forward in spite of whether you are invited for the interview or not.

Let's not turn this into a cliche! Monads are powerful. I find do notation much easier to read in many cases:

     do subscribe
        assertSubSucceeded
        startRoundtripTimer
        assertRecievedWebHook "channel_occupied"
        stopRoundtripTimer
        unsubscribe
        assertRecievedWebHook "channel_vacated"

On top of this, once you have a basic intuition for how monads work, you start gaining the ability to describe what your program does at the type level. For example, This block of code requires a read-only environment (Reader), has logging output (Writer), and accesses websockets (WebSocketT).

Also, the fact that Haskell is a less mainstream language led to a few obvious disadvantages: less documentation, not quite as many libraries, poorer tooling (although having on the fly type errors show up with mod-ghc is already a massive win over Ruby).

Yes, you essentially need to be prepared to do any or all of the following if you want to use Haskell commercially:

1) Patch libraries and tooling.

2) Engage communities and maintainers (bug reports, mailing list, etc).

3) Implement functionality (from scratch) which "should be there".

If you can't, or won't, do these things, Haskell will be much more painful to use in the real world.

My advice is to start small. Look into making documentation updates and fixing bugs you find in projects you currently use. Expand your open source toolset as you build more and repeat the process.

My brother and I co-founded SimplyRETS earlier this year to solve the real estate industry's archaic data problem. We built a modern, RESTful API in Haskell that normalizes MLS data and makes it easier for developers to build websites and applications.

We'd love to hear your thoughts and feedback!

[0] - https://github.com/SimplyRETS/simplyrets-python-sdk [1] - https://github.com/SimplyRETS/simplyrets-ruby-sdk

Not necessarily, in some MLS areas we are able to distribute on behalf of the MLS vendor. It's on a case by case basis and still requires us to ensure we are working with a valid broker, though.

> It's not like building an app on the Twitter or Tumblr API, you have to call the MLS office and talk to real people (who are usually experts in real estate, not tech) and often pay them real money.

In general, this is true. However, we are simplifying the process :). Usually, we are able to handle all the dirty work with the MLS vendor on behalf of the broker. Especially in areas where we have a licensing agreement with that MLS already. Not all MLS's support this but we are growing our reach to handle this as smoothly as possible.

> Also, I'm guessing your IDX feeds don't always include sold properties or historical data.

We can only support what the MLS vendor supports but gaining access to sold and historical has only a problem in smaller MLS areas. It usually costs more at the MLS level, though.

I'm not surprised to see so much push-back from agents [0]. It's a pretty competitive industry and most agents don't take it lightly when their leads are taken :). I do feel like more technology is being adopted but I am curious as to why real estate tech seems so behind?

I also work with real estate data on SimplyRETS (https://simplyrets.com). We aggregate data from MLS's across the US and the state of the art is quite a mess. We took a slightly different approach, though, in that we distribute the data to app developers and brokers through our API and let them manage their leads.

Very cool stuff. Keep up the good work!

[0] - See comments in http://techcrunch.com/2015/02/26/openlistings/ and http://www.inman.com/2015/02/27/startup-lets-you-shop-withou....

The core api service is written in Yesod and various other components are written in Scotty and WAI.

Why such short support windows? The strawmen of three months between releases and a one month grace period are ridiculously short support windows. The reason I propose them is because- like I mentioned in the design goals- we want the smallest delta from how people work today. Right now, there is no concept of stable versions, and we're trying to introduce it. Starting off with a more standard support window of something like two years would be a radical shift in how library users and authors operate today. Three months is very short, but it's long enough for us to test the process. As time goes on, we should have serious community discussions on how long a support window we should have. (I, for one, am fully in favor of extending it well beyond three months.)

-xc (Only available when the program is compiled for profiling.) When an exception is raised in the program, this option causes a stack trace to be dumped to stderr. This can be particularly useful for debugging: if your program is complaining about a head [] error and you haven't got a clue which bit of code is causing it, compiling with -prof -fprof-auto and running with +RTS -xc -RTS will tell you exactly the call stack at the point the error was raised.

http://www.haskell.org/ghc/docs/7.8.3/html/users_guide/runti...

I enjoy contributing to the tools I personally use. Start with small contributions that are not too high commitment. Engage authors on their issue trackers and ask questions. Read the source code for the tools you use and depend on. Always ask yourself how you could make it better.

For example, in the `head []` case, ghc has an option to locate the exact source of the error:

-xc

(Only available when the program is compiled for profiling.) When an exception is raised in the program, this option causes a stack trace to be dumped to stderr.

This can be particularly useful for debugging: if your program is complaining about a head [] error and you haven't got a clue which bit of code is causing it, compiling with -prof -fprof-auto and running with +RTS -xc -RTS will tell you exactly the call stack at the point the error was raised.

The output contains one report for each exception raised in the program (the program might raise and catch several exceptions during its execution), where each report looks something like this:

  *** Exception raised (reporting due to +RTS -xc), stack     
  trace:
    GHC.List.CAF
    --> evaluated by: Main.polynomial.table_search,
    called from Main.polynomial.theta_index,
    called from Main.polynomial,
    called from Main.zonal_pressure,
    called from Main.make_pressure.p,
    called from Main.make_pressure,
    called from Main.compute_initial_state.p,
    called from Main.compute_initial_state,
    called from Main.CAF
  ...