7 ms·

> * It tends to have 'first error, breaks rest of compile' problems `-fdefer-type-errors` will report those errors as warnings and fail at runtime, which is go

• louthy 2y ago
  > Which other functional programming languages do you think have better tooling? F#, Scala > OCaml's LSP starts up faster It was two years ago that I used Haskell last and the LSP was often crashing. But in general there were always lots of 'niggles' with all parts of the tool-chain that just killed developer flow. As I state in a sibling comment, the tooling is on the right trajectory, it just isn't there yet. So, this isn't the main reason to not do Haskell.
  • mhitza 2y ago
    Coincidentally I've started using the Haskell LSP around two years ago, and crashing is not one of the issues I've had with it. Since you mention F#, and C# in your previous comment, are you on the Windows platform? Maybe our experience different because of platform as well. Using GHCup to keep in sync compatible versions of GHC, Cabal and the LSP probably contributed a lot to the consistent feel of the tooling. I use the Haskell LSP for its autocompletion, reporting compile errors in my editor, and highlighting of types under cursor. There are still shortcomings with it that are annoyances: * When I open up vim, it takes a good 5-10 seconds (if not a bit more) until the LSP is finally running. * When a new dependency is added to the cabal file, the LSP needs to be restarted (usually I quit vim and reopen the project). * Still no support for goto definition for external libraries. The workaround I have to use in this case is to `cabal get dependency-version` in a gitignored directory and use hasktags to keep a tags file to jump to those definitions and read the source code/comments. The later two have open GitHub issues, so at least I know they will get solved at some point.
    • louthy 2y ago
      > Since you mention F#, and C# in your previous comment, are you on the Windows platform? Linux Mint.
    • runevault 2y ago
      > Since you mention F#, and C# in your previous comment, are you on the Windows platform? Since dotnet core (now dotnet 5+), the Microsoft version of dotnet has not been tied to windows outside a few exceptions like old Windows UI libraries (WPF/WinForms) and stuff like WCF once they revived it.
    • devmunchies 2y ago
      I’ve been using f# in production for 4+ years and haven’t used windows in like 15 years. Speaking of LSP, the lsp standard is developed by Microsoft so naturally any dotnet language will have good lsp support.
  • nh2 2y ago
    The Haskell LSP crashes less often now than 2 years ago. It isn't perfect yet, but pretty usable for us.
  • rtpg 2y ago
    Has Scala gotten better because I remember it being quite painful in the past (tho probably mostly due to language issues more than anything)
    • draven 2y ago
      Well, there's Intellij IDEA with the scala plugin, and it's pretty good. I regularly debug my code in the IDE with conditional breakpoints, etc. SBT still makes me want to throw the laptop through the window.
      • pxc 2y ago
        In the pre-LSP era, I worked as a novice Scala developer, and I didn most of my Scala work in Emacs with ENSIME. It was pretty good. I imagine the language server is pretty usable by now.
    • weebull 2y ago
      Scala's has made some horrible language compromises in order to live on the JVM in my opinion.
      • bad_user 2y ago
        I'd argue that Scala's "compromises" in general make it a better language than many others, independent of the JVM. But we can talk specifics if you want. Name some compromises.
    • bad_user 2y ago
      The IntelliJ IDEA plugin for Scala is built by Jetbrains, so it has official support. It has its quirks, but so does the Kotlin plugin. Sbt is better than Gradle IMO, as it has a saner mental model, although for apps you can use Gradle or Maven. Sbat has had some awesome plugins that can help in bigger teams, such as Scalafmt (automatic formatting), Scalafix (automatic refactoring), Wartremover and others. Scalafmt specifically is best in class. With Sbt you can also specify versioning schemes for your dependencies and so you can make the build fail on problematic dependency evictions. Scala CLI is also best in class, making it comfortable to use Scala for scripting – it replaced Python and Ruby for me: https://scala-cli.virtuslab.org/ https://scala-cli.virtuslab.org/ Note that Java and Kotlin have Jbang, but Scala CLI is significantly better, also functioning as a REPL. Worth mentioning that other JVM languages hardly have a usable REPL, if at all. The Scala compiler can be slow, but that's when you use libraries doing a lot of compile-time derivation or other uses of macros. You get the same effect in similar languages (with the exception of Ocaml). OTOH the Scala compiler can do incremental compilation, and alongside Sbt's support for multiple sub-projects or continuous testing, it works fairly well. Scala also has a really good LSP implementation, Metals, built in cooperation with the compiler team, so you get good support in VS Code or Vim. To get a sense of where this matters, consider that Scala 3.5 introduces "best effort compilation": https://github.com/scala/scala3/pull/17582 https://github.com/scala/scala3/pull/17582 I also like Kotlin and sadly, it's missing a good LSP implementation, and I don't think Jetbrains is interested in developing it. Also you get all the tooling that's JVM specific, including all the profilers and debuggers. With GraalVM's native image, for example, Scala fares better than Java actually, because Scala code relies less on runtime reflection. I'd also mention Scala Native or ScalaJS which are nice to have. Wasm support is provided via LLVM, but there's also initial support for Wasm GC. So to answer your question, yes, Scala has really good tooling compared to other languages, although there's room for improvement. And if you're comparing it to any other language that people use for FP, then Scala definitely has better tooling.
