The learning curve is definitely, shamelessly high. We've been slowly polishing it to make it easy for complete beginners to fully up-to-speed on a project in minutes, but it's a lot of work that happens mostly on weekends.
Watch this space!
And, Nix doesn't work well with existing tools like intero, it requires troubleshooting to get working with ghc. You can pick either stack or cabal and both sort of support Nix, but in every case some tooling will not quite work right.
Further, if you're not doing 100% open development, Nix's delivery story is also complicated. It's further challenged for projects using private docker or GitHub repos, where in many cases there is simply no support in Nix.
No one does Haskell newbies any favors by suggesting they learn a whole new package expression language and toolchain (that they will be interacting with deeply and constantly) in addition to a language that is full of fundamentally novel concepts and a vast breadth of new libraries, techniques, and a distributed documentation style.
Please. Stop recommending Nix to new Haskell users until at least the new porcelain commands are shipped.
That sounds like a recommendation.
Everyone has different priorities. I know some users who started using Haskell at all with reflex-platform despite the difficulty because it scratched exactly their itch.
Webpack: it's like lens error messages for your builds, at runtime!
But your experience and your requirements differ from mine, and in a professional capacity I could never recommend Nix for an organization.
All of the functionality is just leveraging nix's powerful declarative model which easily defines the build artifacts of a project along with the environments necessary to hack on or compile them.
This sits on top of cabal and stack, actually. Within a project shell provided by Nix, I'll use cabal to get a repl, for example. But since Nix is handling all the dependency management, cabal doesn't have to do any work in that regard.
This is my recipe for starting with haskell and intellij: - install stack, run `stack new helloworld simple-hpack` - make sure it builds: `cd helloworld && stack test --exec helloworld` - install https://github.com/rikvdkleij/intellij-haskell and follow the `Getting started' guide
Interesting. I would advice to start with plain cabal. One has to learn how to deal with cabal anyway, so there's no point adding stack on top of it from the start.
Nah, I haven't used cabal-install in years now. Because of hpack, you don't even need to write .cabal files.
The only time I touch cabal is when I need to write Setup.hs files, which is, mercifully, quite rare.
With *.cabal project files yes, for sure.
But `stack` has completely replaced `cabal` command for me. I don't even have it installed.
VSCode as an editor that just works.
Opam for package management
JBuilder for managing builds.
Stdlib situation is still kind of a mess, but I think Base (which is just a stripped down Core) solves a lot of the current issues.
On the other hand I'm more pessimistic about the stdlib situation because Base breaks compat with the stdlib, thus making the migration impossible (or really painful) for a lot of projects. I'll therefore stick to my own extension of the stdlib (containers) in the foreseeable future…
The fact that haskell users seem to think these things are completely obvious and doesn't need to be explained is frankly a big part of the problem.
stack new my-project
cd my-project
stack ghci
> main
Haskell’s community evolved very differently from JS and the rest of open source. What seems simple to many isn’t necessarily what seems simple to the rest of us. Much of what this community considers simplicity is just convention and familiarity.
But so many people from our world are using it now that things are slowly becoming more “intuitive”!
I understand your frustration. It took me a lot of effort to get over the learning curve. Well worth it. But trust me, it’s easier than ever and getting better
[0] https://marketplace.visualstudio.com/items?itemName=UCL.hask...
[1] https://marketplace.visualstudio.com/items?itemName=Vans.has...
Haskell proper is pretty turn-key these days with stack.
Stay away from edgelord / niche projects.
Stay away from most of the IDE tooling, including ghc-mod. You don't need to be fighting the tooling when starting. The repl and "ghcid" should be all you need (though I grant it takes some learning to use these as effectively if you're used to an IDE- you will learn with experience).
Just use the "ghcid" cli tool to get compile errors and feedback. It is rock solid.
https://github.com/ndmitchell/ghcid
Your experience will be much smoother.
It takes a bit getting used to if you're used to an IDE, but with Haskell it's usually a better to go for a multi-terminal/repl kind of setup
I'm honestly not sure I'm interested in learning haskell if this is considered an acceptable situation.
When starting out, pick a common programmer's editor you already know, find a syntax highlighter for it, and turn on auto-indentation. If there's a plugin or tool which does auto-formatting and doesn't need a lot of tweaking, add that too. Learn an IDE once you understand the language and are getting frustrated by boilerplate, navigation, etc.
It is annoying to not have the high quality of IDE tooling you'd enjoy with Java, but in contrast to Java you can be very productive in Haskell even without advanced IDEs (though you would be even more productive with them).
There will be IDE tooling eventually.
I'd estimate 80% of the time I fail to compile. Typical reasons are errors from Cabal, stack is wrong version, things like that.
If it was C or Python or even Rust I'd forge ahead and make it work. But with Haskell's tooling I'm too far out of my depth to bother.
Stack (and stackage) is the best nicest, most-reliable build-system of any language.
So far, just in these comments I've seen:
1. just use plain cabal
2. use stack, you don't need cabal
3. use gchid
4. haskell+nix is best
5. use hpack
PS. I bought HaskellForMac and it's great. It ties you a Haskell version a little older than the latest but that's OK too.
[1] - http://haskellformac.com
From the tutorials they give, you can build all types of stuff. It looks like the IDE supports game development as well as some data analytics tools. In Haskell for Mac, the right side is like Swift Playgrounds (REPL) and the left side is like IntelliJ (IDE). It's actually kinda weird but that's how it's setup.
[1] - https://cryptomiso.com
I still can't get point-at type to work in emacs/vim for rust reliably(macros make it even worse).
Haskell tooling is good enough(i haven't worked on big projects, so maybe it doesn't scale) now with intero if you use emacs.
That‘s something Rust got very right from the beginning.
I just tried to get haskell set up a few days ago and I couldn't get it working with either vscode or Idea. I also couldn't get ihaskell (jupyter notebook) installed successfully.
I might give it another shot based on these instructions, but the fact that pretty much every program seems to make different assumptions about whether you're using cabal or stack and how you have them set up is really annoying. I assume if you are really knowledgeable about this tools it's not that bad, but as a haskell beginner they are completely impenetrable. (Even just the yaml files used by stack seem completely incomprehensible compared to the formats used by most languages' build tools.)
Considering that the language itself has a pretty steep learning curve, it's really frustrating wasting several hours just trying to get the haskell environment set up without success and not even getting the point of being able to try to actually use it.
I've had a pretty bad opinion of the Ocaml and F# tooling in the past, but the haskell tooling is just so, so much worse. (F# seems to have gotten to a point where the tooling if you can just use .net core, although it gets horrible again if you then need to also use mono at the same time so you can use the interpreter.)
It's especially bad if you compare it to something like rust where cargo works so well it's actually in itself a reason to use rust.