Startups Using Kotlin in Boston
Via their job posts and information submitted by startups themselves, these are the Boston Kotlin startups we've found.
Interested in other technologies? Browse or search all of the built-in-boston tech stacks we've curated.
Tech Stack Highlights
Spring Boot – We field a number of microservices on top of Spring Boot. Its convention-over-configuration design allows us to focus on business logic rather than plumbing. We’re particularly looking forward to the Spring team’s upcoming first-class support for Kotlin, which we’ve been gradually introducing as a safe, expressive alternative to Java 8.
React + Redux – We’ve built a highly interactive and engaging front-end using React and Redux. The resulting code is modular, easy to reason about, flexible, and composable.
Kafka – We use Kafka as our primary message bus. Unlike most “big data” technologies, Kafka has allowed us to scale without imposing a notable increase in complexity. In fact, becuase its append-only architecture allows us to view topic contents long after the message has been “consumed”, Kafka allows us to significantly improve monitoring and visibility over more traditional message buses (JMS, AMQP). We’re looking forward to experimenting with Kafka Streams as a lightweight alternative to standalone stream processing frameworks such as Spark.
Zeppelin – We use Apache Zeppelin to query, aggregate, and visualize data across a number of heterogeneous data sources, including MySQL, ElasticSearch, and S3. We write ‘notebooks’ in Scala and SQL to drive Spark in creating these visualizations. These notebooks can be ad hoc or shared, versioned, and parameterized.
NiFi – We use NiFi as an orchestration layer to manage real-time data flows in a simple scaleable way. The framework provides us with the ability to easily monitor the progress of messages as they move through the processing pipeline and to replay messages should it be necessary.
Tech Stack Highlights
React and Redux – The skeleton and nervous system of our in-browser code. The combination of one-way data binding and functional state transitions has made our products much easier to build (and, more importantly, debug).
Elixir – Our persistent services are written in Elixir, a relatively young functional language built on the Erlang VM. It’s got lots of features to recommend it — immutability, actor-based concurrency with crash supervision, hot upgrades and rollbacks, built-in clustering, etc — but the syntax is also downright comfy and very productive. Elixir’s been great to us in the last year we’ve had it in production.
AWS Lambda and Serverless Framework – Lambdas are an amazingly cost-efficient way to implement services or event handlers that don’t require low latency or long execution times. We’ve recently begun to move our dozen-or-so Lambdas into the Serverless Framework, which automates their deployment and configuration. And the ease of working with Serverless Framework makes it likely that we’ll build a bunch more features with it.
DynamoDB – While we use a combination of data persistence layers (Postgres, Firebase, and S3 also play a part), we began to experience growing pains with our most frequently-updated data. We moved this workload from Postgres to DynamoDB last fall, and we’ve not only seen a 30-40% reduction in operating cost, but our response time is much more predictable, and our peak-traffic performance is between three and twenty times better.
Redis – We’re using Redis as the basis of a stats collection system. In particular, its implementation of the HyperLogLog cardinality estimation algorithm means that we can keep as many unique counters (e.g., daily active users for each customer) as we like without worrying much about disk space or CPU time.