Creating Your First Haskell Project - Haskell's Tooling Is Good Actually
ฝัง
- เผยแพร่เมื่อ 6 ต.ค. 2023
- This tutorial is focused on Haskell specifically creating your first
ever project with Cabal.
In this video I used:
- GHCup www.haskell.org/ghcup/
- cabal cabal.readthedocs.io/en/lates...
- GHC www.haskell.org/ghc/
Let me know what you think and if there is anything specific you would like to learn about.
---------------► Wanna Support Me? ◀︎---------------
Github:
www.github.com/sponsors/gavinok
Patreon:
/ gavinfreeborn
---------------► Wanna Checkout My Dots? ◀︎---------------
Vimrc:
github.com/Gavinok/dotvim
Emacs Config:
github.com/Gavinok/emacs.d
---------------► Come Join The Community◀︎---------------
LBRY:
odysee.com/@GavinFreeborn:d
Matrix Space:
matrix.to/#/%23gavinfreeborn:...
Discord:
/ discord
Great breakdown. There is not nearly enough haskel content out there!
thank u ! been in love w haskell syntax for a long time but it’s been a while since i looked at the state of affairs
so glad to hear cabal hell has been basically fixed w lockfiles!!
big barrier to entry lifted :3
very useful. thank you!
Great video. I love using Haskell and do so professionally, but there are still some major issues with Haskell tooling:
* Working with multiple projects depending on different GHC versions can be tricky - Often tooling is not portable between versions without a rebuild
* LSP often can't handle very large projects
* LSP often needs to be restarted
* Compiler is very slow - On large projects it can make it infeasible to run CI on every push which is a huge problem
* Space leaks are a real problem - fans may say these aren't that big an issue but in practice the lack of good debugging facilities make it harder than it should be to track them down
* No ABI means that everything needs to be recompiled including dependencies - also makes writing real native plugins impossible
* Ecosystem will never be as good as major languages such as JVM, even Rust
I could list a bunch more but these are the major ones.
should we rethink the tools in functional approach then?
should we rethink the tools in functional approach then?
That's a good list of realistic current issues, aside from the last that's some sort of prophecy.
Regarding different toolchains, Stack is designed to handle that. GHCup has some capability too, though I'm not that familiar with it.
It's true that I'm just making my own prediction about the ecosystem, but I'd make a weaker argument that ecosystem will in general scale with the size of the active contributors to a community, and Haskell's community is smaller and growing slower than other more popular languages. You make a good point about stack for multiple toolchains. GHCup unfortunately doesn't support that at the moment. I believe that the is a general desire to move away from Stack and have cabal subsume much of its functionality, but LTS snapshots and multiple toolchain support are big missing pieces before Stack can be discarded completely. @@0LoneTech
Is there something stopping you from caching build artifacts in CI? that speeds up the process considerably… At least for github actions there are multiple options that i think come with caching included
Thanks for this video Gaving. Quite out of the scope of this video but, have you ever tried EXWM? Any thoughts on it? I would love to hear your opinion sometime. Kind regards.
Great video! The wider discussion around Haskell does seem to come mostly from people who don't use it actively. That's fine, you can't expect everybody to use everything, but the chatter becomes stale and people develop bad opinions from it.
I'd be interested in a video on Smalltalk (squeak or pharo) or Forth at some point. The latter lets you run a REPL on a microcontroller over a serial connection, which is a trippy feeling!
It's not actually a REPL. Forth doesn't automatically print results, merely prompts. And more significantly, it's not merely interpreting commands; you have a compiler in that interface too, and an extensible one at that. All in a footprint smaller than the hello world executables from more famous languages.
Good video, I wish people who talk about "bad tooling" would actually describe languages with good tooling (e.g. in comparison Haskell is far better than Python for a huge amount of tooling)
That gets us as far as the "ocaml > haskell" comment already present here. Sometimes you can identify the speaker's favourite language on the repetitive rhetoric. I'd prefer specific functionality descriptions, e.g. git has bisect to track down issues and the ability to do local branches. Failing that, specific questions, like what is using the most RAM and which tool can identify that.
I've been using nix and stack but if I can get by with cabal and nix instead that would be nice
Could you talk about Clojure/Lisp market? I'm a Java Developer and I learned a little bit of Clojure and felt in love with it. In Brazil where I live I could only find one company opening position for Clojure developer. Do you have any tips about finding jobs with Clj?
Can Cabal uninstall packages yet? Are the GHC and Cabal maintainers still finger pointing?
yes cabal can uninstall packages as well. you can use a command like ghcup list to list all the basic packages youve installed if im not wrong.
I’ve heard that stack is easier to use for new Haskell devs and or projects, personally I’d like to see you go into Cabal vs stack more in depth in a video. I’m using cabal for things right now but I’m trying to decide which to use as I go forward.
Sounds good! There are some resources covering the differences but I would be more than happy to dig into it.
As I understand it, they don't compete much. Stack builds on Cabal; Cabal handles your dependencies and build process, Stackage provides distributions of those dependencies, and Stack sets up your compiler to match in a manner that guarantees you can't use undeclared dependencies. It seems easier to me to start out from stack, such that your project includes its context.
That said, the per project isolation can also be wasteful. You don't need stack if you use libraries and compiler from your Linux distribution, for instance, and takes work to get Stack to do that (GHCup does it automatically if you use GHCup to install Stack). It's not completely dumb, it does share tooling in a common cache, but stack's work folders do take a bunch of space.
So it seems it's more GHCup vs Stack (though they can cooperate too) than Cabal vs Stack.
guuys does anyone know an extension or external software that integrates with vscode to provide color highlighting for haskell functions from the base library? like zipWith zip, foldr, map, putstrln, print etc. it looks very bland and odd for a language to have its basic functions look just plain white. can i configure this specific psrt in the settings or something? ive used multiple different extensions on vscode, nothing provides colors to funcions.
i think there’s an additional vscode extension for haskell syntax as well as some specific themes for haskell
is there functional approach for tooling? I guess many problems due to Unix paradigm
The best it really gets is using something like nix or guix
whats the difference between "cabal install package" vs adding that to .cabal file? What If I remove that library from the .cabal file will it be automatically uninstalled?
"cabal install" is meant to install programs for common use, while dependencies in the .cabal file is used to have libraries accessible in a particular project. E.g. pandoc-cli provides a user command line tool, and might make sense to install, but a data type package like containers should be declared as a dependency.
Uninstallation appears oddly neglected; the cabal documentation doesn't seem to want to even mention it. There are some other utilities like cabal-uninstall, stack-clean-old or nix-collect-garbage.
I don't think Cabal makes any attempt to track if you still have projects around that do depend on older packages.
problem was likely me, but earlier this year I would have lots of issues with HLS (in emacs if that matters) with imported dependencies and language extensions. Another problem is that it's really hard to get help, since 1/3 of the comments are about stack, 1/3 are about cabal, and 1/3 are telling people just to use the other one. I found the documentation on including dependencies under the library vs executable very confusing too. Overall I agree though that cabal basically gives you everything you want.
It just sucks. The tooling and documentation around the language is a joke.
I get what you mean. I've had issues in the past with HLS and while it's not perfect it's worked for the most part on my end and when it runs into errors with a particular extension I've just made use of the repl but that has only happened a few times. I've been lucky enough that switching to the newest HLS has fixed most of my issues. As far as the community goes they sure don't help much when you look at stack overflow. Looking at the cabal docs would be my first suggestion.
@@GavinFreeborn Yeah this was shortly before 2.0 was released, so without it being on ghcup, I probably had some version comparability issues I wasn't aware of. More recently I did quite a bit more Haskell and didn't have those issues as badly. Anyways, super appreciate your videos! Probably going to build my next round of side projects in Haskell after I close out the current round.
well, I'm trying hard to agree with you,but I'm 3 days straight trying to get the lsp to work on vscode, and I use arch (btw), so I'm used to clunky configurations with confusing documentation
I ve learned the basics of Haskell yet I found it hard to customize xmonad window manager although it is written in Haskell language..! I don't know why..!🤔
Could you please helpe me 🙏
Sure, mind giving me a rundown of what you have had issues with? Biggest thing is using the `X` monad type which is basically the catchall for anything that uses state. Assuming you have used the IO monad in the past you can use the X monad in a similar way. Maybe I can make a quick intro to extending xmonad
Feel free to ask in my discord and I will do my best to help
@@GavinFreeborn
Because of time limit that may keep me so busy to join discord right now, ...could you do a video guide to explain xmonad config and I mean especially if you use the distrotube xmonad code as an example...
@@streambarhoum4464 I will do my best. I also lack time. Recording and editing videos takes a while 😄
Well done. "ghcup" makes it easier than ever to get started.
Next up - "reverse engineering function implementation using holes".....just kidding.
well, the growing pains of Haskell come from the fact that is the main research language so is constantly changing, so even if Haskell is an amazing language, using it for a project is difficult.
Bro it's Tsoding ( as in Sojin ) it's Russian, it's not Ts coding
🤓☝
@@SIGSEGV200xD
Things that were massively annoying for me the first time I used just cabal recently: 1) Every time you add a file, you have to edit the cabal file. 2) tests are treated like an optional/secondary/external thing rather than an integral part of the dev process (weren't even covered in this video) 3) Still have no idea what cabal.project is for 4) Way too much conflicting advice about using it with nix (ok this is my fault for trying to use nix in the first place, but still)
hackage.haskell.org/package/cabal-edit could solve point 1. 2 is fair though I don't find many build tools actually doing much better 😅. 3 is more a nix problem, part of the reason I don't use it is the constantly changing solutions
After your tenth "..go ahead and...", I had to stop watching.
Ocaml > Haskell
avg oops enjoyer
copied the code from the video literally word for word and got multiple errors:
app/Main.hs:7:9: error:
• Couldn't match type ‘[Char]’ with ‘RoutePattern’
Expected: RoutePattern
Actual: String
• In the first argument of ‘get’, namely ‘"/"’
In the first argument of ‘($)’, namely ‘get "/"’
In a stmt of a 'do' block: get "/" $ do text "Hello World"
|
7 | get "/" $ do
| ^^^
app/Main.hs:8:14: error:
• Couldn't match type ‘[Char]’
with ‘text-2.0.2:Data.Text.Internal.Lazy.Text’
Expected: text-2.0.2:Data.Text.Internal.Lazy.Text
Actual: String
• In the first argument of ‘text’, namely ‘"Hello World"’
In a stmt of a 'do' block: text "Hello World"
In the second argument of ‘($)’, namely ‘do text "Hello World"’
|
8 | text "Hello World"
| ^^^^^^^^^^^^^
[Process exited 1]
Edit: I went to the Scotty documentation and copied their example too and nothing worked.
So yes, Haskell has some of the worst tooling of any programming language. Reminds me of why I dropped it 2 years ago. Things just don't work sometimes for no known reason, the documentation on almost everything is shitty and the community is too far up their own behinds to actually provide any bit of useful information.
Looking at the error it seems like the overloaded strings extension isn't being used you can add it to your cabal file but if it's included in the file this should have worked. If you ran this from the REPL you can try :set -XOverloadedStrings.
@@GavinFreeborn you were right I wasn't using ghci so I couldn't enter the command you suggested. But completely nuking ghcup and reinstalling it somehow fixed the issue. But this shouldn't have happened because I still don't know why the extension wasn't loaded initially and I needed to delete and reinstall ghcup and now it works, I also don't know why. Imo haskell is just too broken for me to take it seriously.
This is what the first line in the Scotty example is for: {-# LANGUAGE OverloadedStrings #-}
A route to find this in the documentation would be that the type has an IsString instance, a type class which is used for OverloadedStrings, as its documentation states.
If you copied the Scotty code line by line you should have a LANGUAGE pragma at the top of the file, and this error does not show up. Maybe you missed it?