
## A Good Morning

One fine day, we woke up to a page at 7AM that one of our non-critical services are returning more 500s than the usual. In fact, 500s constituted more than 50% of the responses, and that's why we were paged. This service ran smoothly for more than a month now, and we had just enabled message publishing in that service last evening. Suspecting this would be the cause, we quickly disabled the functionality by turning a feature flag off and the 500s gradually came down until the alert automatically turned itself off.

Once we were completely awake and caffeinated, we started looking into the logs of the service and a few things stood out:

1. The entries with `level=ERROR` had a spike in the duration of increased 500s. The errors were 502 actually, since the service was quite unavailable during that time.
2. Those log entries were specifically coming from the MQ client - we use self-hosted RabbitMQ
3. The logs were repeatedly saying
   - MQ sending us `ECONNRESET`
   - Our connection retry mechanism kicking in, and becoming successful sometimes, failing other times
   - A seemingly crpyic error message - `connection closed: FRAME_ERROR - type 65, all octets = <<>>: {frame_too_large,1342177289,4088} (501)`

Our service is written in NodeJS + TS, and we use [`@cloudamqp/amqp-client`](https://www.npmjs.com/package/@cloudamqp/amqp-client) to communicate with MQ. We subscribe to [`AMQPChannel`](https://cloudamqp.github.io/amqp-client.js/classes/AMQPChannel)'s [`onError`](https://cloudamqp.github.io/amqp-client.js/classes/AMQPChannel.html#onerror) method to kick in our connection retry mechanism. Our retry mechanism is quite raw and simple and does not take of messages that would be sent during the retry window - they would be lost. The retry mechanism keeps track of a counter, and backs off exponentially. Once the retry is successful, the counter is reset and everything is back normal.

While the retry mechanism seemed to work fine in this case (***spoiler**: it wasn't*), which we were happy about, the number `1342177289` worried us. We have configured the maximum message size as `4088` bytes, which is more than sufficient in almost all the cases. What we were seeing instead was a message of around 1GB, which would be close to impossible! I joked that I'm 99.99% confident that 1GB message would not be the case, but left the remaining probability for me to be amused.

We scoured the logs of the service and its historical data and nothing could come to as close as a GB, or even a few 100KBs. Turning back to logs, We noticed that same number `1342177289` was repeated multiple times. It is highly improbable that we get multiple 1GB ish messages with the same byte count - we never retry publishes as well.

Having gone through articles of magic numbers appearing during crashes, I became particularly interested in the number `1342177289` - would it be the case it was a legit packet size and _somehow_ one or more bits got corrupted to become this humongous big number? I started looking into the bits then:

```
0101 0000 0000 0000 0000 0000 0000 1001
```

Weird - there are more zeros than ones - yes. But 2 bits at Most Significant side should not haven been set accidentally. Meanwhile, we have pasted the number into Google and [it only brought up results **ONLY** related to RabbitMQ!](https://www.google.com/search?q=1342177289)

## What had happened?

[John Eckersberg makes a good job at explaning what this number means](https://john.eckersberg.com/debugging-rabbitmq-frame_too_large-error.html). To make sense of this number, we need to include `type 65` into the picture as well -- `65` is ASCII `A`. Then there is channel number `19793`, which was not included in this log. These three numbers combined together makes out the string `AMQP` followed by the numbers `009`. For reference, the AMQP init packet expects `AMQP0091` in the header (`0091` being the version and represented as a raw number). We can see parts of it in our number:

```bash
1342177289
= 0101 0000 0000 0000 0000 0000 0000 1001
= 0x50 0x00 0x00 0x09
= "P" 0 0 9
```

This means that we were sending initialization packet after the connection was initialized. For reference, here is how our retry looked like:

```ts
class MqClient {
  private readonly client: AMQPClient
  // We keep a single connection
  private readonly connection: AMQPConnection | null = null
  private retryCount = 0

  public MqClient(url: string) {
    this.client = new AMQPClient(url)
  }

  // Users SHOULD call this
  public async init() {
    this.connection = await client.connection()
    this.connection.onEror(this.retry)
    this.retryCount = 0
  }

  private async retry() {
    this.retryCount += 1
    // Exponential backoff
    await sleep(2 ** this.retryCount * 1000 /*ms*/)
    await this.init()
  }
}
```

While this code looks good at the surface, **if an error happens during retry, since the retry handler is already registered, it is called again - now multiple retry sequence are running concurrently**. And it is entirely possible that a retry happens on already initialized connection - and that's what has happened.

## The Fix

The fix is simple, clear connection and associated handlers before attempting a retry. This is akin how React's `useEffect` wants us to [clean up all the subscriptions, callbacks etc when the component is unmounting](https://react.dev/learn/synchronizing-with-effects#how-to-handle-the-effect-firing-twice-in-development).

However, that's not the end of the story. We observed that MQ connections were being closed when the traffic to our service was mere 20% more than usual. We were running 3 pods in Kubernetes and observed our pods were running over limit on CPU utilization. Scaling them to 16 did bring things back to normal at 100% CPU utilization. We need to further investigate why an act of publishing the message uses up the resources so much. Until then, we plan to use [`HorizontalPodScalar`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) on CPU utilization to scale up the service on load.


The day when we received a 1GB message on our RabbitMQ (did we?) and how we handled it

1342177289

As a software engineer, I helped build a few systems and products at work this year. Here I present a high level overview of my learnings and thoughts without specificities to the products I built.

2023 - Year In Review


Suppose we have an object, and one of its fields an array. Taking every array
elements and adding the rest of the objects keys is _exploding_ the object
w.r.t that array element. For example, if we have an object `{university: "XYZ", batch: 2019, students: [{name: "Alice"}, {name: "Bob"}]}`, exploding it
w.r.t `students` results in `[{university: "XYZ", batch: 2019, name: "Alice"}, {university: "XYZ", batch: 2019, name: "Bob"}]`.

We can encounter the need for the explosion in many cases. For example, let's
have an e-commerce order object, where it contains the individual items in an
array. When we want to process individual items with the order details,
explosion is the suitable operation.

With understanding the _explode_ operation, let's proceed to define our goals
clearly w.r.t to the result and type-safety

## The Goals

- We want to have a function `explode(object, key)` which does the explosion
- The `key` not being present in `object` should result in type error
- The `key` not being array should result in type error
- The returned array must be appropriately typed

We are resorting to type errors in most of the cases as we can be confident
about the function inputs when we run the code inside our app. If we want to
ship this function in a library, we need to do runtime checks as well, as there
is a possibility of this code called in plain JS without any typechecking. In
this post, for the sake of breivity, We are omiting the runtime checks.

## Solution without Types

The problem of explosion is easy and straightforward - we extract the value at
the key, map over the array and add rest of the properties to every object in
it.

```javascript
const explode = (object, key) => {
  const { [key]: array, ...rest } = object
  return array.map((item) => ({
    ...item,
    ...rest,
  }))
}
```

## Moving to the Type Realm

Now, let's add the types to the `explode` function, starting with the basics to
match the JS schematics:

```typescript
const explode = (object: object, key: string) => {
  const { [key]: array, ...rest } = object
  return array.map((item) => ({
    ...item,
    ...rest,
  }))
}
```

TS yells us at about two problems here:

1. We don't know if the `key` is indeed a key of the `object`

2. By virtue of that, `array` has type `any`, which makes `item` implicitly
   `any`.

Let's first restrict `key` to be a valid key of `object`. Since our parameters
have dependency now, we need to make our function generic. If the generic
parameter is `T`, we can either mark `object` or `key` as `T`. For the reasons
that will become evident later, let's mark the `object` as `T`. With that,
let's also add generic _constraint_ on `T` to be a subtype of `object`.

```typescript
const explode = <T extends object>(object: T, key: keyof T) => {
  const { [key]: array, ...rest } = object
  return array.map((item) => ({
    ...item,
    ...rest,
  }))
}
```

With this, we restrict `key` to be a valid key of `T`, not any string. This
solves the problem #1. We still need to solve problem #2. Before doing that,
let's first restrict `key` to only the keys where value is an array.

## Hello, Key Mapping!

Let's first understand how `keyof T` looks like before filtering it:

```typescript
type UniversityRecord = {
  university: string
  batch: number
  students: { name: string }[]
}

type Keys = keyof UniversityRecord
// "university" | "batch" | "students"
```

Thus, `Keys` is a union of strings, and it does not recursively descend into
the object structure, which is as expected. Now, can we loop over the union?
**Unfortunately not**. To understand why, remember there is no _order_ in
unions - `a | b | c` as `b | c | a` and etc. To loop over the keys and filter
them out, we can use [_key
remapping_](https://www.typescriptlang.org/docs/handbook/2/mapped-types.html#key-remapping-via-as)

```typescript
type ArrayKeys<T extends object> = keyof {
  [K in keyof T as T[K] extends any[] ? K : never]: unknown
}
```

There are so many things going on here even if the code is deceptivly small.
Let's break down the things happening here:

- We are looping over every key `K` in `keyof T` in a mapping context (inside
  `[]`). Remember that such loop was not possible with unions.
- We are remapping the key using `as` keyword. If we map the key to `never`, it
  will be excluded
- Remapping supports conditions too - we check if `T[K]` is an array. If so, we
  keep `K` as it is; otherwise, we will exclude it using `never`.

Using this type helper, we can now define `explode` function as:

```typescript
const explode = <T extends object>(object: T, key: ArrayKeys<T>) => {
  const { [key]: array, ...rest } = object
  return array.map((item) => ({
    ...item,
    ...rest,
  }))
}
```

Now, we have to solve one problem: TS _still_ does not know that `object[key]`
is an array. While we can do further type manipulations, we can use runtime
functions to solve this.

```typescript
const explode = <T extends object>(object: T, key: ArrayKeys<T>) => {
  const { [key]: array, ...rest } = object
  return Array.isArray(array) ? array.map((item) => ({ ...item, ...rest })) : []
}
```

By adding `Array.isArray`, the `array` is treated as `any[]`. TS defines
`isArray` as a [_type
predicate_](https://www.typescriptlang.org/docs/handbook/2/narrowing.html#using-type-predicates)
with the following declaration:

```typescript
function isArray(arg: any): arg is any[]
```

When `isArray` returns `true`, TS knows that the `arg` is `any[]`, so we can
access `map` and `item` is infered as `any`. Let's try our new function
definition to check if argument types work properly:

```typescript
const res1 = explode(
  {
    university: 'XYZ',
    batch: 2019,
    students: [{ name: 'Alice' }, { name: 'Bob' }],
  },
  'university'
) // type error

const res2 = explode(
  {
    university: 'XYZ',
    batch: 2019,
    students: [{ name: 'Alice' }, { name: 'Bob' }],
  },
  'students'
) // no error
```

Well, so far so good. But if we check the return type of `explode`, it is
`any[]`, which makes it less useful in practice. Let's solve that by adding a
return type to it.

## Enter Type Gymnastics

We have following information about `explode(object, key)`:

- It returns an array (well, TS is intelligent to know that already, as it
  infers `any[]` as the return type)
- Every element of the array is an object.
- The object is derived by concatenating two objects:
  1. `object` with `key` removed
  2. the type of elements of `object[key]`

With this information, we can write a type helper `Explode`:

```typescript
type Explode<T extends object, K extends keyof T> = T[K] extends any[]
  ? (Omit<T, K> & T[K][number])[]
  : never
```

Few interesting things are happening here:

- We constrint `K` to be `keyof T`, not `ArrayKeys<T>`. Using `ArrayKeys` here
  does not add any useful information as TS does not get to know `T[K]` is an
  array. Thus, we choose a simpler path.
- We do the check `T[K] extends any[]` again, due to the reason explained
  above. If it does not, we return `never`. This case _never_ happens if `K
extends ArrayKeys<T>`
- If the check passes, we _omit_ `K` from `T` and intersect with the
  constituent type of `T[K]`
- To get the constituent type of `T[K]`, we index it on `number`, as arrays are
  indexed based on number

Now, we can proceed to type the `explode` function completly:

```typescript
const explode = <T extends object, K extends ArrayKeys<T>>(
  object: T,
  key: K
) => {
  const { [key]: array, ...rest } = object
  return (
    Array.isArray(array)
      ? array.map((item) => ({
          ...item,
          ...rest,
        }))
      : []
  ) as Explode<T, K>
}
```

It looks little bit different from our above definition. Apart from the `as
Explode<T,K>` cast, we typed `key` with `K` where `K extends ArrayKeys<T>`.
Typing `key` as `ArrayKeys<T>` and passing `typeof key` to `Explode` will keep
the generic argument to `Explode` as `ArrayKeys<T>`, not the specific literal
type that is passed in `key`. With this, we can proceed to _explode_!

## Testing

Let's call `explode` few times to check if everything works well. For testing,
let's assume we have an e-commerce order object:

```typescript
const order = {
  type: 'Order',
  customer: {
    name: 'Alice',
    address: '123 st.',
  },
  items: [
    {
      id: '111',
      name: 'Long sleeve T Shirt',
      price: 15,
      currency: 'USD',
    },
    {
      id: '232',
      name: 'Jeans',
      price: 12,
      currency: 'USD',
    },
  ],
  offers: [
    {
      code: 'FIRST-CUSTOMER',
      discountPercentage: '20',
    },
    {
      code: 'REFFERAL',
      discountPercentage: '10',
    },
  ],
}
```

As per our expectations, `explode` on this object should work for `items` and
`offers`, but not on other keys:

```typescript
const result1 = explode(order, 'type') // type error
const result2 = explode(order, 'items') // works
/*
const result2 = [
  {
    id: "111",
    name: "Long sleeve T Shirt",
    price: 15,
    currency: "USD",
    type: "Order",
    customer: {
      name: "Alice",
      address: "123 st.",
    },
    offers: [
      {
        code: "FIRST-CUSTOMER",
        discountPercentage: "20",
      },
      {
        code: "REFFERAL",
        discountPercentage: "10",
      },
    ],
  },
  {
    id: "232",
    name: "Jeans",
    price: 12,
    currency: "USD",
    type: "Order",
    customer: {
      name: "Alice",
      address: "123 st.",
    },
    offers: [
      {
        code: "FIRST-CUSTOMER",
        discountPercentage: "20",
      },
      {
        code: "REFFERAL",
        discountPercentage: "10",
      },
    ],
  },
]
*/
const result3 = explode(order, 'offers') // works
/*
const result3 = [
  {
    code: "FIRST-CUSTOMER",
    discountPercentage: "20",
    type: "Order",
    customer: {
      name: "Alice",
      address: "123 st.",
    },
    items: [
      {
        id: "111",
        name: "Long sleeve T Shirt",
        price: 15,
        currency: "USD",
      },
      {
        id: "232",
        name: "Jeans",
        price: 12,
        currency: "USD",
      },
    ],
  },
  {
    code: "REFFERAL",
    discountPercentage: "10",
    type: "Order",
    customer: {
      name: "Alice",
      address: "123 st.",
    },
    items: [
      {
        id: "111",
        name: "Long sleeve T Shirt",
        price: 15,
        currency: "USD",
      },
      {
        id: "232",
        name: "Jeans",
        price: 12,
        currency: "USD",
      },
    ],
  },
]
*/
```

We can also check the output types of `result2` and `result3`

```typescript
type Simplify<T> = T extends object
  ? {
      [K in keyof T]: Simplify<T[K]>
    }
  : T

type Result2 = Simplify<typeof result2>

/*
type Result2 = {
  type: string
  customer: {
    name: string
    address: string
  }
  offers: {
    code: string
    discountPercentage: string
  }[]
  id: string
  name: string
  price: number
  currency: string
}[]
*/

type Result3 = Simplify<typeof result3>

/*
type Result3 = {
  type: string
  customer: {
    name: string
    address: string
  }
  items: {
    id: string
    name: string
    price: number
    currency: string
  }[]
  code: string
  discountPercentage: string
}[]
*/
```

We can see that the type result matches the type of execution result, which
made `result2` and `result3` strongly typed, and, caught invalid key in
`result1`, making our `explode` function robust in type domain.


We explore the operation of exploding an object in this post, and make it robust by adding strong typing for its inputs and output

Exploding with Type Safety


While exploring Scala, one of the features that caught my eyes was that
functions can accept two sets of arguments. Typically, we write `function
name(argumentList)` in most languages. Scala goes one step ahead and allows
`function name(argumentList)(implicitArgumentList)`. In this article, we shall
explore implicit arguments from a Scala-newbie perspective. meaning that we
won't dig deep into architectural patterns and theoretical implications,
rather, we explore them from a syntax and syntax-sugar perspective.

## A First Dive

Let's write a function to concatenate a list of strings with a separator. As a
good first step, we write this as a function accepting two arguments and a
return value

```scala
def concatStrings(strings: Seq[String], separator: String): String = {
  strings.foldRight("") {_ + separator + _}
}
```

Several things are going on here, let's break them down one by one:

- Scala uses `[]` to denote generics; thus, `Seq[String]` is a `Seq` of
`String`s

- The return value is the value of the last line of the function; writing
`return` is optional

- `foldRight` is similar to `reduce` function in JS, its first argument is the
initial value `""`

- `foldRight` takes a reducer function as a
[_curried_](https://docs.scala-lang.org/tour/multiple-parameter-lists.html)
argument

- The reducer function is of type `(String, B) => B`, The type `B` comes from
the initial value, which is also `String` now

- The funny `_`s are a shorthand to access function arguments; the First `_` is
of type `String`, and the second `_` is of type `B` (= `String`). You can't
write a third `_`,  that's an error :sweat_smile:

- `{...}` is a shorthand for the funciton body, otherwise you would have
written `strings.foldRight("")((a, b) => a + separator + b)`; Notice two set of
arguments `foldRight()()`, don't worry, we will address it right away :smile:

Then, we invoke this function and get a return value from anywhere.

```scala
def main(args: Array[String]): Unit = {
  val strings = Seq("Hello", "World")
  val result = concatStrings(strings, "+")
  assert(result == "Hello+World+") // The extra + is because of foldRight
}
```

## Hello Implicit!

Let's make our function `concatStrings` to accept an implicit `separator`
argument. The function body looks similar to the previous case, excpet the
argument list:

```scala
def concatStrings(strings: Seq[String])(implicit separator: String): String = {
  strings.foldRight("")((a, b) => a + separator + b)
}
```

The second set of arguments begins with the `implicit` keyword and marks them
as _implicit_. The implicit arguments are inferred from the scope at
compile-time and passed to the function as an argument. To make it clear, let's
look at the invocation of our new `concatStrings` function.

```scala
def main(args: Array[String]): Unit = {
  val strings = Seq("Hello", "World")
  implicit val delimiter: String = "+"
  val result = concatStrings(strings)
  assert(result == "Hello+World+")
}
```

Here, we are creating a constant named `delimiter` of type `String`, which is
also declared as `implicit`. When the compiler encounters the call to
`concatStrings`, it looks for values of type `String` in the scope, which is
marked as `implicit`. In this case, it is the constant `delimiter`. Then, it is
passed as an argument to the function.

Let's play with implicit arguments by modifying the code.

### Missing Implicit

If the compiler can not find `implicit` values in the scope, it is an error.

```scala
def main(args: Array[String]): Unit = {
  val strings = Seq("Hello", "World")
  val result = concatStrings(strings)
  assert(result == "Hello+World+")
}
```

Here, the compiler complains with a readable, understandable error

```
could not find implicit value for parameter separator: String
	val result = concatStrings(strings)
```

### Multiple Implicits

If we have multiple `implicit` values of the same type, that is also an error.

```scala
def main(args: Array[String]): Unit = {
  val strings = Seq("Hello", "World")
  implicit val delimiter: String = "+"
  implicit val anotherDelimiter: String = "+"
  val result = concatStrings(strings)
  assert(result == "Hello+World+")
}
```

The error is

```
ambiguous implicit values:
 both value anotherDelimiter of type String
 and value delimiter of type String
 match expected type String
    val result = concatStrings(strings)
```

### Explicitly Implicit

We can also explicitly pass the `implicit` argument, as we did in `foldRight()`

```scala
def main(args: Array[String]): Unit = {
  val strings = Seq("Hello", "World")
  val result = concatStrings(strings)("+") // Notice the second argument list
  assert(result == "Hello+World+")
}
```

### Implicit from Upper Scope

Implicit values can be from upper scope as well:

```scala
object ImplicitHelper {
  def concatStrings(): String = {
    // Same as before
  }
}

object Main {
  implicit val delimiter: String = "+"
  
  def main(args: Array[String]): Unit = {
    val strings = Seq("Hello", "World")
    val result = ImplicitHelper.concatStrings(strings)
    assert(result == "Hello+World+")
  }
}
```

Here, the `object ...` is a singleton object, which can define methods as well.
Think of it as a `static` method. When we have implicit values present in
multiple scopes, the closest one is picked first (as expected :grin:).

```scala
object ImplicitHelper {} // Same as before

object Main {
  implicit val delimiter: String = "+"

  def main(args: Array[String]): Unit = {
    val strings = Seq("Hello", "World")
    implicit val delimiter: String = "_" // This one is picked
    val result = ImplicitHelper.concatStrings(strings)
    assert(result == "Hello_World_")
  }
}
```

Implicits can flow in from `import` as well, suppose we have an `object` named
`Config` in the file `Config`

```scala
// Config.scala
object Config {
  implicit val delimiter: String = ","
}
```

In our `Main.scala` (in which we write the `main` function),

```scala
// Main.scala
import Config._

object ImplicitHelper {} // Same as before

object Main {
  def main(args: Array[String]): Unit = {
    val strings = Seq("Hello", "World")
    val result = ImplicitHelper.concatStrings(strings)
    assert(result == "Hello,World,")
  }
}
```

Since we imported every member of the object `Config`, the compiler can match
the `delimiter` to the argument of `contactStrings`

## Viewing Implicit Arguments

Since the implicit arguments can be inferred directly from the code without
analyzing all the imports in all scopes, debugging others' code can be hard.
Fortunately, IntelliJ has an option to _explicitly_ show the `implicit`
variables :tada:. Just enable it from `View -> Show Implicit Hints` (you might
need Scala Plugin to do this). With this option enabled, the editor window
looks like this,

![IntelliJ Idea showing implicit
argument](https://media.graphassets.com/GSdBIKACSz2g9SW9r5ai)

Now you can follow the definition of the value as usual.

## Implicit Conversions

Since functions are the first-class citizens of Scala, they can be an
`implicit` argument as well, here is a sample:

```scala
import scala.language.implicitConversions

object ImplicitHelper {
  def toInt[A](argument: A)(implicit function: (A) => Int): Int =
function(argument)
}

object Main {
  implicit def length(string: String): Int = string.length

  def main(args: Array[String]): Unit = {
    val string = "Hii"
    val result = ImplicitHelper.toInt(string)
    assert(result == 3)
  }
}
```

Here, the object method `Main.length` is the implicit parameter to the `toInt`
function. Note that we also needed to import
`scala.language.implicitConversions`. To quote the [Scala
Docs](https://docs.scala-lang.org/tour/implicit-conversions.html), we need
this,

> Because implicit conversions can have pitfalls if used indiscriminately the
compiler warns when compiling the implicit conversion definition.

So, we are making it explicit that we are using implicit conversions :smile:
(BTW, conversion = function).

## Implicitly Implicit :sunglasses:

We have already seen that we can bring in `implicit` values in the scope using
`import`. If we can have multiple `implicit` values defined in the imported
classes, we have some interesting effects.

Let's take the earlier example of `concatStrings()`. We have a `DefaultConfig`
object setting delimiter to `","`, and a `SpecialConfig` object setting it to
`"+"`. Let's also have these files:

1. `ImplicitHelper.scala` -- Defines `concatStrings` method
2. `Main.scala` -- Invokes the `contactStrings` method
3. `DefaultConfig.scala`, and
4. `SpecialConfig.scala` -- as defined earlier

Now, 

```scala
// DefaultConfig.scala
object DefaultConfig {
  implicit val delimiter: String = ","
}
```

And,

```scala
// SpecialConfig.scala
object SpecialConfig {
  implicit val delimiter: String = "+"
}
```

And,

```scala
// ImplicitHelper.scala
object ImplicitHelper {} // As before
```

At last,

```scala
import ImplicitHelper._
import DefaultConfig._

object Main {
  def main(args: Array[String]): Unit = {
    val strings = Seq("Hello", "World")
    val result = concatStrings(strings)
    assert(result == "Hello,World,")
  }
}
```

Since we `import DefaultConfig._`, the delimiter is now `","`. We can quickly
swap that for `SpecialConfig._` to have a different delimiter.

```scala
import ImplicitHelper._
import SpecialConfig._

object Main {
  def main(args: Array[String]): Unit = {
    val strings = Seq("Hello", "World")
    val result = concatStrings(strings)
    assert(result == "Hello+World+")
  }
}	
```

  And, the import order does not matter.

## Concluding Thoughts

The `implicit` arguments, especially through `import` provide a nice way to
implement composability and dependency injection patterns. Thanks to the
tooling, we still get the benefits of following arguments to their definitions.
Sometimes, like in implicit conversions, we still need to be careful not to
misuse them.


Scala's functions are different since they accept two set of arguments as opposed to one in many programming languages. What does it serve? Let's look into it...

Hello World! I'm Vinayaka K V

Blog

1342177289

2023 - Year In Review

Exploding with Type Safety

The Implicit Arguments