Visual… programming languages? Yikes.

If you mean for programming specifically, I… don’t, really. At most it would be for a quick sanity check on syntax in a language I don’t write often, for which Google is fine. But otherwise I rely on documentation and search features of the various language/tool-specific websites.

The tooling has improved dramatically since then. There’s now a full-fledged language server (https://haskell-language-server.readthedocs.io/en/stable/), ghcup (https://www.haskell.org/ghcup/) is now a thing for installing/managing different versions of GHC/cabal/HLS, there’s now formatters (https://github.com/tweag/ormolu) and cabal has modernized significantly and supports multi-package projects much more comfortably now. Nix-based Haskell infrastructure is also now pretty nice. There’s even stuff like https://github.com/srid/haskell-template/blob/master/flake.nix to very quickly get spun up on a new project using Haskell and nix, including vscode, formatter, HLS, and a full development shell with a bunch of useful commands.

Another great modern thing (which powers HLS) is that GHC can now emit .hie files for each file it compiled, which is basically a standardized representation of the AST for that module that can be consumed/manipulated programatically. Lots of tools can use this. One such tool that’s particularly useful is https://github.com/wz1000/HieDb, which constructs an sqlite database from the information in these files, so you basically can have an index of every symbol definition, reference, export, etc. all readily available to use however you want.

https://www.shellcheck.net/ is probably one of the most well-known.

https://simplex.chat/ is written entirely in Haskell.

https://pandoc.org/ is another big one.

https://serokell.io/blog/best-haskell-open-source-projects has a (non-exhaustive) list of a bunch more.

Haskell. It’s a fantastic language for writing your usual run of the mill DB-backed web APIs (and a bunch of other stuff like compilers, data processing, CLIs, even scripting) and can do a lot of things that other languages simply can’t (obviously not in terms of computation, but in terms of what’s possible with the type system).

I’ve been writing it professionally for a while and am very happy with it. Would be nice if the job market for it was a bit broader. You can definitely get jobs doing it, you just don’t have quite as broad of a pool to choose from.

It’s currently the best tool for doing UX/design work.

Briefly glancing through your code there’s a typo on line 37:

outlives_parsed = parse_trail_outlives(bouds.fetch('outlives', nil))

Of course this wouldn’t be an issue had you actually implemented it in Rust since such a thing wouldn’t compile. Not really a good reason to be using ruby for this.

Ah my bad, didn’t see that Rust was the implementation language. Carry on.

This is a community for Rust, not JavaScript. This doesn’t belong here.

Huh, you know what, maybe I’ll give something like that a try. In the past I’ve tried doing one worktree per branch, but it was a pretty big hassle since I’d have to copy over a bunch of files every time (stuff sitting in the directory but not version-controlled). Yeah it can be automated, but it didn’t seem worth it. But a persistent set of work trees that I can use to parallelize when needed sounds pretty good.

No, because raw-dogging JavaScript isn’t something grown-up software shops do.

If you instead made your lobby field a HashMap<String, MatchId>, then whenever you get an event from a known player, you can lookup the match they are in from the lobby map and use that to lookup other data about the match (such as the other players) via the matches field (assuming that was also changed to be a hashmap as described in my previous comment).

Could you not have a hashmap keyed on matches pointing to vectors of strings for the players in each match? Basically modeling the data how you want rather than relying on indexing.

Yeah, in most statically-typed languages this is simply the default behavior unless you specifically declare a field as optional.

For sure. If 32-year-old vim can handle multi-GB files smoothly, you don’t need a GPU.

Yup. Especially since it’s written in Rust… Like why? Rust has a great cross-platform story.

Haskell being so high really doesn’t make any sense. Experience level maybe?

It’s one of the tersest languages out there.

I quite like flakes on the whole, but there is still, in my opinion, a pretty big unsolved issue, in that it’s impossible to configure a flake. Some consider it a feature, and in some sense it is, but at the same time it incurs some pretty hefty drawbacks (admittedly, these are much more relevant for using nix as a build tool rather than as a package manager for an OS).

The packages you specify via the packages attribute are the ones it will build dependencies for, but not build. You want to return a list of packages selected from the argument attribute set, like

packages = hsPkgs: [hsPkgs.pkgA, hsPkgs.pkgB];

It’s never too late to learn about them. They’re super common in practice so it’s very helpful to know about them. A lot of things are a DAG, like tree data structures and dependency graphs. Having no cycles in a directed graph has a lot of nice properties too, like allowing one to use efficient graph traversal algorithms, topological sorting, or its transitive closure. It’s come up multiple times in my career so it’s definitely worth knowing imo.