6 ms·

I've also used several languages and IMHO, Haskell's tooling is some of the worst. Language server breaks with random errors all the time for me, I'm always con

I've also used several languages and IMHO, Haskell's tooling is some of the worst. Language server breaks with random errors all the time for me, I'm always confused about whether I should have ghcup or stack manage my Haskell versions (and what the benefits and drawbacks are), and so on. I have a project I work on from time to time, and I'm 100% sure that the next time I'll open it up, it will stop working again. Python's mess of dependency and venv management system is probably equally bad, although my experience was that Poetry is decent. By contrast, Ruby tooling usually works well (you can choose between chruby, rbenv and rvm, but they all work similarly, and Bundler just works(TM)), and Java has its warts but one of the best IDE experiences I've ever seen. Maybe the refactorings aren't as safe as in Haskell, but they're extremely easy to do.

pyrale 3y ago
I've used stack+stackage, and I can still run all of my older projects. I agree that as a newcomer the choice is not evident, haskell is a small enough community that finding mentorship is not always evident if you don't know where to look.
- mananaysiempre 3y ago
  > haskell is a small enough community that finding mentorship is not always evident I don’t know about today, but ten years ago the answer was to hop on IRC and you’d get all of your IRC-sized non-FAQs answered, however difficult they are.
  - pyrale 3y ago
    There's libera chat now. But not everyone has the idea of looking there.
  - bradrn 3y ago
    I’m not on IRC, but the subreddit, the Discourse forum and the Discord server are all pretty good for this kind of thing too.
  - tome 3y ago
    It's still the case, as far as I know. Big list of channels: https://www.haskell.org/irc/ https://www.haskell.org/irc/
revskill 3y ago
Not quite. I'm not sure about how Ruby with Bundler related to each other. Recently, i upgraded Ruby, but then what's to do about Bundler then ? I'm confused.
- Tainnor 3y ago
  Bundler is Ruby's dependency management tool, basically like npm or similar. It's come preinstalled with Ruby for a while now.
bradrn 3y ago
> I'm always confused about whether I should have ghcup or stack manage my Haskell versions (and what the benefits and drawbacks are) There was a long and drawn-out transition, but these days it’s quite simple: use GHCup to manage your tooling, and Cabal to manage your packages. At one point Stack was the best option, but no longer: it’s not as well maintained, and is missing a lot of features (see e.g. https://discourse.haskell.org/t/6849/23 https://discourse.haskell.org/t/6849/23).
- Tainnor 3y ago
  You say "don't use stack" and the other person in this comment thread says "use stack". Do you see the issue?
  - bradrn 3y ago
    Fair enough, though I’ll note that only I’ve given an up-to-date reference.
    - Eddygandr 3y ago
      Stack vs Cabal was a huge argument where I worked with multiple teams using different build tools. Add Nix and nix2whatever, and it was more fun. Spent half my time debugging build instructions
      - pastage 3y ago
        It is not that much better in Java land. Getting builds right takes lots of resources, keeping new and old things running is not trivial.
        Tainnor 3y ago
        I haven't had that experience for newer code bases. Yes, there's some ancient "works only in my IDE" stuff but that's really not how modern Java is written. Yes, there is a disagreement about whether to use maven or gradle, but IMHO they both work reasonably well out of the box.
talideon 3y ago
I expect that now that things are settling down around pyproject.yaml, Python's tooling will settle down. I've been settling on Hatch for most projects rather than using Poetry these days and Flit for smaller projects. It's managing to replace the mess of makefiles and shell scripts I used to have and supports standardised metadata. These days, I mostly use a combination of hatch, pip-tools (mostly when I'm dealing with lambdas and Django projects), and pipx whenever I'm doing anything with Python. it's not perfect yet, but it's much improved. The new pip dependency resolver still has its issues though if you haven't clamped your dependencies sufficiently and its solver can get caught in loops of excessive backtracking. Hopefully that'll improve too. pyenv is still somewhat hit-and-miss though. What's really surprised me lately is how much better OCaml's opam tool has gotten! Last time I was using OCaml in anger, the experience was very, very clunky, but these days it's quite smooth.
- pdonis 3y ago
  > I expect that now that things are settling down around pyproject.yaml, Python's tooling will settle down First, a nitpick: it's pyproject.toml. YAML was considered for the language of this file and rejected in favor of TOML. Second, unfortunately, I'm not sure I share your optimism. This is an area where IMO the Python developers have never been able to do things right. In fairness, they are trying to support a lot of very different use cases, but the proper way to do that would have been to let the communities surrounding each of those use cases invent their own tools, while focusing the standard tools in the Python standard library on the vast majority of Python projects that are pure python code--no extension modules, no weird compilation issues, just pure Python modules and packages for which build and install ought to be simple and straightforward. But even that simplest use case was never quite properly and standardly supported. Even pyproject.toml illustrates this pattern: a new markup language was adopted, one which has no support in Python's standard library, which has no obvious advantages over previous file formats, and which now creates ambiguity between pyproject.toml and the previous supposed "standard" for declarative project metadata, setup.cfg. Which do I use now? I can't just use pyproject.toml because it doesn't include everything that setup.cfg does; and I can't just use setup.cfg if I want my project to be compliant with the latest build tool specs because setup.cfg alone is now considered a "legacy" build format. So now I have to use both, even for pure Python projects where this should have been a solved problem years ago. At least the actual installation of pure Python projects is now a lot easier; once you have a properly built sdist or wheel, pip install will put it wherever you need. But the "properly built sdist or wheel" part is still IMO a lot harder than it needs to be for most projects.
