10 ms·

As someone that has also written haskell for about a decade and moved away from it as a breadwinner recently (but for other reasons - I simply wanted to filter

by pyrale 3y ago

As someone that has also written haskell for about a decade and moved away from it as a breadwinner recently (but for other reasons - I simply wanted to filter job offerings based on social utility rather than language stacks), I definitely agree with the author's first point: the Haskell community values learning extremely strongly. That's great because you work with curious people that have always something to teach and learn. But the community is not so strong when it comes to discard ideas after trying them, and so a professional haskell codebase, if not curated strictly, often ends up with lots of things that you can do but that you probably shouldn't use. I, however, disagree about tooling. Haskell's tooling sucks, but having used several other languages since (python, js, java, rust, elm), most tooling sucks. After this tour, I miss the Haskell toolchain. Sure, cargo is great, but that's one in many, and most older languages don't have this. I wonder whether Rust can escape this fate as it ages. The author also mentions being dismayed by Python, so I guess that's mostly me seeing the glass half-full though.

Tainnor 3y ago
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.
mberning 3y ago
I’m a bit incredulous that Java’s tooling is in the “sucks” category. You could say a lot of negative things about Java, but the tools available freely and commercially are in a league of their own.
- pooya72 3y ago
  Yes, it's definitely much easier to get up and running with Java than it is with Haskell. This includes everything from setting up the JDK, setting up your IDE, to building and deploying your applications.
- Tainnor 3y ago
  I think it's nuanced. IDEs are great, but there's often a lack of good CLI tools and they often show their age. For example, I find checkstyle rather annoying to configure and use.
  - CraigJPerry 3y ago
    If you’re looking for alternatives, SonarQube has jumped quite far in the last few releases. I like the coherence of the platform now and i find the default gates aren’t oppressive like they were in days gone by. I’ve gone all in on them these days, the feedback from sonarlint in the IDE is usually useful.
    - Tainnor 3y ago
      Last I checked, configuring stuff in SonarQube still involves fiddling with the UI instead of config files. And you need to host it somewhere.
      - deleted 3y ago
        [deleted]
- pyrale 3y ago
  Well, it really depends on what you value in your tooling I guess. I tend to appreciate minimalist tooling, and Java definitely doesn't fit that bill. To be fair, the language needs that tooling to be practical, and the quantity of it isn't helped by its long history so it isn't necessarily the tool makers that are to blame.
mymac 3y ago
If only Python would be able to really solve their dependency and backwards compatibility issues, those are really holding the adoption back. Though there is a good chance that even if they fixed those that people burned in the past will never go back into it.
- boxed 3y ago
  > [python] backwards compatibility issues What issues? A lot of problems with Python is due to keeping compatibility with Python 2.0. Implicit string concat bites me fairly often for example, and it has never been useful.
  - mymac 3y ago
    2->3 has been a complete disaster, anything older than a few weeks tends to randomly break with some kind of dependency issue, sometimes requiring multiple installations of python on the same machine which will bite each other in hard to predict ways. Python is a wonderful idea but I've yet to be able to write something in python and call it 'finished' because it never ever continues to work in the longer term. Highly frustrating and in my opinion unnecessary.
    - boxed 3y ago
      > 2->3 has been a complete disaster It WAS a long slog yes. But now it's pretty much done. And there really was no way to fix the unicode issue without a big painful transition. > anything older than a few weeks tends to randomly break with some kind of dependency issue I absolutely do not have this issue. Maybe you're using libraries very different from what I do? But I do think I have pretty wide interests/projects... > sometimes requiring multiple installations of python on the same machine which will bite each other in hard to predict ways I don't know what you're talking about here. Do you have an example? > I've yet to be able to write something in python and call it 'finished' because it never ever continues to work in the longer term. I don't have this experience.
- paulddraper 3y ago
  What dependency and backwards compatibility issues does Python have? That other languages don't?
regularfry 3y ago
Cargo is an evolution of older ideas from Ruby's bundler, so in a sense it does have a longer pedigree than most other tools of that ilk. Bundler mostly doesn't suck. There are design choices I disagree with but there's a happy path to using it that gets a lot right. There are ways to do language tooling that don't suck. Without much direct experience of cargo I can't say whether that carries across, but I wouldn't be surprised if it was genuinely the best of breed and stays that way.
- pyrale 3y ago
  > so in a sense it does have a longer pedigree than most other tools of that ilk. That's true of most new languages. It seems like most projects these days can produce a LSP with minimal effort, make the obvious choice of sandboxing every project separately to avoid dependency hells across projects, have at least basic distribution systems even with small communities, etc. The community learned a lot from the mistakes of yore.
- paulddraper 3y ago
  All I know about Ruby is that I always seem to download three versions of documentation
  - nobleach 3y ago
    Back when I used to use Ruby 10 years ago, I got used to doing the "no docs" args when I'd do a gem install. I always thought it was a cool idea to have local docs but, I never had an occasion to actually USE them. (never was I stuck in a non-internet-connected zone, wishing I had documentation)
  - regularfry 3y ago
    Adding `install: --no-document` into ~/.gemrc is something of a reflex for me. Should only be getting `ri` docs these days by default though.
- saurik 3y ago
  FWIW, the thing which really sucks about cargo is how it handles cross-compilation. Most "professional" workflows are always cross-compilation: even if you are technically on Linux already you don't want to build for the exact version you have so you create a sysroot and cross compile towards it... and cargo is somehow so bad at this that increasingly large numbers of projects are being forced to turn on a environment variable that has in the name of the variable DO_NOT_USE to shift cargo stable into accepting nightly flags so we can activate a patch that they begrudgingly committed to fix the behavior of targets to not get infected by host configuration if they happen to look similar. The goal was that this would eventually become the default but it's been years now and the related bugs are just stacking up. As a package manager I'm sure it's great... as a build system? Not so much. The situation frankly really just sucks: as far as I am concerned--from the shear number of bugs I have run into trying to do what should be table-stakes, and which even autoconf handles trivially: doing deterministic builds across platforms of a library to be embedded into another language's build system--cargo optimizes for extremely simple use cases (hell: ones so simple they lead to the wrong mental model of compiling in the first place! like, people seem to seriously think you need to compile for old systems ON old systems using old tools as cross-compilation is somehow treated as esoteric) while throwing the people who know what they are doing under the bus, which isn't at all how one should build tooling; instead, the goal should be to make extremely difficult things easier to pull off, even if it means the simple things have to be a bit harder, as your overall workflow is then easier to manage and you can better grow with your tooling rather than having to eventually throw it away entirely.
wslh 3y ago
I wonder why this discussion about tooling does not include .NET languages or Swift, even if the first class tooling are IDEs such as Visual Studio or Xcode. Most probably because the open source world escapes big tech dependencies?
- Tainnor 3y ago
  No idea about .NET, but XCode is a joke of an IDE.
  - bootsmann 3y ago
    I appreciate the "run app on any iDevice" with one click that xcode offers, but yeah the rest of the UI is terribly clunky (Try moving the boundaries of frames).
    - Tainnor 3y ago
      Not just the UI. The IDE barely has any functionality. Automated refactorings? Nope.
- pyrale 3y ago
  That's simply because I talk about my personal experience, and there's only so many languages you can experience professionally over a few years.
- paulddraper 3y ago
  Linux
  - wslh 3y ago
    Yes, but you can run both in Linux natively.
- bluk 3y ago
  As much as I like Swift, the tooling has been and still is subpar. Swift package management is barely viable. You have to use Xcode. You can try other IDEs but LSP equivalent features are at the most basic level. Xcode is the kitchen sink of IDEs which has led to many negative opinions as it struggles under its own weight. Every other year there’s new UI for things like debugging which is fine but what would be really nice is if the actual debugging worked. Technically there are reasons why you can’t print a local variable sometimes when stepping through a program, but in practice, I do not care and I want to know what the value is. If you don’t care about the “optional” tooling like the dependency manager and LSP or a linter (which is closer to ESLint versus Rust Analyzer), the required tooling leaves much to be desired. The compiler sometimes gives up when it takes too much time to process a complex type. It would be understandable in some cases but most people encounter the problem when just writing seemingly simple SwiftUI. Error messages and auto fix-it suggestions are improving but still disappointing. I remember when Apple switched from GCC to LLVM and everyone was praising the error messages as a reason to switch. Swift is actually ambitious. The generics system is world class. It has to support the legacy of a huge ecosystem on multiple platforms. SwiftUI is one of those bets that you might be surprised that Apple can still make. But whenever I fire up that SwiftUI Preview, I am crossing my fingers that maybe I’ll see something instead of an error. Swift lives up to its name in terms of moving quickly and the language design is probably fine, but outside of that, the tooling is still very immature for a decade old language which tons of resources are invested in.
alex_smart 3y ago
What is wrong with Java's tooling?
- xmcqdpt2 3y ago
  Too much XML? Seriously though what's a decent Java build tool? Hacking on Gradle means having to learn another PL entirely. Maven? Then say I want to publish a library for others to use from their own java project, how do I do that? I've never actually done it, but that page https://maven.apache.org/repository/guide-central-repository-upload.html https://maven.apache.org/repository/guide-central-repository... seems awfully complicated compared to say https://doc.rust-lang.org/cargo/reference/publishing.html https://doc.rust-lang.org/cargo/reference/publishing.html or even the pip equivalent. Granted, working on a well set up java project is nice, but the setup process is not simple.
  - paulddraper 3y ago
    So you don't like a config language like XML because _____ and you don't like a DSL like Groovy because _____. What is acceptable? P.S. For easier publishing, use a different repo e.g. Artifactory instead of Maven Central.
  - pjmlp 3y ago
    Not only do Maven and Gradle support binary libraries (including native code) instead of waiting to build the whole universe on each checkout, their plugins for mixed language development are way better than writing build.rs scripts.
  - alex_smart 3y ago
    That maven link is perhaps not the most useful, but it is not hard to find better-written articles. For example- https://docs.github.com/en/actions/publishing-packages/publishing-java-packages-with-maven https://docs.github.com/en/actions/publishing-packages/publi... The steps are roughly: 1. Configure the repository you want to push to. 2. Set up your account with the repository. 3. Configure your credentials. 4. Deploy.
  - chriswarbo 3y ago
lovasoa 3y ago
> I simply wanted to filter job offerings based on social utility rather than language stacks I wish more people did that.
- Eddygandr 3y ago
  I think this happens with experience - I’ve recently done the same after spending years chasing languages to work in
- Symmetry 3y ago
  I good place to start looking: https://jobs.80000hours.org/?int_campaign=job-board https://jobs.80000hours.org/?int_campaign=job-board
- ParetoOptimal 3y ago
  In my experience the organizations that claim to have social utility fail at it and don't pay well. Language stacks are much easier to fact check.
  - pyrale 3y ago
    You don't have to listen to orgs to make your opinion. There are plenty of orgs that obviously produce a vital service for society, and they are usually starved of good IT people: health care, social services, logistics, electricity production & distribution, industry, agriculture, emergency responders, etc. > and don't pay well. :( Well, the comp is still high enough to live a comfortable life, I just won't be able to bankroll a political party in the near future.
otikik 3y ago
> filter job offerings based on social utility rather than language stacks Any pointers on how to do this? A person that close to me is thinking about entering the High Frequency Trading world, and I would like to give them some alternatives.
- RhysU 3y ago
  Pushing advertisements to people who don't want to see them? /s Every trade matches two parties who came to the market to trade.
  - otikik 3y ago
    > Pushing advertisements to people who don't want to see them? /s That’s… where they work at now
- pyrale 3y ago
  Well, for starters you have to fight the urge to get as much compensation as you can. Once you realize that 90% of SWE job offerings will land you in the top 10-20% of earners, and provided you're fine with the lifestyle that allows, most companies need tech. The two criteria I'm interested in as an IC is how useful the job is in my eyes (this you can know before applying), and whether the company gives me enough independence to be able to make things right. So my interviews focus on a single factor: whether the company culture and organization is conductive to good, productive work I will be proud of down the line.
jgwil2 3y ago
Haskell's tooling has put me off ever really trying to get into it again. However, I've dabbled in Purescript a few times and it always seems to offer a pretty smooth experience, especially if you're familiar with JS tooling.
- george_____t 3y ago
  It has been rapidly improving over the last few years, though this can mean it's difficult to keep up. HLS (the LSP implementation) in particular is a pretty young project, and key compiler improvements which will help it improve are still landing.
friend_and_foe 3y ago
Yeah most tooling sucks. I think tooling in general was a bad idea. A compiler and an interactive shell/interpreter are all you need, you look at NPM and the current state of the python package management system, a total disaster. I personally would rather use a language where I had to include all dependencies within my program, rather than automatically fetching them from a remote server, deal with versions and version locks, all that stuff was a bad idea.
- throwawaymaths 3y ago
  > A compiler and an interactive shell/interpreter are all you need You might also want a good testing in the lang or stdlib, and a documentation system.
  - friend_and_foe 3y ago
    Well the thing about testing with Haskell, the type system ensures that you're not going to have the most common bugs. If there's an error, it's probably an error in your logic or you did some math wrong or something like that. So testing, you'd basically write tests for your mental model of how the program should operate. And because of the type system you're probably going to use unsafe for a lot of test code.
    - throwawaymaths 3y ago
      Clearly the type system is comprehensively self documenting too.
- pshc 3y ago
  Python and JavaScript both had their various fragmented package management systems added well after the language was invented and suffer for it. JavaScript is especially hobbled by the need for an intermediary bundling step. More modern languages like Rust, where tooling was carefully designed in tandem with the initial language release, fare much better in this regard.
swader999 3y ago
I haven't seen better tooling than what's available for C#. Curious to hear from others who strongly disagree.
- all2 3y ago
  C# tooling is dense, but the build tools generally "just work" TM. Occasionally I have to purge my build artifacts because the build tool doesn't clean things up completely, but that is a small pain compared to working with python. Another commenter noted that Poetry is quite good and it is (I've noticed they added venv support directly into the tool - you still need pyenv to manage multiple venvs, though).
kahnclusions 3y ago
I too have used several languages and for me Haskell’s is the worst I’ve had the displeasure of using. It could be forgivable if the language itself wasn’t so unfathomable to newcomers. JavaScript’s situation isn’t great, but it’s still easier to work with than Haskell, in terms of hours of frustration. For me it’s Rust that has really raised the bar for what quality tooling looks like.

by pyrale 3y ago

Tainnor 3y ago

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.

mberning 3y ago

I’m a bit incredulous that Java’s tooling is in the “sucks” category. You could say a lot of negative things about Java, but the tools available freely and commercially are in a league of their own.

pooya72 3y ago
Yes, it's definitely much easier to get up and running with Java than it is with Haskell. This includes everything from setting up the JDK, setting up your IDE, to building and deploying your applications.
Tainnor 3y ago
I think it's nuanced. IDEs are great, but there's often a lack of good CLI tools and they often show their age. For example, I find checkstyle rather annoying to configure and use.
- CraigJPerry 3y ago
  If you’re looking for alternatives, SonarQube has jumped quite far in the last few releases. I like the coherence of the platform now and i find the default gates aren’t oppressive like they were in days gone by. I’ve gone all in on them these days, the feedback from sonarlint in the IDE is usually useful.
  - Tainnor 3y ago
    Last I checked, configuring stuff in SonarQube still involves fiddling with the UI instead of config files. And you need to host it somewhere.
    - deleted 3y ago
      [deleted]
pyrale 3y ago
Well, it really depends on what you value in your tooling I guess. I tend to appreciate minimalist tooling, and Java definitely doesn't fit that bill. To be fair, the language needs that tooling to be practical, and the quantity of it isn't helped by its long history so it isn't necessarily the tool makers that are to blame.

mymac 3y ago

If only Python would be able to really solve their dependency and backwards compatibility issues, those are really holding the adoption back. Though there is a good chance that even if they fixed those that people burned in the past will never go back into it.

boxed 3y ago
> [python] backwards compatibility issues What issues? A lot of problems with Python is due to keeping compatibility with Python 2.0. Implicit string concat bites me fairly often for example, and it has never been useful.
- mymac 3y ago
  2->3 has been a complete disaster, anything older than a few weeks tends to randomly break with some kind of dependency issue, sometimes requiring multiple installations of python on the same machine which will bite each other in hard to predict ways. Python is a wonderful idea but I've yet to be able to write something in python and call it 'finished' because it never ever continues to work in the longer term. Highly frustrating and in my opinion unnecessary.
  - boxed 3y ago
    > 2->3 has been a complete disaster It WAS a long slog yes. But now it's pretty much done. And there really was no way to fix the unicode issue without a big painful transition. > anything older than a few weeks tends to randomly break with some kind of dependency issue I absolutely do not have this issue. Maybe you're using libraries very different from what I do? But I do think I have pretty wide interests/projects... > sometimes requiring multiple installations of python on the same machine which will bite each other in hard to predict ways I don't know what you're talking about here. Do you have an example? > I've yet to be able to write something in python and call it 'finished' because it never ever continues to work in the longer term. I don't have this experience.
paulddraper 3y ago
What dependency and backwards compatibility issues does Python have? That other languages don't?

regularfry 3y ago

Cargo is an evolution of older ideas from Ruby's bundler, so in a sense it does have a longer pedigree than most other tools of that ilk. Bundler mostly doesn't suck. There are design choices I disagree with but there's a happy path to using it that gets a lot right. There are ways to do language tooling that don't suck. Without much direct experience of cargo I can't say whether that carries across, but I wouldn't be surprised if it was genuinely the best of breed and stays that way.

pyrale 3y ago
> so in a sense it does have a longer pedigree than most other tools of that ilk. That's true of most new languages. It seems like most projects these days can produce a LSP with minimal effort, make the obvious choice of sandboxing every project separately to avoid dependency hells across projects, have at least basic distribution systems even with small communities, etc. The community learned a lot from the mistakes of yore.
paulddraper 3y ago
All I know about Ruby is that I always seem to download three versions of documentation
- nobleach 3y ago
  Back when I used to use Ruby 10 years ago, I got used to doing the "no docs" args when I'd do a gem install. I always thought it was a cool idea to have local docs but, I never had an occasion to actually USE them. (never was I stuck in a non-internet-connected zone, wishing I had documentation)
- regularfry 3y ago
  Adding `install: --no-document` into ~/.gemrc is something of a reflex for me. Should only be getting `ri` docs these days by default though.
saurik 3y ago
FWIW, the thing which really sucks about cargo is how it handles cross-compilation. Most "professional" workflows are always cross-compilation: even if you are technically on Linux already you don't want to build for the exact version you have so you create a sysroot and cross compile towards it... and cargo is somehow so bad at this that increasingly large numbers of projects are being forced to turn on a environment variable that has in the name of the variable DO_NOT_USE to shift cargo stable into accepting nightly flags so we can activate a patch that they begrudgingly committed to fix the behavior of targets to not get infected by host configuration if they happen to look similar. The goal was that this would eventually become the default but it's been years now and the related bugs are just stacking up. As a package manager I'm sure it's great... as a build system? Not so much. The situation frankly really just sucks: as far as I am concerned--from the shear number of bugs I have run into trying to do what should be table-stakes, and which even autoconf handles trivially: doing deterministic builds across platforms of a library to be embedded into another language's build system--cargo optimizes for extremely simple use cases (hell: ones so simple they lead to the wrong mental model of compiling in the first place! like, people seem to seriously think you need to compile for old systems ON old systems using old tools as cross-compilation is somehow treated as esoteric) while throwing the people who know what they are doing under the bus, which isn't at all how one should build tooling; instead, the goal should be to make extremely difficult things easier to pull off, even if it means the simple things have to be a bit harder, as your overall workflow is then easier to manage and you can better grow with your tooling rather than having to eventually throw it away entirely.

wslh 3y ago

I wonder why this discussion about tooling does not include .NET languages or Swift, even if the first class tooling are IDEs such as Visual Studio or Xcode. Most probably because the open source world escapes big tech dependencies?

Tainnor 3y ago
No idea about .NET, but XCode is a joke of an IDE.
- bootsmann 3y ago
  I appreciate the "run app on any iDevice" with one click that xcode offers, but yeah the rest of the UI is terribly clunky (Try moving the boundaries of frames).
  - Tainnor 3y ago
    Not just the UI. The IDE barely has any functionality. Automated refactorings? Nope.
pyrale 3y ago
That's simply because I talk about my personal experience, and there's only so many languages you can experience professionally over a few years.
paulddraper 3y ago
Linux
- wslh 3y ago
  Yes, but you can run both in Linux natively.
bluk 3y ago
As much as I like Swift, the tooling has been and still is subpar. Swift package management is barely viable. You have to use Xcode. You can try other IDEs but LSP equivalent features are at the most basic level. Xcode is the kitchen sink of IDEs which has led to many negative opinions as it struggles under its own weight. Every other year there’s new UI for things like debugging which is fine but what would be really nice is if the actual debugging worked. Technically there are reasons why you can’t print a local variable sometimes when stepping through a program, but in practice, I do not care and I want to know what the value is. If you don’t care about the “optional” tooling like the dependency manager and LSP or a linter (which is closer to ESLint versus Rust Analyzer), the required tooling leaves much to be desired. The compiler sometimes gives up when it takes too much time to process a complex type. It would be understandable in some cases but most people encounter the problem when just writing seemingly simple SwiftUI. Error messages and auto fix-it suggestions are improving but still disappointing. I remember when Apple switched from GCC to LLVM and everyone was praising the error messages as a reason to switch. Swift is actually ambitious. The generics system is world class. It has to support the legacy of a huge ecosystem on multiple platforms. SwiftUI is one of those bets that you might be surprised that Apple can still make. But whenever I fire up that SwiftUI Preview, I am crossing my fingers that maybe I’ll see something instead of an error. Swift lives up to its name in terms of moving quickly and the language design is probably fine, but outside of that, the tooling is still very immature for a decade old language which tons of resources are invested in.

alex_smart 3y ago

What is wrong with Java's tooling?

xmcqdpt2 3y ago
Too much XML? Seriously though what's a decent Java build tool? Hacking on Gradle means having to learn another PL entirely. Maven? Then say I want to publish a library for others to use from their own java project, how do I do that? I've never actually done it, but that page https://maven.apache.org/repository/guide-central-repository-upload.html https://maven.apache.org/repository/guide-central-repository... seems awfully complicated compared to say https://doc.rust-lang.org/cargo/reference/publishing.html https://doc.rust-lang.org/cargo/reference/publishing.html or even the pip equivalent. Granted, working on a well set up java project is nice, but the setup process is not simple.
- paulddraper 3y ago
  So you don't like a config language like XML because _____ and you don't like a DSL like Groovy because _____. What is acceptable? P.S. For easier publishing, use a different repo e.g. Artifactory instead of Maven Central.
- pjmlp 3y ago
  Not only do Maven and Gradle support binary libraries (including native code) instead of waiting to build the whole universe on each checkout, their plugins for mixed language development are way better than writing build.rs scripts.
- alex_smart 3y ago
  That maven link is perhaps not the most useful, but it is not hard to find better-written articles. For example- https://docs.github.com/en/actions/publishing-packages/publishing-java-packages-with-maven https://docs.github.com/en/actions/publishing-packages/publi... The steps are roughly: 1. Configure the repository you want to push to. 2. Set up your account with the repository. 3. Configure your credentials. 4. Deploy.
- chriswarbo 3y ago

lovasoa 3y ago

> I simply wanted to filter job offerings based on social utility rather than language stacks I wish more people did that.

Eddygandr 3y ago
I think this happens with experience - I’ve recently done the same after spending years chasing languages to work in
Symmetry 3y ago
I good place to start looking: https://jobs.80000hours.org/?int_campaign=job-board https://jobs.80000hours.org/?int_campaign=job-board
ParetoOptimal 3y ago
In my experience the organizations that claim to have social utility fail at it and don't pay well. Language stacks are much easier to fact check.
- pyrale 3y ago
  You don't have to listen to orgs to make your opinion. There are plenty of orgs that obviously produce a vital service for society, and they are usually starved of good IT people: health care, social services, logistics, electricity production & distribution, industry, agriculture, emergency responders, etc. > and don't pay well. :( Well, the comp is still high enough to live a comfortable life, I just won't be able to bankroll a political party in the near future.

otikik 3y ago

> filter job offerings based on social utility rather than language stacks Any pointers on how to do this? A person that close to me is thinking about entering the High Frequency Trading world, and I would like to give them some alternatives.

RhysU 3y ago
Pushing advertisements to people who don't want to see them? /s Every trade matches two parties who came to the market to trade.
- otikik 3y ago
  > Pushing advertisements to people who don't want to see them? /s That’s… where they work at now
pyrale 3y ago
Well, for starters you have to fight the urge to get as much compensation as you can. Once you realize that 90% of SWE job offerings will land you in the top 10-20% of earners, and provided you're fine with the lifestyle that allows, most companies need tech. The two criteria I'm interested in as an IC is how useful the job is in my eyes (this you can know before applying), and whether the company gives me enough independence to be able to make things right. So my interviews focus on a single factor: whether the company culture and organization is conductive to good, productive work I will be proud of down the line.

jgwil2 3y ago

Haskell's tooling has put me off ever really trying to get into it again. However, I've dabbled in Purescript a few times and it always seems to offer a pretty smooth experience, especially if you're familiar with JS tooling.

george_____t 3y ago
It has been rapidly improving over the last few years, though this can mean it's difficult to keep up. HLS (the LSP implementation) in particular is a pretty young project, and key compiler improvements which will help it improve are still landing.

friend_and_foe 3y ago

Yeah most tooling sucks. I think tooling in general was a bad idea. A compiler and an interactive shell/interpreter are all you need, you look at NPM and the current state of the python package management system, a total disaster. I personally would rather use a language where I had to include all dependencies within my program, rather than automatically fetching them from a remote server, deal with versions and version locks, all that stuff was a bad idea.

throwawaymaths 3y ago
> A compiler and an interactive shell/interpreter are all you need You might also want a good testing in the lang or stdlib, and a documentation system.
- friend_and_foe 3y ago
  Well the thing about testing with Haskell, the type system ensures that you're not going to have the most common bugs. If there's an error, it's probably an error in your logic or you did some math wrong or something like that. So testing, you'd basically write tests for your mental model of how the program should operate. And because of the type system you're probably going to use unsafe for a lot of test code.
  - throwawaymaths 3y ago
    Clearly the type system is comprehensively self documenting too.
pshc 3y ago
Python and JavaScript both had their various fragmented package management systems added well after the language was invented and suffer for it. JavaScript is especially hobbled by the need for an intermediary bundling step. More modern languages like Rust, where tooling was carefully designed in tandem with the initial language release, fare much better in this regard.

swader999 3y ago

I haven't seen better tooling than what's available for C#. Curious to hear from others who strongly disagree.

all2 3y ago
C# tooling is dense, but the build tools generally "just work" TM. Occasionally I have to purge my build artifacts because the build tool doesn't clean things up completely, but that is a small pain compared to working with python. Another commenter noted that Poetry is quite good and it is (I've noticed they added venv support directly into the tool - you still need pyenv to manage multiple venvs, though).

kahnclusions 3y ago

I too have used several languages and for me Haskell’s is the worst I’ve had the displeasure of using. It could be forgivable if the language itself wasn’t so unfathomable to newcomers. JavaScript’s situation isn’t great, but it’s still easier to work with than Haskell, in terms of hours of frustration. For me it’s Rust that has really raised the bar for what quality tooling looks like.