I think the point in the space Glean hits well is efficiency/latency (enough to power real time editing, like in IDE autocomplete or navigation), while having a schema and query language generic enough to do multiple languages and code-like things. You can accurately query JavaScript or Rust or PHP or Python or C++ with a common interface, which is a bit nuts :D
Most clients hit the Glean server via the network (thrift/JSON) and then mostly via language bindings to the Glean query language, Angle. The shell is more for debugging/exploration.
Imagine an IDE plugin that queries Glean over the network for symbol information about the current file, then shows that on hover. That sort of thing.
We use this to power things like find-references or jump-to-def, "symbol search" and autocomplete, or more complicated code queries and analysis (even across languages). Imagine rich LSPs without a local checkout, web-based code queries, or seeding fuzzers and static analyzers with entry points in code.
Our focus has been on very large scale, multi-language code indexing, and then low latency (e.g. hundreds of micros) query times, to drive highly interactive developer workflows.
Facebook | C++/OCaml static analysis | | London, UK | Onsite | Full time
Work extending the open source Infer static analysis suite support for C++. We use Clang for the front-end and have an open role to work on this in general. The code is all OCaml. Expertise in C++ is highly desirable. The requirements are roughtly C++ AND (OCaml OR Haskell OR Static Analysis OR Formal Methods).
Standard Chartered | London and Singapore | Full-time and Contracting
10+ open positions for Haskell developers in the Strats team at Standard Chartered. 1 open position in the developer efficiency team working on our build system and tooling.
Standard Chartered | London and Singapore | Full-time and Contracting
10+ open positions for Haskell developers in the Strats team at Standard Chartered. 2 open positions in the developer efficiency team working on our build system and tooling.
Habitually rewriting things in applicative and/or pointfree is a sure sign of a junior Haskell dev. One who has never had to maintain someone else's code.
There are cases where it helps (e.g. structured parsing), but all too often this is simply obfuscation. Even if motivation is good -- learning new structures -- you still have to focus on cost/benefit of each change in structure.
git was first released in April 2005. We (Haskell community) were using dvcs through darcs for about 2 years prior to that. dvcs made a lot of sense to the Haskell open source world back then, as we didn't have servers, so central repos (like CVS or SVN) were out of the question. It had to be p2p to get off the ground.
Yeah, it could well be that you just care about latency hiding on e.g. network services. For that raw compute and memory is much less important than having a reasonable thread scheduler and cheap threads.
> It is very hard to construct a DSL and once established it is cast in stone
Not if you're using embedded DSLs, which are basically rich APIs supporting variables and control structures. They can be as fluid as simpler APIs, yet have strictly greater expressive power.