js2 3y ago
It's weird how personal this is. Sometimes I wonder if it comes down to familiarity. I've been using Python professionally since 2000 and have never run into issues with its tooling. It's even easier these days: "python -m venv" and then pip are all I need in 99% of use cases. For local development I use direnv + pyenv. I typically develop on macOS and deploy to either macOS or Linux. I previously gave pipenv a try but found it to be brittle and more trouble than it was worth. I haven't used poetry just because I haven't had the need. Conversely, I regularly run into trouble with ruby. Here's a recent example where I had to contribute a patch to pre-commit to get ruby to install gems where pre-commit wanted it to: https://github.com/pre-commit/pre-commit/pull/2905 https://github.com/pre-commit/pre-commit/pull/2905 I got so annoyed with bundler I wrote a simple shell script to provide the moral equivalent of Python venvs to gem: https://gist.github.com/jaysoffian/3c67711d3f00c364365905d877cc4af4 https://gist.github.com/jaysoffian/3c67711d3f00c364365905d87... All that said, these are just minor annoyances. The only tooling I truly despise is Gradle and especially everything around the Android Gradle Plugin.
- movpasd 3y ago
  I don't have any issues with Python's packaging ecosystem anymore, having settled comfortably into a pyenv+virtualenv+pip-tools as my "stack" after going around the block a few times. But even so, I must recognise how awful the experience is for new users. It's taken me years to settle into this system, and it can take half a day to get someone up to speed with these tools if they haven't used them. I also work a lot with non-developers who need to use or contribute to Python models, so that doesn't help — but I bet it would take an order of magnitude less time to get them up to speed with something like cargo. Coaching them has helped me see how user-hostile the process is to beginners. It also doesn't help how infectious "all-in-one" Python distributions like Anaconda can be, to the point that whenever anyone has an unexpected issue one of my first reflexes is to check their PATH. The fact that Rust has a widespread default toolchain multiplexer completely solves this issue. I appreciate that maintaining such a toolchain is work, and there is value as well in the diversity and choice of an open ecosystem. But perhaps building is one place where first-class support by the reference implementation creates a worthwhile tradeoff.
grumpyprole 3y ago
Having developed Haskell professionally for many years, I've spent the last two years programming OCaml professionally. I've been really enjoying the OCaml tooling: dune, Merlin and ocamlformat work extremely well for me. Dune especially is packed full of features, for example a file-watch mode for tests. Merlin doesn't choke on large codebases like some of the Haskell tooling did and ocamlformat works better than any code formatter I have ever used. The tooling is so good, I can forgive the rather minimal standard library. OCaml is also very good regarding backwards compatibility, new releases don't break our builds.
- belmont_sup 3y ago
  I have to agree so much. Been following for years, and started new experiments this week. It all worked so well. dune init … opam install some tools like lsp restart vscode dune build --watch and I’m good to go. Edit: adding some counterpoints and issues to level the field (but are being worked on) 1. dune/opam - wish they were one thing. I can still install packages with dune, and a package lock file exists for deterministic-enough builds. 2. dune files and s-expressions are still weird to write. I wish we can move away, or at best, have a tool that helps you remember and where configs. best I have now is chatgpt instead of having to crawl dune docs 3. eio, lwt, async - 3 async runtimes, hoping that one day it’ll be easy to use an async lib with an lwt-based project via eio. The division will likely never be consolidated
  - yawaramin 3y ago
    1. I agree. And this is being worked on, in the future dune will take on more package management tasks. 2. Agree, YAML has decisively won the config format wars. But dune it's extremely unlikely that dune will change this, and we can at least tell ourselves that s-exprs are pretty cool after all. 3. Yup, I hope Eio becomes the de facto standard in the future.
