VulCode

The technologies we write in, and the projects that show it

10 technologies, each with at least two projects in our repositories. For each: its projects on real screens, lines of code and changes merged into other people's projects.

Contributions

Technologies by where the code runs

Each has its own page with projects on real screens and a comparison with the alternatives. We only list ones where we have at least two projects.

Websites and web apps

What you see in a browser, and its back end.

Mobile apps

Native Android and iOS clients.

Desktop apps

Programs for Windows, macOS and Linux without a browser inside.

Back end and infrastructure

Cores, server agents and real-time services.

Bots and automation

Discord, scripts and monitoring.

How we choose the technology for a project

Five questions before the quote. We write the answers into the quote, so you know why you get this stack.

  1. Where does the code run?

    A browser, a phone, a computer, a client's server.

  2. Who will take it over?

    Your team, another vendor or us.

  3. How long should it live?

    A one-month campaign or a system for years.

  4. What is inside?

    Money, personal data, cryptography.

  5. The choice and the reason

    In the quote, in one paragraph.

What our code is made of

The lines added in the commits of our repositories, language by language. A language with a technology page leads to it.

5,375,614
lines we have written
26
languages in our repositories
50.0%
of the lines are TypeScript
51
repositories with TypeScript code

The need and the first choice

Rows from the choice tables of all 10 technology pages in one picture: the need on the left, the language we pick first on the right.

  1. A long-running service handling money
    Rust

    We write Rust where a bug costs the most: a hosting platform's core, a messenger's cryptography, a licence server and tools that run for years on other people's machines.

    TypeScript on Node: good, with more test discipline

  2. A terminal tool
    Rust

    Rust: one binary, no runtime.

    TypeScript on Node: needs Node on the user's machine

  3. A quick company site
    TypeScript

    React with prerendering: content in the first HTML, a fast interface.

    Rust: overkill

  4. An agent on thousands of machines
    Go

    Go: simple code, fast builds.

    Rust: good too, slower to start

  5. A WebRTC server
    Go

    Go: the mature pion library.

    Rust: fewer ready tools

  6. Thousands of connections and supervision
    Elixir

    Elixir: built into OTP.

    Go: written by hand

  7. Discord bot
    Python

    Python: discord.py, quick to start.

    Another language: TypeScript with discord.js is good too

  8. A WHMCS module
    PHP

    PHP: the only option.

    Node or Rust: not possible

  9. A Minecraft plugin
    Java

    Java: the most examples and libraries.

    Kotlin: works too

  10. An Android app with widgets and notifications
    Kotlin

    Kotlin and Swift: full access to the system's widgets and notifications.

    Web app: limited

  11. An iOS app with notifications
    Swift

    Native Swift: APNs with full control.

    Web app: web push once installed

  12. Desktop app
    C#

    Program size: smaller, no Chromium. Native feel: closer to the system.

    Electron: larger, with a whole browser

Our changes in other people's projects, by language

Merged changes are the best proof we know a language: the maintainer of someone else's project reviewed our code and merged it.

Week by week

  • Go
  • PHP
  • JavaScript
  • C#
  • Rust
  • Perl i JavaScript
  • Python
  • TypeScript

The languages of our changes

Languages with one project

In these languages we have one workshop project each, so they do not get their own page. Each is in the portfolio with a write-up.

Questions about technologies

About choosing a technology, who decides and the numbers on these pages.

Not sure which technology to pick?

Describe the project. We propose a stack with the reasoning and a free quote.