3 ms·

I completely agree. I'm interested in making the Haskell tooling system better. I would welcome anyone with Haskell experience to let me know what you think wou

I completely agree. I'm interested in making the Haskell tooling system better. I would welcome anyone with Haskell experience to let me know what you think would be the highest priority items here. I'm also curious about the slowness of compilation and whether that's intrinsic to the design of GHC.

tome 2y ago
> I would welcome anyone with Haskell experience to let me know what you think would be the highest priority items here. Simplifying cabal probably, though that's a system-level problem, just just a cabal codebase problem.
- ants_everywhere 2y ago
  thanks!
lemonwaterlime 2y ago
The Brittany code fixer needs a maintainer. The previous one had to step away. It has a unique approach to code formatting that the ormolu/fourmolu formatters doesn’t. There’s lots of the philosophy and such in the docs. I like it better than the ormolu family because it respects your placement of comments and just formats the code itself. But it isn’t maintained as of a few years ago. https://hackage.haskell.org/package/brittany https://hackage.haskell.org/package/brittany
- ants_everywhere 2y ago
  thanks!
  - lemonwaterlime 2y ago
    Great vids by the way! I watch your channel.
- louthy 2y ago
  Indeed, we used Brittany too, and I was pretty gutted when the support ended!
cptwunderlich 2y ago
The Haskell Language Server (LSP) always needs help: https://github.com/haskell/haskell-language-server/issues?q=is%3Aopen+is%3Aissue+label%3A%22level%3A+easy%22 https://github.com/haskell/haskell-language-server/issues?q=... As for GHC compile times... hard to say. The compiler does do a lot of things. Type checking and inference of a complex type system, lots of optimizations etc. I don't think it's just some bug/inefficient implementation, bc. resources have been poured into optimizations and still are. But there are certainly ways to improve speed. For single issues, check the bug-tracker: https://gitlab.haskell.org/ghc/ghc/-/issues/?label_name%5B%5D=compiler%20perf https://gitlab.haskell.org/ghc/ghc/-/issues/?label_name%5B%5... For the big picture, maybe ask in the discourse[1] or the mailing list. If you want to contribute to the compiler, I can recommend that you ask for a gitlab account via the mailing list and introduce youself and your interests. Start by picking easy tickets - GHC is a huge codebase, it takes a while to get familiar. Other than that, I'd say some of the tooling could use some IDE integration (e.g., VS Code plugins). [1]...https://discourse.haskell.org/ https://discourse.haskell.org/
- ants_everywhere 2y ago
  thanks!
drblue 2y ago
The highest priority is probably making real debugging tools. Right now, the only decent debugging tool is ghc-debug to connect to a live process, and doing anything over that connection is slow, slow, slow. ghc-debug was the only thing which was able to resolve a long standing thunk leak in one of my systems, and I know that unexplained thunk leak caused a previous startup I was at to throw away their Haskell code and rewrite it in Rust. In my case, it found the single place where I had said `Just $` instead of `Just $!` which I had missed the three times I had inspected the ~15k line program. ghc-debug still feels like a pre-alpha though, go compare it to VisualVM for what other languages have. Also, I have found very little use for the various runtime flags like `+RTS -p`. These flags aren't serious debugging tools; I couldn't find any way to even trigger them internally at runtime around a small section, which becomes a problem when it takes 10 minutes to load data from disk when the profiler is on. The debugging situation with Haskell is really, really bad and it's enough that I try to steer people away from starting new projects with the language.

tome 2y ago

> I would welcome anyone with Haskell experience to let me know what you think would be the highest priority items here. Simplifying cabal probably, though that's a system-level problem, just just a cabal codebase problem.

ants_everywhere 2y ago
thanks!

lemonwaterlime 2y ago

The Brittany code fixer needs a maintainer. The previous one had to step away. It has a unique approach to code formatting that the ormolu/fourmolu formatters doesn’t. There’s lots of the philosophy and such in the docs. I like it better than the ormolu family because it respects your placement of comments and just formats the code itself. But it isn’t maintained as of a few years ago. https://hackage.haskell.org/package/brittany https://hackage.haskell.org/package/brittany

ants_everywhere 2y ago
thanks!
- lemonwaterlime 2y ago
  Great vids by the way! I watch your channel.
louthy 2y ago
Indeed, we used Brittany too, and I was pretty gutted when the support ended!

cptwunderlich 2y ago

The Haskell Language Server (LSP) always needs help: https://github.com/haskell/haskell-language-server/issues?q=is%3Aopen+is%3Aissue+label%3A%22level%3A+easy%22 https://github.com/haskell/haskell-language-server/issues?q=... As for GHC compile times... hard to say. The compiler does do a lot of things. Type checking and inference of a complex type system, lots of optimizations etc. I don't think it's just some bug/inefficient implementation, bc. resources have been poured into optimizations and still are. But there are certainly ways to improve speed. For single issues, check the bug-tracker: https://gitlab.haskell.org/ghc/ghc/-/issues/?label_name%5B%5D=compiler%20perf https://gitlab.haskell.org/ghc/ghc/-/issues/?label_name%5B%5... For the big picture, maybe ask in the discourse[1] or the mailing list. If you want to contribute to the compiler, I can recommend that you ask for a gitlab account via the mailing list and introduce youself and your interests. Start by picking easy tickets - GHC is a huge codebase, it takes a while to get familiar. Other than that, I'd say some of the tooling could use some IDE integration (e.g., VS Code plugins). [1]...https://discourse.haskell.org/ https://discourse.haskell.org/

ants_everywhere 2y ago
thanks!

drblue 2y ago

The highest priority is probably making real debugging tools. Right now, the only decent debugging tool is ghc-debug to connect to a live process, and doing anything over that connection is slow, slow, slow. ghc-debug was the only thing which was able to resolve a long standing thunk leak in one of my systems, and I know that unexplained thunk leak caused a previous startup I was at to throw away their Haskell code and rewrite it in Rust. In my case, it found the single place where I had said `Just $` instead of `Just $!` which I had missed the three times I had inspected the ~15k line program. ghc-debug still feels like a pre-alpha though, go compare it to VisualVM for what other languages have. Also, I have found very little use for the various runtime flags like `+RTS -p`. These flags aren't serious debugging tools; I couldn't find any way to even trigger them internally at runtime around a small section, which becomes a problem when it takes 10 minutes to load data from disk when the profiler is on. The debugging situation with Haskell is really, really bad and it's enough that I try to steer people away from starting new projects with the language.