epolanski 3y ago
+1. I have in most years learned some nicher languages: Elm, Rescript, Racket, Common Lisp. But nothing is even remotely bad as Haskell is. Even just setting up an IDE to have basics like syntax highlight or go to definition is a giant chore. On the official Haskell devcontainer offered by GitHub is nearly impossible to add any external dependency, so having a one-click shareable Haskell environment in the cloud (the very basic to onboard people on the language without wasting them days into having their own inconsistent environment) is a must. Another thing that I feel sucks is the default documentation for Haskell libraries. Doesn't say anything useful at all, bundles few definitions here and there, 0 examples, and more often than not there's 0 documentation.

pyrale 3y ago

I've used stack+stackage, and I can still run all of my older projects. I agree that as a newcomer the choice is not evident, haskell is a small enough community that finding mentorship is not always evident if you don't know where to look.

mananaysiempre 3y ago
> haskell is a small enough community that finding mentorship is not always evident I don’t know about today, but ten years ago the answer was to hop on IRC and you’d get all of your IRC-sized non-FAQs answered, however difficult they are.
- pyrale 3y ago
  There's libera chat now. But not everyone has the idea of looking there.
- bradrn 3y ago
  I’m not on IRC, but the subreddit, the Discourse forum and the Discord server are all pretty good for this kind of thing too.
- tome 3y ago
  It's still the case, as far as I know. Big list of channels: https://www.haskell.org/irc/ https://www.haskell.org/irc/

revskill 3y ago

Not quite. I'm not sure about how Ruby with Bundler related to each other. Recently, i upgraded Ruby, but then what's to do about Bundler then ? I'm confused.

Tainnor 3y ago
Bundler is Ruby's dependency management tool, basically like npm or similar. It's come preinstalled with Ruby for a while now.

bradrn 3y ago

> I'm always confused about whether I should have ghcup or stack manage my Haskell versions (and what the benefits and drawbacks are) There was a long and drawn-out transition, but these days it’s quite simple: use GHCup to manage your tooling, and Cabal to manage your packages. At one point Stack was the best option, but no longer: it’s not as well maintained, and is missing a lot of features (see e.g. https://discourse.haskell.org/t/6849/23 https://discourse.haskell.org/t/6849/23).

Tainnor 3y ago
You say "don't use stack" and the other person in this comment thread says "use stack". Do you see the issue?
- bradrn 3y ago
  Fair enough, though I’ll note that only I’ve given an up-to-date reference.
  - Eddygandr 3y ago
    Stack vs Cabal was a huge argument where I worked with multiple teams using different build tools. Add Nix and nix2whatever, and it was more fun. Spent half my time debugging build instructions
    - pastage 3y ago
      It is not that much better in Java land. Getting builds right takes lots of resources, keeping new and old things running is not trivial.
      - Tainnor 3y ago
        I haven't had that experience for newer code bases. Yes, there's some ancient "works only in my IDE" stuff but that's really not how modern Java is written. Yes, there is a disagreement about whether to use maven or gradle, but IMHO they both work reasonably well out of the box.

talideon 3y ago

I expect that now that things are settling down around pyproject.yaml, Python's tooling will settle down. I've been settling on Hatch for most projects rather than using Poetry these days and Flit for smaller projects. It's managing to replace the mess of makefiles and shell scripts I used to have and supports standardised metadata. These days, I mostly use a combination of hatch, pip-tools (mostly when I'm dealing with lambdas and Django projects), and pipx whenever I'm doing anything with Python. it's not perfect yet, but it's much improved. The new pip dependency resolver still has its issues though if you haven't clamped your dependencies sufficiently and its solver can get caught in loops of excessive backtracking. Hopefully that'll improve too. pyenv is still somewhat hit-and-miss though. What's really surprised me lately is how much better OCaml's opam tool has gotten! Last time I was using OCaml in anger, the experience was very, very clunky, but these days it's quite smooth.

pdonis 3y ago
> I expect that now that things are settling down around pyproject.yaml, Python's tooling will settle down First, a nitpick: it's pyproject.toml. YAML was considered for the language of this file and rejected in favor of TOML. Second, unfortunately, I'm not sure I share your optimism. This is an area where IMO the Python developers have never been able to do things right. In fairness, they are trying to support a lot of very different use cases, but the proper way to do that would have been to let the communities surrounding each of those use cases invent their own tools, while focusing the standard tools in the Python standard library on the vast majority of Python projects that are pure python code--no extension modules, no weird compilation issues, just pure Python modules and packages for which build and install ought to be simple and straightforward. But even that simplest use case was never quite properly and standardly supported. Even pyproject.toml illustrates this pattern: a new markup language was adopted, one which has no support in Python's standard library, which has no obvious advantages over previous file formats, and which now creates ambiguity between pyproject.toml and the previous supposed "standard" for declarative project metadata, setup.cfg. Which do I use now? I can't just use pyproject.toml because it doesn't include everything that setup.cfg does; and I can't just use setup.cfg if I want my project to be compliant with the latest build tool specs because setup.cfg alone is now considered a "legacy" build format. So now I have to use both, even for pure Python projects where this should have been a solved problem years ago. At least the actual installation of pure Python projects is now a lot easier; once you have a properly built sdist or wheel, pip install will put it wherever you need. But the "properly built sdist or wheel" part is still IMO a lot harder than it needs to be for most projects.

