I had some code for the Servant type-level HTTP API library in Haskell that does type-correct property testing on arbitrary web apis without user input, then Servant changed their type structure from a basic list-based format to a record-based one. This was a good change for lots of reasons, but adding the type-level code to make my library (roboservant) compile was absurdly hard, i burned days on it.
I used sqlite as a backend for scraping 160 million websites a day. It works extraordinarily well if you hold it right - in my case, that meant devoting a database file to each thread. (Arguably in this context, it's competing with flat files, but it does a really good job there.)
Me too. Got its quirks (I wish it noticed stack-relevant changes and ran intero-restart itself) but I find it really valuable, especially with Anthony Cowley's suggestion-handling stuff.
I've implemented this. It isn't too bad up to a certain point. You have to be a bit careful about your filesystem/layout of files, lots of filesystems don't particularly like it when you have a few hundred million files in one directory.
This is true :) been a great tool to write a spider in, fast native code, a strict type system and very cheap threads has made it much faster than it otherwise would have been. ZeroMQ has also been a great help in modularising it. I'll try to get a piece out on the technical architecture later. (I'm the CTO, btw.)
ha. I didn't think that at all when I was writing it, but I can see how it's applicable. I'll be sure to analyse that more explicitly next time I write a presentation.
It really depends on the type of risk. My assertion is that most startups have most of their risk in the market bucket rather than the technical bucket. If you can move some risk from the market bucket to the technical bucket, and compensate by using Haskell, that may be a good tradeoff.
in the case where your risk is in the market bucket, you may go through many just-barely-working prototypes before you hit product-market fit. at that point, if you've saved some time using Ruby (say) because of external factors like Heroku, Bundler, and ruby-friendly services, you're ahead of the game, even if your tenth prototype sucks and needs to be rewritten.
A lot of context is lost in a slideshow. I am very much a fan of the experience of developing in Haskell. My problem was tangential stuff like Cabal & the difficulty of operationalising Haskell. It's the reason I spent a few fruitless weekends trying to get a heroku haskell buildpack: if it was trivial to deploy prototypes, it would be a much more appealing target for time-poor startups.
It wasn't really intended to make much sense by itself. I find if I make slides that stand alone, the audience reads the slides and ignores me. I put the slides up as a courtesy to the people in the audience.
There was less than zero marketing involved - I gave this talk months ago and only just noticed this thread.
http://jacquesmattheij.com/The+Starter+the+Architect+the+Deb... seems relevant here. I often have the same problem - once the crazy technical stuff is done, I lose interest in the mundane details of packaging, finish, promotion... you know, the boring 90%.
GPT 5.something got it in two prompts.