5 ms·
Their support in the demo period sucked, their complex C++ support was lacking, they didn't integrate into modern C++ build systems well, and their prices were
by isityouyesitsme 3y ago
Their support in the demo period sucked, their complex C++ support was lacking, they didn't integrate into modern C++ build systems well, and their prices were insane.
They kept trying to push this "campaign" feature on us, which is an overly-complex auto-refactoring tool that couldn't even support our non-proprietary, well-known build system. For the cost of their license, we instead hired two developers for code refactors, who then went on to make other tooling, and we didn't need to hire someone to babysit their crappy service integration.
I would not say that they had found their niche when speaking to us. Perhaps it has gotten better.
- mardifoufs 3y ago2 devs for the price of the license?! How expensive are we talking about here?
- chefandy 3y agoIf it's true, I'd love to hear how many devs their marketing people say you'd have to hire to replace the functionality.
- CAP_NET_ADMIN 3y agoIt was 100USD per month per seat some time ago, with a high number of devs it may actually be beneficial to roll something on your own.
- isityouyesitsme 3y agoWe hired 2 junior developers for maybe 20K more total, in total compensation, than their original quote. But you (and child) comment made me realize that I don't remember the terms of the proposal, whether it was per year or for 2 years. So it might have been a 1:1, not 1:2. In the end, their product was just completely insufficient for our needs, and it was clearly just gluing open source tools together. The part we couldn't do as well was the front end, and they clearly put a lot of effort into it. It looked and worked nicely. But that didn't help us when they couldn't parse the code to populate it.
- __float 3y agoWhat build system did you use? I thought the JSON compilation database is relatively well supported to generate these days (e.g. used by the language server in VS Code).
- isityouyesitsme 3y agoI don't want to go into specifics. The problems we encountered were that they could not rewrite the targets in our build system for the automated refactoring, and any missing include path at all would cause the clang-based tooling they were using to barf. We just asked ourselves why we would spend so much money on a product when we still had to solve all of the fundamental problems ourselves. We liked the UI, but it wasn't worth the insane license fee.
- typesanitizer 3y agoBased on your use of "campaign" (the older name for Batch Changes), it sounds like you were looking into Sourcegraph about 2.5 years ago or before that. Lots has changed since then. We recently released a new indexer scip-clang (https://about.sourcegraph.com/blog/announcing-scip-clang https://about.sourcegraph.com/blog/announcing-scip-clang), which we've used to successfully index large codebases like Chromium. The indexer relies on a JSON compilation database (same as our older indexer lsif-clang) which is easy to produce from CMake, Bazel, Meson, Make etc. We've also added support for cross-repo code navigation for C++ recently. (https://about.sourcegraph.com/blog/c-cpp-cross-repo https://about.sourcegraph.com/blog/c-cpp-cross-repo)
- isityouyesitsme 3y agoTypesanitizer, I just want to note that I'm not downvoting you. I found nothing objectionable about your comment. I'm unsure what the expectation is here. I'm allowed to say we had a poor experience, you should be allowed to say how you think you're addressing it.