• deleted 2y ago
  [deleted]
• lkmain 2y ago
  I haven't yet felt the need for third party tooling in OCaml. OCaml has real abstractions, easily readable modules and one can keep the whole language in one's head. Usually people do not use objects, and if they do, they don't create a tightly coupled object mess that can only be unraveled by an IDE.
• mattpallissard 2y ago
  > Experimenting lately with OCaml, feels like Haskell's tooling is more mature. I feel like OCaml has been on a fast upward trajectory the past couple of years. Both in terms of language features and tooling. I expect the developer experience to surpass Haskell if it hasn't already. I really like Merlin/ocaml-lsp. Sure, it doesn't have every LSP feature like a tool with a lot of eyes on it, such as clangd, but it handles nearly everything. And yeah, dune is a little odd, but I haven't had any issues with it in a while. I even have some curve-ball projects that involve a fair amount of C/FFI work. My only complaint with opam is how switches feel a little clunky. But still, I'll take it over pip, npm, all day. I've been using OCaml for years now and compared to most other languages, the experience has been pretty pleasant.
  • mhitza 2y ago
    My little experiments with OCaml have been pleasant thus far (in terms of language ergonomics), but on the tooling side Haskell (or rather I should say GHC) is pretty sweet. For what I had to do thus far, at one point I needed to step debug through my code. Whereas in GHC land I reload my project in the interpreter (GHCi or cabal repl), set a break point on function name and step through the execution. With OCaml I have to go through the separate bytecode compiler to build it with debug symbols and the I can navigate through program execution. The nice thing is that I can easily go back in execution in flow ("timetravel debugging"), but a less ergonomic. Also less experienced with this flow, to consider my issues authoritative. I don't have that much experience with dune (aside from setting up a project and running dune build), but one thing that confused me at first, is that the libraries I have to add to the configuration do not necessarily match the Opam package names. The LSP is fast, as mentioned before, it supports goto definition, but once I jump to a definition to one of my dependencies I get a bunch of squiggly lines in those files (probably can't see transitive dependency symbols, if I where to guess). I can navigate dependencies one level deeper than I can with the Haskell language server, though. I actually want to better understand how to build my projects without Dune, and probably will attempt to do so in the future. The same way I know how to manage a Haskell project without Cabal. Feels like it gives me a better understanding of the ecosystem.
• innocentoldguy 2y ago
  Elixir’s tooling is awesome, in my opinion.
  • travisgriggs 2y ago
    I’m curious what you think is awesome about its tooling? For me, mix is capable enough, but I consider the IDE story to be pretty lacking actually.