bloop VS Wartremover

https://github.com/BloopAI/bloop Is fully open source and has full text + regex search built on tantivy fyi

Thanks! Bloop really helped with the documentation! they index your code base and uses RAG locally to talk against it. It works shockingly well.

In this blog post, I’ll be comparing 3 distinct AI-first code search tools I recently came across: Cody (developed by late-stage startup, Sourcegraph), SeaGOAT (an open-source project that was trending on HN last week), and Bloop (an early-stage YC startup). I’ll be evaluating them along the dimensions of user-friendliness as well as their accuracy.

If you're confused about any of the code snippets above, you can check out bloop.ai and phind.com (along with its VSCode extension) to answer any of your questions about the repository, noting that both have free plans.

COMPANY: bloop (https://bloop.ai)

bloop (YC S21) | Rust AI Engineer | Onsite | London, UK

We're a YC + tier-1 VC backed startup, working on a AI chat assistant for software developers that can answer questions about any large codebase.

About you: you hack around with GPT on the weekend, maybe you even fine-tune some of these new open source models. But you're also a solid programmer, capable of not just prototyping a nice demo but also shipping performant code that can scale. You're probably quite good at what you do, maybe you were top of your class, or maybe you rose the ranks to your comfortable management role, but yearn for the days of writing code, redbull and deploying on a Friday.

We're a small team, looking for one individual to join us in London, in-person at least 3 days per week.

Please reach out to me at join [at] bloop [dot] ai with "HN AI Engineer" in the subject line and a note about why this is exciting and a link to your portfolio or linkedin/resume.

P.S. Our stack is Rust, so it's likely the role will go to a candidate with Rust experience but if you think you have something to offer that compensates for lack of Rust we should chat anyway!

https://github.com/BloopAI/bloop

Bro let me turn your life inside out: https://bloop.ai

Another example is Bloop, it is a code search engine built on top of tantivy and qdrant.

Bloop is a developer assistant that uses GPT-4 to answer questions about your codebase (https://github.com/BloopAI/bloop)

By contrast, Java and ECMAScript are essentially what we might call "classical" imperative OOP languages, although ECMAScript reveals much more of its Lisp-inspired "map/filter/reduce" FP roots. IMO ESLint is essentially table stakes for working with ECMAScript, but honestly, I wouldn't stop there and would insist on working in TypeScript, including some of the tooling for ESLint specifically for TypeScript, dialing type-safety up to 11, effectively like using Wart Remover with Scala.

I'm awed by the maturity of the Scala 2 compiler. Every minor version in the 2.13 series adds a new linting improvement. You can see that if you have sbt-tpolecat in your project. I'm always happy to see that some option from Wartremover is no longer used.

I was recently trying to move away from Scapegoat to Wartremover and I got bitten by this bug which is particularly prevalent in codebases using Typelevel libraries.

There is also wartremover but you cannot run it separately from your compile command.

or `NonUnitStatements` without explicit annotation.

This effectively locks you into writing pure code (you can extend the linter to cover other things like not using `Future` or not using Java libs outside of `MonadError` from cats[4]). The linters operate on typed ASTs at compile time, and have plugins for the most popular scala build tools. Coupled with `-XFatalWarnings', you can guarantee that nothing unexpected happens unless you explicitly pop the escape hatch, for the most part.

You can still bring in external libraries that haven't been compiled with these safties in place, so you aren't completely safe, but if you use ZIO[5]/Typelevel[6] libraries you can be reasonably assured of referentially transparent code in practice.

There are three schools of thought, roughly, in the scala community towards the depth of using the type system and linters to provide guarantees and capabilities, currently:

1) Don't attempt to do this, it makes the barrier to entry to high for Scala juniors. I don't understand this argument - you want to allow runtime footguns you could easily prevent at compile time because the verifiable techniques take time to learn? Why did you even choose to use a typesafe language and pay the compilation time penalty that comes with it?

2) Abstract everything to the smallest possible dependency interface, including effects (code to an effect runtime, F[_] that implements the methods your code needs to run - if you handle errors, F implements MonadError, if you output do concurrent things, F implements Concurrent, etc.) and you extend the effect with your own services using tagless final or free.

3) You still use effect wrappers, but you bind the whole project always to use a concrete effect type, avoiding event abstraction, thus making it easier to code, and limiting footguns to a very particular subset (mainly threadpool providers and unsafeRun or equivalent being called eagerly in the internals of applications).

My opinion is that smallest interface with effect guarantees (#2) is best for very large, long maintenance window apps where thechoice of effect runtime might change(app), or is out of the devs' control (lib); and #3 is best for small apps.

TL/DR; You can go a really, really long way to guaranteeing effects don't run in user code in scala. Not all the way like Haskell, but far enough that it's painful to code without conforming to referential transparency.

1. https://github.com/scalacenter/scalafix

2. https://github.com/scalaz/scalazzi

3. http://www.wartremover.org/

4. https://typelevel.org/cats/api/cats/MonadError.html

5. https://zio.dev/

6. https://typelevel.org/