js2 3y ago

It's weird how personal this is. Sometimes I wonder if it comes down to familiarity. I've been using Python professionally since 2000 and have never run into issues with its tooling. It's even easier these days: "python -m venv" and then pip are all I need in 99% of use cases. For local development I use direnv + pyenv. I typically develop on macOS and deploy to either macOS or Linux. I previously gave pipenv a try but found it to be brittle and more trouble than it was worth. I haven't used poetry just because I haven't had the need. Conversely, I regularly run into trouble with ruby. Here's a recent example where I had to contribute a patch to pre-commit to get ruby to install gems where pre-commit wanted it to: https://github.com/pre-commit/pre-commit/pull/2905 https://github.com/pre-commit/pre-commit/pull/2905 I got so annoyed with bundler I wrote a simple shell script to provide the moral equivalent of Python venvs to gem: https://gist.github.com/jaysoffian/3c67711d3f00c364365905d877cc4af4 https://gist.github.com/jaysoffian/3c67711d3f00c364365905d87... All that said, these are just minor annoyances. The only tooling I truly despise is Gradle and especially everything around the Android Gradle Plugin.

movpasd 3y ago
I don't have any issues with Python's packaging ecosystem anymore, having settled comfortably into a pyenv+virtualenv+pip-tools as my "stack" after going around the block a few times. But even so, I must recognise how awful the experience is for new users. It's taken me years to settle into this system, and it can take half a day to get someone up to speed with these tools if they haven't used them. I also work a lot with non-developers who need to use or contribute to Python models, so that doesn't help — but I bet it would take an order of magnitude less time to get them up to speed with something like cargo. Coaching them has helped me see how user-hostile the process is to beginners. It also doesn't help how infectious "all-in-one" Python distributions like Anaconda can be, to the point that whenever anyone has an unexpected issue one of my first reflexes is to check their PATH. The fact that Rust has a widespread default toolchain multiplexer completely solves this issue. I appreciate that maintaining such a toolchain is work, and there is value as well in the diversity and choice of an open ecosystem. But perhaps building is one place where first-class support by the reference implementation creates a worthwhile tradeoff.

grumpyprole 3y ago

Having developed Haskell professionally for many years, I've spent the last two years programming OCaml professionally. I've been really enjoying the OCaml tooling: dune, Merlin and ocamlformat work extremely well for me. Dune especially is packed full of features, for example a file-watch mode for tests. Merlin doesn't choke on large codebases like some of the Haskell tooling did and ocamlformat works better than any code formatter I have ever used. The tooling is so good, I can forgive the rather minimal standard library. OCaml is also very good regarding backwards compatibility, new releases don't break our builds.

belmont_sup 3y ago
I have to agree so much. Been following for years, and started new experiments this week. It all worked so well. dune init … opam install some tools like lsp restart vscode dune build --watch and I’m good to go. Edit: adding some counterpoints and issues to level the field (but are being worked on) 1. dune/opam - wish they were one thing. I can still install packages with dune, and a package lock file exists for deterministic-enough builds. 2. dune files and s-expressions are still weird to write. I wish we can move away, or at best, have a tool that helps you remember and where configs. best I have now is chatgpt instead of having to crawl dune docs 3. eio, lwt, async - 3 async runtimes, hoping that one day it’ll be easy to use an async lib with an lwt-based project via eio. The division will likely never be consolidated
- yawaramin 3y ago
  1. I agree. And this is being worked on, in the future dune will take on more package management tasks. 2. Agree, YAML has decisively won the config format wars. But dune it's extremely unlikely that dune will change this, and we can at least tell ourselves that s-exprs are pretty cool after all. 3. Yup, I hope Eio becomes the de facto standard in the future.

epolanski 3y ago

+1. I have in most years learned some nicher languages: Elm, Rescript, Racket, Common Lisp. But nothing is even remotely bad as Haskell is. Even just setting up an IDE to have basics like syntax highlight or go to definition is a giant chore. On the official Haskell devcontainer offered by GitHub is nearly impossible to add any external dependency, so having a one-click shareable Haskell environment in the cloud (the very basic to onboard people on the language without wasting them days into having their own inconsistent environment) is a must. Another thing that I feel sucks is the default documentation for Haskell libraries. Doesn't say anything useful at all, bundles few definitions here and there, 0 examples, and more often than not there's 0 documentation.