As long as your language has a reasonably mature ecosystem for what you want to do, almost any choice is reasonable.Īnd Haskell is already there! There are good web frameworks, good blog post explainers, good RPC libraries, and a good OAuth2 implementation. Pick the language you’re most comfortable in and can build fastest in. if you’re doing data science, use Python), language choice actually doesn’t matter that much. if you’re building a database, use a fast language) or domain (e.g. Unless you have mission-critical constraints around performance (e.g. Effect tracking also enabled us to build a great debugging feature called “replay logging” that allows us to replay an analysis run from debug logs, which makes debugging customer issues much easier. Megaparsec allowed us to build parsers with very high confidence in their correctness, and effect tracking and our effect system made testing these parsers at various levels (unit, integration, end-to-end) really simple. Haskell was a particularly good fit for this use case because of its great parsing libraries and great testing story. Our CLI also gets shipped on-premises, so we don’t have the freedom to do constant incremental updates each release we make has to be rock solid. We write a lot of parsers in the CLI, and a lot of those parsers have really complicated interactions with compilers and build tools. You could get away with writing everything in the IO monad (just write JavaScript in Haskell), and you’d still have a language that feels imperative but has much better jump-to-definition support and static safety guarantees.įor us, the first use case that made us seriously consider adoption was parsing. The library ecosystem has most of what you need. Static types and effect tracking make for a really good refactoring and testing story. I currently lead our Platform team, working on improving the performance, stability, and correctness of our underlying data and analysis systems.Įven without a specific use case, Haskell is a pretty good general-purpose language. I joined FOSSA in 2017 as an early engineer, and have played various roles in engineering since then. FOSSA automates away the checklist of extra compliance issues that engineering teams have to deal with when they use open source, so that engineers can spend their time actually building stuff. It also provides a bunch of useful tools on top, aggregating risk information (like licensing and vulnerabilities), providing a policy engine to figure out which dependencies are compliant, providing integrations (like a GitHub PR check and an IDE integration) so developers get warned about non-compliant dependencies early, and automatically generating required reporting to help your team stay compliant. It works across all of your languages and all of your projects and integrates with zero configuration. Today, it’s solved through the sheer willpower of spreadsheets, paperwork, tickets, and process.įOSSA builds a tool that integrates with existing compiler, build, and CI systems to automatically determine, track, and analyze your dependencies. At its worst, it becomes a 2-week fire drill that happens every time a major release gets done, as other teams pester engineers to figure out what dependencies are being used, which are actually okay to use, and how to remove the bad ones.įor large companies with hundreds of teams and thousands of services, each using different languages and build tools, this is an enormous effort. At many large companies, this manifests in other functions (security, compliance, etc.) becoming gatekeepers in the engineering release process. When engineering teams use open source, it exposes them to legal (“is this a license like GPL v3 or AGPL?”), security (“does this have a vulnerability?”), and code quality (“is this still maintained?”) risks.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |