My top concern when application engineers are going to spend 90%+ time reviewing AI-generated codes in the upcoming years -- the human reviewing speed.

In the real world, someone in the team must take accountability for the correctness and performance of the source code. It doesn't make sense for anyone to make a disclaimer like

This system is generated by AI and might contain errors.

If 99%+ of source code will eventually be generated by LLMs, the human review process becomes critical.

Underestimated the effect of choosing programming languages

I have 8 years of application development experience using strong, statically typed programming languages, including Java, Scala, Swift, Javascript, Typescript, and Kotlin, from before the GenAI era.

For the recent two years, the latest GenAI libraries usually released in Python first. Thus, I have been heavily using LLMs to generate Python code while building and exploring GenAI PoC with my customers across different frameworks like LangChain, LangGraph, Google ADK, Strands Agent, and more.

The longer I read and write Python, the more I miss statically typed programming languages, especially Kotlin and its compiler.

Before the GenAI era, Kotlin has always been my go-to programming language because of its elegant design. Its rich language features enable me to express myself through different forms of abstraction very efficiently. The static typing and type inference help me navigate others' source code effectively.

Now, in GenAI era, LLMs can generate high quality source code for many popular programming languages. The underestimated part is to leverage compilers in Agent tool to guarantee their output has zero type mismatches or syntax errors at compile time.

Code reviewing efficiency

In my 8 years development experience, I was 99.9% of the time able to navigate deeply Java/Kotlin open-source libraries' source code in my IDE and trace the underlying low-level implementations and read source code documentation. This significantly helped build confidence and learn fast when using new libraries.

While with Python, it is less than 50%. It is because some Python implementations use dynamic typing with no type hint or with Union type hint makes it difficult to navigate deeply.

See the common Result type implementation:

Can you spot error during the review?

from typing import Union

class SuccessResultA:
    a: int = 1

class FailureResultB:
    b: str = "1"

def call(x: int) -> Union[SuccessResultA, FailureResultB]:
    if x%2 == 1:
        return SuccessResultA()
    else:
        return FailureResultB()

result = call(0)

print(result.b)

Let's run it

As the result type is produced dynamically base on runtime, sometimes the program will works.

How would you review the source code effectively if LLM generate source code with 4 - 10 abstraction layers of union types in Python build from ground up?

On the contrast, the similar abstraction to Python Union type in Kotlin is sealed class, it is static typing and checked by complier at compile time.

The best part of compile time error is that, it has no runtime dependencies or side effect.

When I am reviewing the source code, I would check and navigate the types. The Kotlin smart cast annotation really shine in this area.

Roughly speaking, when I review the same AI generated source code in Kotlin, the static typing, language conciseness and complier reduces 80% mental cognitive load. The complie-time type errors help to reduce 80% Agentic-back-and-forth time comparing to Python.

Although my current job role is unlikely to involve building complex and long-lived production systems, I hope newcomers to this industry aware the choice of programming languages.

The technology stacks of building throwable GenAI PoCs are completely different from building long-lived applications.

If you are new to this application development industry, I highly recommend you to spend some effort to deep dive into different programming languages with AI, especially on the strong and static typed programming language.

The ultimate goal is to take accountability and review AI generated codes as efficient as possible.

Jupyter Python Notebook is great, now available in Kotlin - Kotlin Notebook

In terms of learning a new language, my first "wow" moment was experiencing Python Jupyter notebooks. These notebooks helped me tremendously in picking up new technologies and allowed for rapid experimentation.

When I discovered that Kotlin Notebook had become freely available and JetBrains is building the latest Kotlin-native AI agent framework (Koog), I started an open-source project to consolidate my Kotlin experiments and share them online.

GitHub repository: https://github.com/gaplo917/awesome-kotlin-notebook

I am trying to build a multi-agent system using A2A protocol with strong static typing in Kotlin running on my M4Max Macbook Pro. It is for my own learning about A2A and the experience is transferrable to Python as well.

Notes: I don't use LLM generate ideas as it is the interesting part of being a human. I use LLM to work on my ideas instead.

Kotlin 2.0 is finally arrived and become stable. The most interesting upgrade to Kotlin 2.0 is the K2 compiler, it helps your project build faster and allow you to write smarter codes.

In the recent JetBrain blog post, it shows Kotlin 2.0.0 (K2) vs 1.9.23 performance gains:

• Clean build: 94% faster (57.7s → 29.7s)
• Initialization: 488% faster (0.126s → 0.022s)
• Analysis: 376% faster (0.581s → 0.122s)

Not only the performance is significant improved, the smart cast handling on K2 compiler also significantly improved. I consolidated five examples:

Handling generic box interface

interface Box<T>
val <X> Box<X>.first: X get() = TODO()

fun foo(p: Box<() -> Unit>) {
    // K1: compile error
    // K2: ok
    p.first()
    p.first.invoke()
}

Synthetic data flow variables can carry information about smart-casts

fun test(foo: String?) {
    if (foo != null) {
        foo.length
    }
    
    val fooIsNonNull = foo != null
    if (fooIsNonNull) {
        // K1: compile error , unsafe call
        // K2: ok
        foo.length
    }
}

Smart-casts inside changing closures of lambdas

• In general, we don't know anything about the inPlaceRun function
• The parameter f could be invoked later or just stored somewhere, and value could be changed after the lambda block

fun inPlaceRun(f: () → Unit) {
    f()
}

fun foo() {
    var value: Int? = null
    inPlaceRun {
        // K1: compile error, smart cast to 'Int' is impossible
        // K2: ok
        if (value != null) value++ else value = 0
    }
}

Explicitly tell the compiler that the parameter f will be invoked only within the method and won't be stored anywhere else.

@OptIn(ExperimentalContracts::class)
fun inPlaceRun(f: () → Unit) {
    contract {
        callsInPlace(f, InvocationKind.UNKNOWN)
    }
    f()
}

fun foo() {
    var value: Int? = null
    inPlaceRun {
        // K2: smart cast to 'Int'
        if (value != null) value++ else value = 0
    }

Smart-casts inside closures of inline lambdas

• In K1, it's impossible to have a smart-cast because the lambda can be invoked later, even after forEachIndexed call

fun indexOfMax(a: IntArray): Int? {
    var maxI: Int? = null
    a.forEachIndexed { i, value ->
        // K1: compile error, smart cast to 'Int' is impossible,
        // because 'maxI' is a local variable that is captured by a changing closure
        // K2: Ok
        if (maxI == null || a[maxI] <= value) {
            maxI = i
        }
    }
    return maxI
}

Smart-casts after ||: merge to a common supertype

K2 compiler now can recognize || case in the condition. You don't need to write switch case now.

interface Status {
    fun signal()
}

interface Ok : Status
interface Postponed : Status
interface Declined : Status

fun foo(o: Any) {
    if (o is Postponed || o is Declined) {
        // K1: compiler error, o is inferred to Any
        // K2: o is inferred to Status
        o.signal()
    }
}

Foreword: Beyond Javascript Development

Before I have started React/Vue/Angular development, I have been working on building iOS and Android mobile applications for a few years that use MVVM architecture.

When developing a frontend application, we undoubtedly offload all kinds of I/O, computational tasks from a UI thread to prevent a UI thread from being too busy and becoming unresponsive.

This rule doesn't apply to current web development.

The current web development ONLY offloads the tasks to web worker when the application encounter performance issues but NOT by the tasks' nature.

As we all know, web workers are designed to offload works from a UI thread, but why don't developers utilize it by default?

Painful and Time-consuming Web Worker Development

I cannot deny that by the javascript execution design (single-main-thread event-loop architecture),  you can't have shared memories across threads(workers).

That's why web workers are designed in a message-driven way. All the communications are required to send message copies. For example:

// main.js  
const first = document.querySelector('#number1');
const second = document.querySelector('#number2');

const result = document.querySelector('.result');

if (window.Worker) {
  const myWorker = new Worker("worker.js");

  first.onchange = function() {
    myWorker.postMessage([first.value, second.value]);
    console.log('Message posted to worker');
  }

  second.onchange = function() {
    myWorker.postMessage([first.value, second.value]);
    console.log('Message posted to worker');
  }

  myWorker.onmessage = function(e) {
    result.textContent = e.data;
    console.log('Message received from worker');
  }
} else {
  console.log('Your browser doesn\'t support web workers.');
}

// worker.js
onmessage = function(e) {
  console.log('Worker: Message received from main script');
  const result = e.data[0] * e.data[1];
  if (isNaN(result)) {
    postMessage('Please write two numbers');
  } else {
    const workerResult = 'Result: ' + result;
    console.log('Worker: Posting message back to main script');
    postMessage(workerResult);
  }
}

It makes parallel processing difficult and requires a deep understanding of workers to do it right.

Here are the pain points that javascript application developers might encounter:

• creating a web worker and importing existing npm modules into a web worker is painful.
• Coding in a weakly-typed language with a loosely message-driven style is not intuitive, time-consuming, more difficult to debug, and repetitive.
• Working in an async loading UI pattern requires extra UI states to handle it.

Because of the learning curve of web workers, we are tempted to do everything on UI thread like:

• calling fragmented JSON RPC / API calls and then aggregate into one view model
• calling a large GraphQL query and then applying a lot of data transformations
• sorting, filtering, and reducing different kinds of data triggered by UI actions

In 2020, web technology advancement has brought the way out of this pain.

Web Technology Advancement

A Comlink RPC abstraction abstracts message-driven web workers into a promise-like RPC call. It works with webpack and magically import npm modules into the web workers.

React 17.0 will expose <Suspense> component (Experimental Concurrent Mode Feature) helps boost developer productivity on handling asynchronous data without sacrificing the power of declarative programming style.

From my deep heart, I believe it is suitable for every React developer to discover those techniques, try to find out, and apply forward-suspense-compatible solutions into their new/existing code bases.

Creating a React Application w/ Experimental Features

First, I studied the React 17.0 experimental <Suspense> contract and researched the latest Web Worker abstraction.

Combined with the power of Comlink RPC abstraction that abstracts message-driven web workers into a promise-like RPC call.

I created react-suspendable-contract that is a high-level and experimental abstraction for any promise-like to fulfill the contract of <Suspense>.

import { DependencyList, ReactElement, useMemo } from 'react'

const PENDING = Symbol('suspense.pending')
const SUCCESS = Symbol('suspense.success')
const ERROR = Symbol('suspense.error')

type RenderCallback<T> = (data: T) => ReactElement<any, any> | null

export interface SuspendableProps<T> {
  data: () => T
  children: RenderCallback<T>
}

/**
 * Simple Wrapper indicate the component is suspendable.
 * `useSuspendableData` will create the contract that consumed by <Suspense> Component
 *
 * ```js
 *  const UserPage = ({ userId }) => {
 *    const suspendableData = useSuspendableData(() => getUserAsync({ id: userId }), [userId])
 *
 *    return (
 *      <Suspense fallback={<Loading />}>
 *         <Suspendable data={suspendableData}>
 *           {data => <UserProfile user={data}/>}
 *         </Suspendable>
 *      </Suspense>
 *    )
 *  }
 * ```
 *
 * @param data
 * @param children
 * @constructor
 */
export const Suspendable = <T>({ data, children }: SuspendableProps<T>) => {
  return children(data())
}

/**
 * `useSuspendableData` will only execute the promiseProvider when one of the `deps` has changed.
 *
 * Notes: internally use `useMemo` keep track the `deps` changes
 *
 * @param promiseProvider
 * @param deps
 */
export function useSuspendableData<T>(
  promiseProvider: () => PromiseLike<T>,
  deps: DependencyList | undefined,
): () => T {
  if (typeof promiseProvider !== 'function') {
    throw Error('promiseProvider is not a function')
  }

  return useMemo(() => {
    let status = PENDING
    let error: any
    let result: T
    const suspender = Promise.resolve()
      .then(() => promiseProvider())
      .then(r => {
        status = SUCCESS
        result = r
      })
      .catch(err => {
        status = ERROR
        error = err
      })
    return () => {
      switch (status) {
        case PENDING:
          throw suspender
        case ERROR:
          throw error
        case SUCCESS:
          return result
        default:
          throw Error('internal error. This should not happen')
      }
    }
  }, deps)
}

Then, I created a sample React application with 300 items in a popular virtual list library react-virtualized . The application calculates a simple math function when the items become visible during the user's scroll.

I added a compute function that would burn some CPUs.

// Simply write the same computational function
// Comlink will do the magic to pack this function into a web worker

// noting special, just a compute task that could use CPU
export function compute(base: number, pow: number): number {
  let result = 0
  let i = 0
  const len = Math.pow(base, pow)
  while (i < len) {
    result += Math.sin(i) * Math.sin(i) + Math.cos(i) * Math.cos(i)
    i++
  }

  return result
}

I implemented four scenarios to process a virtual list calculation when the item becomes visible:

• UI Thread (Blocking)
• Web Worker (Singleton)
• Web Worker (Pool)
• Web Worker (Dedicated Worker)

Let's have a quick look at the final research deliverables.

Live Demo

A video recording to show a web-worker-powered web application that can use all the 16 threads of an 8 core CPU.

In 2020, If someone explains the laggy of a Web Application because of a single-threaded limitation, they don't know Web.

A correctly implemented Web Application can use ALL your CPU cores to process your business logic.

Live Demo: https://t.co/PpyfUbzKyJ #React #Javascript pic.twitter.com/Ofh4rBbe1U

— LoGap (@gaplo917) September 20, 2020

Try the following iframe, or Full Page Live Demo to scroll in the "Virtual List with 300 Items", and change the "Mode" to see the different effects!

Someone might claim that:

My application reaches 60 fps most of the time in my iPhone 12 Pro Max / i9 Macbook pro...

Try to run the demo in the "CPU 4x slowdown" option under "Performance."

Hey! Do you know all the previous demos and screenshots only talk about 60 fps...

120Hz is coming

Since the iPad Pro 2nd-gen started to support 120Hz, I believed 120Hz Web browsing is coming soon. The higher fps, the shorter time for a UI thread to process.

Considering the 60Hz to 120Hz change, the "smooth UI (No dropped frames)" process cycle time changed from 16.67ms to 8.33ms, which halved the time we got from the previous decade!

An I/O call is non-blocking on a UI thread doesn't mean that it doesn't use the UI thread CPU time.

A non-blocking HTTP I/O call doesn't block the UI thread immediately, but it does consume the UI thread's CPU time. If the UI thread doesn't have sufficient CPU time to process the UI, it would eventually drop the frames.

For instance, when the applications make high-concurrency I/O calls, these processes cumulatively eat up the UI thread's CPU time at the same moment and it would easily cause the drop frame. What's more, developers tend to process the business requirements after I/O calls such as data transformation, data validations, and UI state transformation, which are blocking operations.

If the business requirements become more and more complex, using web workers is unavoidable if you need to build a hassle-free, smooth 120Hz Web application.

A scientific approach is to develop your application in "CPU 4x slowdown" and target to remain 60 fps, it proves your application can smoothly complete the workload on a UI thread on low-end devices, and there should be no significant lag on high-end 120Hz browsing.

Understanding the Trade-off

Assume we spend n CPU time to process a task on UI thread, if we offload the task to web workers would need to spend n + m CPU time where m is the overhead. Here are the illustrations:

In a micro view, we traded off using more total CPU time to process the same task in parallel for saving the UI thread's CPU time.

But in a macro view, if the users did unnecessary and repetitive actions because of junking UI such as refreshing the whole page, it would easily take 100 - 1000x more CPU time than the overhead.

If m is much smaller than n, it is worth reserving the UI thread CPU time for future complex changes.

Conclusion

The ComLink abstraction(turn a web worker to RPC-style function call) and React Concurrent mode arise.

I think it is time to start thinking about adopting web workers in all cases - completely decouple a data accessing layer. Using the browser's web worker in the background thread for all I/O and data processing by nature and then return to the UI thread for rendering.

Nothing is new; this is how we write a standard smooth frontend application in other platforms(iOS, Android, Windows, macOS, JVM) since multi-threaded CPU arise.

GitHub Source: https://github.com/gaplo917/react-offload-ui-thread-research

Appendix

UI Thread (Blocking)

The one who is already busy on UI still needs to work on the calculation task.

// file:SomeListBlocking.tsx

function TabContent({ index, base, pow, style, isScrolling }: TabContentProps) {
  // if user is scrolling and the content is not yet ready, showing loading component
  const result = isScrolling ? (
    <Loading index={index} />
  ) : (
    useMemo(() => {
      const result = compute(base, pow)
      return (
        <ComputeResult index={index} base={base} pow={pow} result={result} />
      )
    }, [base, pow])
  )
  return <p style={{ padding: 8, ...style }}>{result}</p>
}

export default function SomeListBlocking() {
  return (
    <VirtualList
      rowRendererProvider={(base, pow) => ({
        key,
        index,
        style,
        isScrolling,
      }) => (
        <TabContent
          key={key}
          index={index}
          base={base}
          pow={pow}
          style={style}
          isScrolling={isScrolling}
        />
      )}
    />
  )
}

Web Worker (Singleton)

An extra worker to do all the computations. It is the easiest way to integrate Comlink correctly and 99.99% guarantees performance improvement.

// file:SomeListSingleton.tsx
// the actual web worker function from comlink
import { compute } from '../../workers/compute.worker.singleton'

function TabContent({ index, base, pow, style }: TabContentProps) {
  // create a future data that force a promise to fulfill  Suspense Component contract
  const suspendableData = useSuspendableData(() => compute(base, pow), [
    base,
    pow,
  ])
  return (
    <p style={{ padding: 8, ...style }}>
      <ErrorBoundary
        key={`${base}-${pow}`}
        fallback={<ComputeErrorMessage index={index} base={base} pow={pow} />}
      >
        <React.Suspense fallback={<Loading index={index} />}>
          <Suspendable data={suspendableData}>
            {(data) => (
              <ComputeResult
                index={index}
                base={base}
                pow={pow}
                result={data}
              />
            )}
          </Suspendable>
        </React.Suspense>
      </ErrorBoundary>
    </p>
  )
}

export default function SomeListSingleton() {
  return (
    <VirtualList
      rowRendererProvider={(base, pow) => ({ key, index, style }) => (
        <TabContent
          key={key}
          index={index}
          base={base}
          pow={pow}
          style={style}
        />
      )}
    />
  )
}

Web Worker (Pool)

When you have a lot of computations, you might need a worker pool and distribute the jobs to the workers in parallel to speed up the calculations.

// file:SomeListWorkerPool.tsx
// the actual web worker from comlink
import ComputeWorker from 'comlink-loader!../../workers/compute.worker'

function TabContent({ index, base, pow, style, worker }: TabContentProps) {
  const suspendableData = useSuspendableData<number>(
    () => worker.compute(base, pow),
    [base, pow],
  )
  return (
    <p style={{ padding: 8, ...style }}>
      <ErrorBoundary
        key={`${base}-${pow}`}
        fallback={<ComputeErrorMessage index={index} base={base} pow={pow} />}
      >
        <React.Suspense fallback={<Loading index={index} />}>
          <Suspendable data={suspendableData}>
            {(data) => (
              <ComputeResult
                index={index}
                base={base}
                pow={pow}
                result={data}
              />
            )}
          </Suspendable>
        </React.Suspense>
      </ErrorBoundary>
    </p>
  )
}

export default function SomeListWorkerPool() {
  const [poolSize, setPoolSize] = useState(4)

  // create a pool of workers
  const workerPool = useMemo(
    () => new Array(poolSize).fill(null).map(() => new ComputeWorker()),
    [poolSize],
  )

  return (
    <>
      <VirtualList
        headerComp={() => (
          <TextField
            id="standard-basic"
            label="Worker Pool Size"
            required
            type="number"
            variant="outlined"
            defaultValue={poolSize}
            inputProps={{ step: 1 }}
            onChange={(event: React.ChangeEvent<{ value: string }>) => {
              setPoolSize(Number(event.target.value))
            }}
          />
        )}
        rowRendererProvider={(base, pow) => ({ key, index, style }) => (
          <TabContent
            key={key}
            index={index}
            base={base}
            pow={pow}
            style={style}
            worker={workerPool[index % poolSize] /* distribute workload */}
          />
        )}
      />
    </>
  )
}

Web Worker (Dedicated Worker)

Ideal world, when you have unlimited resources, you could dedicate a new task to a new worker. In the real world, it is not efficient.

// file:SomeListDedicatedWorker.tsx
// the actual web worker from comlink
import ComputeWorker from 'comlink-loader!../../workers/compute.worker'


// no way to dispose the worker if using a comlink-loader, until this pr is merged
// https://github.com/GoogleChromeLabs/comlink-loader/pull/27
function TabContent({ index, base, pow, style }: TabContentProps) {
  const suspendableData = useSuspendableData<number>(async () => {
    // create a dedicated worker for each rendering
    const worker = new ComputeWorker()
    return worker.compute(base, pow)
  }, [base, pow])

  return (
    <p style={{ padding: 8, ...style }}>
      <ErrorBoundary
        key={`${base}-${pow}`}
        fallback={<ComputeErrorMessage index={index} base={base} pow={pow} />}
      >
        <React.Suspense fallback={<Loading index={index} />}>
          <Suspendable data={suspendableData}>
            {(data) => (
              <ComputeResult
                index={index}
                base={base}
                pow={pow}
                result={data}
              />
            )}
          </Suspendable>
        </React.Suspense>
      </ErrorBoundary>
    </p>
  )
}

export default function SomeListDedicatedWorker() {
  return (
    <VirtualList
      rowRendererProvider={(base, pow) => ({ key, index, style }) => (
        <TabContent
          key={key}
          index={index}
          base={base}
          pow={pow}
          style={style}
        />
      )}
    />
  )
}

Patreon Backers

Thank you for being so supportive ❤️❤️❤️. Your support made this R&D article always free, open, and accessible. It also allows me to focus on my writings that bring a positive impact to you and the other readers among the global technical community. Become a Patreon Backer!

Backers:

• 
  Tecky Academy(Business I)
• Anthony Siu (Gold)
• Martin Ho (Gold)
• Chan Paul (Gold)
• Jay Chau (Gold)
• Mat (Gold)
• Raymond An
• Chi Hang Chan

Become a Patreon Backer!

Foreword

In Hong Kong, there are so many code boot camps teaching javascript courses that market with the buzzword - Full Stack developer. In the code boot camp, the candidates are trained to figure out the frontend (React), backend (Nodejs), and database(NoSQL) in a short period. As we all know, each of these fields is a super big spectrum that takes time to discover and study. I am pretty confident to say that:

It is easy to get it working but challenging to do it right.

The root of doing the right thing is entirely relying on the fundamentals - knowledge of Software Engineering. It is a big topic that I would continue to write articles to share more.

Let's back to the topic - The javascript declarative cost.

Declarative Javascript (Functional Programming)

ES6 has introduced functional operators(.map, .filter, .reduce) for Array. I can't remember the last time I wrote "for loop" control flow to compute data in javascript.

I really like the power of declarative programming style that helps me write nearly bug-free and scalable data transformations

I decided to start building a new project called kt.ts that targeted to bring a Kotlin wise-designed collections API interface to Typescript that the existing npm modules can't compete with.

In Javascript, there are two popular FP libraries called lodash and ramda, developers write data transformations in a self-documented and declarative way.

// lodash lazy chain
_.chain(arr)
    .map(someTransform)
    .filter(isNotNullPredicate)
    .uniq()
    .sumBy(someCalculation)
    .value()

// ramda
R.pipe(
  R.map(someTransform),
  R.filter(isNotNullPredicate),
  R.uniq,
  R.map(someCalculation),
  R.sum,
)(array)

To do the same express in Kotlin, we could express in a simpler way:

array
  .mapNotNull(someTransform)
  .distinct()
  .sumBy(someCalculation)

That's why I would like to bring these wise and practical designed interfaces from Kotlin to Typescript.

Creating kt.ts in a wrapper approach

So, I started with a wrapper approach that uses lodash internally to build the kt.ts abstractions. After a few hours of implementation and designing the project architecture, a few commonly used interfaces are finished like .mapNotNull(transform) , .distinct().

Here is an example of the wrapper approach in Typescript:

import { uniq, uniqBy } from 'lodash'

declare global {
  interface Array<T> extends KtListDistinctOp<T> {}
}

export interface KtListDistinctOp<T> {
  /**
   * Returns a list containing only distinct elements from the given collection.
   *
   * The elements in the resulting list are in the same order as they were in the source collection.
   */
  distinct(): T[]

  /**
   * Returns a list containing only elements from the given collection
   * having distinct keys returned by the given [selector] function.
   *
   * The elements in the resulting list are in the same order as they were in the source collection.
   */
  distinctBy<K>(selector: (value: T) => K): T[]
}

export default <T extends any>(proto: Array<T>) => {
  proto.distinct = function (): T[] {
    return uniq(this)
  }

  proto.distinctBy = function <R>(selector: (value: T) => R) {
    return uniqBy(this, selector)
  }
}

After that, I kick-started another project to benchmark my wrapped implementations in kt.ts to guarantee the implementation doesn't have performance regression. I wrote the vanilla for-loop approach to compare my kt.ts implementation.

The benchmark result is very disappointed and completely unacceptable. The first thought that came to my head was

Did I do something wrong? Is that V8 optimization too magical to me? Or lodash issue?

OMFG, 80x performance difference!?

To take care of my curiosity,

my sense of software engineering summon me to implement all possible versions of  .mapNotNull , .distinct , and .sumBy in vanilla javascript and different libraries.

Preparation of Javascript Benchmark

To kick start, I pick a common scenario that uses .mapNotNull , .distinct , and .sumBy that use native, ramda, lodash, array prototype, and lazy iterator to implement the same data transformation logic.

Finally, I implemented 19 variations that are (click to browse the source code)

• native-ideal-while
• native-standard-for-loop
• native-fp (declarative, native .map, .filter, .reduce)
• native-fp-optimized (merged FP operators)
• native-fp-reduce-imperative(infamous wrong way of using reduce)
• lodash-one-by-one
• lodash-one-by-one-optimized
• lodash-lazy-chain
• lodash-lazy-chain-optimized
• lodash-fp
• lodash-fp-optimized
• ramda
• ramda-optimized
• array-ext-native (kt.ts designed)
• array-ext-lodash-optmized (kt.ts designed)
• array-ext-ramda-optmized (kt.ts designed)
• lazy-sequence-native
• lazy-sequence-lodash-optmized
• lazy-sequence-ramda-optmized

Then, I use benchmark npm library to run with arraySize = [1,10,100,1k,10k,100k,1M]` in node.js v14.

Those implementations are so sensitive to CPU performance.

I have to guarantee there is

• No unwanted applications are running
• No noisy neighbor on cloud
• No performance thermal throttling
• Large enough sample size to take the average

Thus, I rented a cloud-based Packet's Bare Metal Ubuntu Server (t1.small.x86). Run 1000 sample * 20 implementations * 7 size. Here is the benchmark performance:

Stunning Benchmark Result

As a result, the whole benchmark 1000 sample * 20 implementations * 7 size it takes 16.44 hours to run!

Here is the result:

Summary:

• The imperative approach performs the best when the array size is small
• Merged functional operators significantly improve the performance, compare native-fp and native-fp-optimized, see the optimized codes
• The bigger the array size, the closer between native-fp-optimized and native-ideal-while. The performance of the native-fp-optimized is very close to the native-ideal-while when the array size >= 100.
• The ramda and lodash/fp's benchmark results are surprisingly worse when the array size < 100
• Surprisingly, comparing between native-standard-for-loop and array-ext-native, array-ext-native is a declarative abstraction that uses two for loop implementations and one new Set  underlying to avoid Set the operation does improve the performance when the array size is large.

// native-standard-for-loop
export function nativeStandard(arr) {
  const len = arr.length
  if (len === 0) {
    return 0
  }
  const set = new Set()
  let sum = 0
  for (let i = 0; i < len; i++) {
    const e = someTransform(arr[i])
    if (e !== null) {
      const oriSize = set.size
      set.add(e)
      if (set.size !== oriSize) {
        sum += someCalculation(e)
      }
    }
  }
  return sum
}

// array-ext-native
export function arrayExtensionNative(arr) {
  return arr
    .ktMapNotNullNative(someTransform)
    .ktDistinctNative()
    .ktSumByNative(someCalculation)
}

Array.prototype.ktMapNotNullNative = function (transform) {
  const result = []
  for (let i = 0, len = this.length; i < len; i++) {
    const e = transform(this[i])
    if (e !== null) {
      result.push(e)
    }
  }
  return result
}

Array.prototype.ktDistinctNative = function () {
  return Array.from(new Set(this))
}

Array.prototype.ktSumByNative = function (selector) {
  let sum = 0
  for (let i = 0, len = this.length; i < len; i++) {
    sum += selector(this[i])
  }
  return sum
}

The benchmark proves that if kt.ts can bring Kotlin collection API design(lots of extra declarative operators) to Typescript, Typescript developers can

• enjoy shorter implementation and more performant declarative codes compared with the native-fp / lodash / ramda
• enjoy a lot of extra declarative operators (merged multiple functional operators) to build different use cases

I believe 80%+ of worldwide javascript usage won't process an array having more than 1k items, and 80%+ developers won't choose javascript to build performance-sensitive applications.

A professional software engineer should always know their needs.

Don't worry about non-exist needs.

If the performance is critical in most use cases, I suggest learning the necessary algorithms and data structures and writing them in an imperative style(control flow) to get the best performance rather than spending time struggling on the performance tuning of the declarative programming style.

If the performance is neglectable in most use cases, I suggest going for declarative programming style to use well-tested functional operators to write a more readable and self-documented data transformation logic.

Conclusion

By kicking start a new side project, kt.ts, I learned a lot from creating this benchmark of figuring out the javascript declarative cost. This benchmark has changed my mind about using lodash or ramda as a foundation library.

Learning lodash or ramda is just a way to work in a more functional and declarative. They did provide well-tested functional operators and allowed developers to use them immediately. However, from the benchmark result, the implementation itself doesn't work efficiently in javascript compared to the native functional operators.

Unless their internal implementations would eventually provide a "Parallel Processing" option that spawns an extra node worker/web worker and process array elements in parallel, like Scala's parallel collection, otherwise, under a single main thread execution model, you need to sacrifice some performance to trade readability and development speed.

That is the "Declarative Cost in Javascript".

If someone told you a simple .map or .filter operator in lodash or ramda is just n% slower than the native .map or .filter operator, they forget that we normally chain 3 - 5 operators on average that is (1-n)^k % slower.

If on average n = 0.2, chain 3 - 5 operators become

• 0.8^3 = 0.51
• 0.8^5 = 0.32

~50-70% performance drop on average
if
chaining 3 - 5 operators

I hope you can get some insight from this article!

Patreon Backers

Thank you for being so supportive ❤️❤️❤️. Your support made this R&D article always free, open, and accessible. It also allows me to focus on my writings that bring a positive impact to you and the other readers among the global technical community. Become a Patreon Backer!

Backers:

• 
  Tecky Academy(Business I)
• Anthony Siu (Gold)
• Martin Ho (Gold)
• Chan Paul (Gold)
• Jay Chau (Gold)
• Mat (Gold)
• Raymond An
• Chi Hang Chan

Become a Patreon Backer!

I have seen a lot of iOS developers who has tried Kotlin with their first glaze and most of them would very likely to use the following statement to describe Kotlin:

“Kotlin in Android” is just like “Swift in iOS”

But, from my personal experience on Android & iOS development. I think “Kotlin in Android” is MUCH BETTER and MATURER than “Swift in iOS” .

If you have experience on coding Swift in iOS by using Xcode, you should have experienced some really really bad. And I would like share my list of complaints :

• Too many breaking changes on Swift standard API (from Swift 1.0 to 3.0) — Let’s wait to see the breaking changes on Swift 4 :p .
• Xcode* keep crashing — boom ! “Xcode quit unexpectedly”.
• Xcode* keep showing “internal error” — boom! All syntax-highlight has gone and you can only wait for the Xcode self-recover by making some line changes.
• Xcode* has NO “Refactor” features for Swift
• Swift Compiler is too weak to work on “Type inference” — Result in Long compile time. When the expression is too complex and it fails to find the correct Type, compiler will ask you to type it manually. Sometimes, seriously, the compiler will encounter “segmentation fault” because of Type inference.
• Xcode’s* Swift inspection is very slow — The best approach is never wait the Xcode to prompt syntax error, after writing a lot of code and directly press ⌘+B to compile and wait the compiler prompt any syntax error you had made.
• Swift SourceKit inspection is not accurate — For example, missing a } of a closture would result in unrelated error message XXX is not convertible to YYY . It is really annoying and confusing, especially for new comers.
• Swift SourceKit inspection is disruptive — Every time when I had made a typo mistake on syntax. i.e. missing a { or } , Xcode mark the line with red and STOP doing syntax highlight on the later code or even crash on “internal error”. It really annoys my normal work flow. I solve this problem by using Intellij App Code which I feel more productive and zero-annoyance when coding some non-UI logics.
• Objective-C syntax is too strange to Swift-Only developer — Many useful third-party libraries still using Objective-C but Swift has grow very fast and I believe “Pure Swift iOS Project” will solve this problem.

*Experienced with Xcode ≥ 7.0 && ≤ 8.1, iMac 27"(Retina) 2014 Late i7 32GB Ram

Kotlin with the Best IDE

All of the aforementioned bad parts of “Swift in iOS” are NOT valid to “Kotlin@Android Studio”. JetBrain has provided a very good IDE support for Kotlin.

Android Studio (≥ 2.0) with Kotlin:

• Super smooth & stable, nearly NO crash
• Inspection and auto-complete is fast
• Concise and accurate syntax error message
• Compiler is clever enough to work on complex type-inference(i.e. Nested Lambda)
• Trustworthy Refactoring
• Work with Instant Run

Welcome to Part 2, this part includes lots of Java vs Kotlin sample code snippets as a show case. Many useful comments/arguments are written in the code block. In order to have better reading experience, I would recommend you to use a large screen to continue to read this article.

Compile-time Null Safe

“Compile-time Null-Safe” in Kotlin is a serious and fundamental improvement compared with Java. It solves the infamous null problem in Java and gives a very productive way to write high quality and NPE-less code.

In Java, every object you created will be assigned it to null by default. It is also known as “The Billon dollar mistake”. Numerous “workarounds” has been brought out in Java, third-parties library or even in IDE, for example:

• @NotNull
• Objects.requireNonNull(..)
• Optional.ofNullable(..)

Closely look at the follow Java example, it shows four different ways to write the same functionality.

// Java null risk workaround example

import org.jetbrains.annotations.NotNull;
import org.jetbrains.annotations.Nullable;

import java.util.Optional;
import static java.lang.System.*;

class NullRisk {
  // Bad code in Java
  public String doRiskyThing(String str) {
    return str.toLowerCase();
  }
  
  // Human error by typing wrong annotation, should be @NotNull
  public String doMissLeadingThing(@Nullable String str) {
    return str.toLowerCase(); // IDE warning
  }
  
  // possible work around, IDE will show warning if the input is null
  // but it is safe to compile
  @NotNull
  public String doSafeThing(@NotNull String str){
    return str.toLowerCase();
  }

  // possible work around, but using Optional in java is pain and not handy as Kotlin/Scala
  public Optional<String> doOptionalThing(@Nullable String strOpt) {
    return Optional.ofNullable(strOpt).map(String::toLowerCase);
  }

  {
    // compile OK! throw NullPointerException in run-time
    out.println(doRiskyThing(null));
    
    // compile OK! IDE warning, throw NullPointerException in run-time
    out.println(doSafeThing(null)); 
    
    // compile OK! throw NullPointerException in run-time
    out.println(doMissLeadingThing(null));
    
    // compile OK!
    out.println(doOptionalThing(null));
  }
}

The first function doRiskyThing is written w/o @NotNull annotation. The function is not self-documented and you must do some workaround to improve it.

If we focus on the function declaration public String doRiskyThing(String riskyString)without looking at the implementation details, developers won’t get any information about the input parameter. Questions may come up for Java developers :

• Can I pass a null?
• if I pass a null , what will be the return? null? empty string? other default string?

Consider if developers are required use doRiskyThing to build something, they had to spend extra effort to run a test or look at the source code to build up their confidence.

The other two examples are the popular “Work Arounds”, ONLY doOptionalThing(String strOpt) is safe in run-time.

In Kotlin, nullable object must be represented by appending ? . For example,Int? String? Long? DateTime? BigDecimal? . This syntax will be checked in compile time and also in IDE inspection.

No workaround is needed, and the follow functions are by-design self-documented.

// Kotlin null safe example
// Java null risk example 

fun doSth(str: String): String {
    return str.toLowerCase()
}

fun doSthOptional(str: String?): String? {
    // Optional chainning, similiar to Swift
    return str?.toLowerCase()
}

doSth(null) // compile error
doSth("Abc") // return "abc"

doSthOptional(null) // return null
doSthOptional("Abc") // return "abc"

// More example on copmile-time checking
var a0 // fail, compile error  
var a1 = null // fail, compile error  
var a2: String = null // fail, compile error  
var a3: String? = null // OK

println(a3) // OK, print null  
println(a3.toLowerCase()) // fail, compile error  
println(a3?.toLowerCase()) // OK, print null

As you can see the fundamental difference in this tiny example, why don’t Java fix “the billion dollar mistake”?

Java has to maintain the Backward Compatibility

So, you may ask what is the point that related to Kotlin?

In 2016 Aug, we are going use existing Java libraries to write a NEW Android application or NEW backend application. Considering the fact that both of Java & Kotlin can 100% using the existing Java libraries. If we pick Java instead of Kotlin, we have to sacrifice the beauty of compile-time Null-safe and do a lot of extra “work-arounds” in order to cope with the trade off (Backward compatibility) that we don’t even need ?

Kotlin sounds interesting? Null-Safe is only one of the major killing features.

There are at least 5+ killing features I am going to introduce.

Cautions/Disclaimer: If you keep reading the following Kotlin’s killing features, you will never want to go back to Java. Trust me, think twice before you do!

Zero Overhead Nullable Type, Nullable Chaining and Default Value

Java 8 has introduced a new Optional<T> Class into java.util package. As Optional<T> is just a value type (container) to wrap a value.

However, the lack of pattern matching in Java (A very power features in Scala), unwrapping and comparing the wrapped value are damn pain in Java. Optional<T> is proposed to be used ONLY for return type to raise the awareness of “no result”, hence, avoid NPE. Check to see the following example

// Optional Type Overhead
Optional<String> strOpt = null; // Compile OK

Optional<String> strOpt = Optional.empty(); // Compile OK

strOpt = null; // Compile OK

strOpt == null; // Compile OK => true

strOpt = Optional.of("gary"); // Compile OK

strOpt = Optional.ofNullable("gary"); // Compile OK

// cannot direct assign a value
strOpt = "gary"; // Compile error: Type mismatch
  
// cannot direct compare with a value
strOpt.equal("gary"); // Compile error: Type mismatch
  
strOpt.equal(Optional.of("gary")); // Compile OK, true
  

// unwrap and compare the wrapped value
if(strOpt.isPresent()) {
  final String str = strOpt.get();
  return str.equal("gary");
} 
else {
  return false
}

// do something when the wrapped value is not null
strOpt.ifPresent(str -> {
  doSth(str)
});
  
// Easy to be mis-used
// in some case,
// null is a good representation of nothing instead of empty String
String str = strOpt.orElse("");

// throw NullPointerException if the wrapped value is null
String str = strOpt.get();

Let’s see a simple example of Scala pattern matching (FYI):

// pattern matching in Option Type
val usernameOpt: Option[String] = Some("gary")

usernameOpt match {
    case Some("gary") => println("matched gary!")
    case Some("peter") => println("matched peter!")
    case Some(username) => println("found ${username}, but no username is matched")
    case None => println("No username is found")
}

Let’s see how powerful is Kotlin’s Nullable Type:

// Kotlin NullableType is different from java.util.Optional or scala.Option
// it is NOT a Value Type

var str: String? = null

str == null // Compile OK! => true 

str = "gary"  // Compile OK! 

str == null // Compile OK! => false
str == "gary" // Copmile OK! => true

// Optional chaining
str?.toUpperCase() == "GARY" // Compile OK! => true
str?.toLowerCase()?.capitalize() == "Gary" // Compile OK! => true

// Default value `?:`
val username = str ?: "N/A" // username is String now!

// Kotlin Smart cast - if
if(str is String) {
   // the Type of str is smart casted to `String`!!!
   println(str.toUpperCase())
}

// Kotlin Smart cast - when
when(str) {
  is String -> println(str.toUpperCase()) 
  else -> println("str is null")
}

From my experience, refactoring in Java/Scala from a Type to java.util.Optional/scala.Option Type is a disaster and seems like rewriting a whole part of the affected codes. But refactoring Kotlin’s Nullable Type is nearly zero-effort.

Type Inference

Type inference polishes the beauty of static-typed language and can boost the coding productivity to reach as fast as dynamic-typed level.

Java and Kotlin are both static and strong typing language. This characteristic is very important to large scale application.

Good Things Come With a Price

In Java, compared with dynamic and weak typing language like PHP or Javascript, you have to spend extra effort to specify the type definition for variables.

Sometimes, the type definitions are meaningless and verbose because

• It is too obvious to Human
• The compiler should clever enough to know the type
• Type definitions increase the cost of refactoring.

For example, when we create a map with seed values with type key: String value: Integer

// Java 9
final Map<String,Integer> abc = Map.of("a",1, "b", 2, "c", 3);

// Java >= 5
final Map<String,Integer> abc = new HashMap<String, Integer>() {{  
    put("a",1);
    put("b",2);
    put("c",3);
}};

final Integer c = abc.get("c");

// Question: 
// If you are asked to refactor from Map<String,Integer> to Map<String,String>,
// try to estimate the efforts!

In Kotlin,

let the compiler do it for you

We can skip type definition and let the compiler make type inference for us.

// val abc: Map<String,Int> = mapOf("a" to 1, "b" to 2, "c" to 3)
// the actual type of the Map is obvious
// thus we can skip Map<String,Int> and let kotlin compiler to make type inference
val abc = mapOf("a" to 1, "b" to 2, "c" to 3)

val abcd = abc + ("d" to 4) // ok!
val abce = abc + ("e" to "5") // compile error: Type mismatch

// val c: Int? = abc["c"]
var c = abc["c"] 

c = "2" // compile error: Type mismatch

// Same Question: 
// If you are asked to refactor from Map<String,Integer> to Map<String,String>,
// try to estimate the efforts!

The syntax is very similar to dynamic typed language but any type-mismatched operations would be considered as compilation error.

Kotlin with type inference can help us to write less-verbose code without sacrifice anything.

Default Argument & Named Argument

In a real world, there exist some situations we damn need default value instead of null. Java developers can either do a very ugly work around if-null-then-default value or do a verbose method overloading. For example,

// Ugly work around to save time (compared to method overload)
void doSomething(
  @NotNull String fname,
  @NotNull String lname,
  @Nullable String addr,
  @Nullable Gender gender
) {  
  requireNonNull(fname);
  requireNonNull(lname);
  if(addr == null) addr = "N/A";
  if(gender == null) gender = Gender.Unknown;
  // do sth
}
String lastName = "lastName";
String firstName = "firstName";
String gender = Gender.Male;
String address = "address";

// As we know the implementation will provide default value for null
// so we type null in the parameter...
// code-smell? WTF by new comer?
// Question: What is the null suppose to be?
doSomething(firstName,lastName,null,null);  
doSomething(firstName,lastName,address,null);  
doSomething(firstName,lastName,null,gender);  
doSomething(firstName,lastName,address,gender);

// without named paramenter...
// Can you notify the bug when you type out this?
// it is safe to compile but logically error 
// bug: lastName and firstName are swapped
doSomething(lastName,firstName,address, gender); 

// To avoid null and expose a better API
// without default and namged argument, method overloading is the only way
void doSomething(String fname, String lname) {
  doSomething(fname,lname,"N/A", Gender.Unknown);
}
void doSomething(String fname, String lname, String addr) {
  doSomething(fname,lname,addr, Gender.Unknown);
}
void doSomething(String fname, String lname, Gender gender) {
  doSomething(fname,lname,"N/A", gender);
}
void doSomething(String fname, String lname, String addr, Gender gender) {
  // do sth
}

// Question: 
// if you asked to add one more arugment let say "Phone"
// how many overloading is needed?
  

Either the “ugly work around” and the “verbose method overloading” are also not self-documented, hard to refactor/change in Java.

Kotlin support Named and Default Argument, it helps developers to create a more intuitive, meaningful and maintainable API.

// Default argument
fun doSomething(
  fname: String,
  lname: String,
  addr: String = "N/A",
  gender: Gender = Gender.Unknown
) {
  // do something that really need fname,lname, addr, gender..
}

val firstName = "firstName"
val lastName = "lastName"
val address = "Address"
val gender = Gender.Male

// Normally you can do this
doSomething(firstName, lastName, address, gender) // OK!
doSomething(firstName, lastName, address)  // OK!
doSomething(firstName, lastName)  // OK!

// Fail, compile error! Type mismatch! Expected String type
doSomething(firstName, lastName, gender) 

// It can be solved by Named Argument
// with Named Argument
doSomething(
  fname = firstName,
  lname = lastName,
  addr = address,
  gender = gender
) // OK!

// skip the address (3rd argument)
doSomething(
  fname = firstName,
  lname = lastName,
  gender = gender
) // OK!

// Order is not important!!
doSomething(
  addr = address,
  lname = lastName,
  fname = firstName
) // OK!

// Fail! compile error: lname is required
// because lname has no default value
doSomething(
  addr = address,
  fname = firstName
)

// Ask yourself:
// Is it possible to achieve the same level of conciseness in Java?

As the gist example has clearly demonstrate the power of Named and Default Argument. This is a fundamental and serious improvement in Kotlin compared with Java.

Once you get used to the Kotlin’s powerful Named and Default Argument to design your interface, you won’t go back to Java.

Extension is Awesome

In Java, we can not directly add functionalities on a Class. If some logics applied on a specific Type and have to be used multiple time in a project, Java developers get used to create a XXXUtils for Type XXX in order to follow the D.R.Y. principle.

Programming has no magic. All about Abstractions

Kotlin provided a much better abstraction to model the similar problems that are solved by “Java Utils Pattern” — Extension

Traditional Java Utils usage

// please focus on the function name & declaration 

// As we all know, String is a final class and we can't extend
class StringUtils {
  public static TypeA toTypeA(String str)
}

// Assume TypeA is from third party library that you can't extend
class TypeAUtils {
  public static Double calculateResult(TypeA a) 
}

// Similar to String, you can't extend Double
class DoubleUtils {
  public static Double toTwoDecimalPlace(Double d) 
}

String someString = "someString";

// The execution order is not as same as to our reading direction(top-to-bottom)
// it is difficult to read
final Double typeAResultWithRounding = 
  DoubleUtils.toTwoDecimalPlace(
    TypeAUtils.calculateResult(
      StringUtils.toTypeA(someString)
    )
  );

// flatten it?  better to read but more unnessecary variables are created
final TypeA typeA = StringUtils.toTypeA(someString);
final Double typeAResult = TypeAUtils.calculateResult(typeA);
final Double typeAResultWithRounding = DoubleUtils.toTwoDecimalPlace(typeArResult);
  
// Question: 
// How do a new comer would know to use exactly these three Utils?
// Normally, they would ask someone or implement a duplicate one for their use case.

How is Kotlin provided a better abstraction for this problem? We can directly add an “Extension” for a specific Type with a very simple syntax! (Very similar to javascript)

// Kotlin

// extension, give toTypeA() functionality to String
fun String.toTypeA(): TypeA { 
  return TypeA(str = this)
}

// give calculateResult() functionality to TypeA 
fun TypeA.calculateResult(): Double {
  return this.str.length + 0.123456789
}

// give toTwoDecimalPlace() functionality to Double
fun Double.toTwoDecimalPlace(): Double {
  return BigDecimal(this).setScale(2, RoundingMode.HALF_UP).toDouble()
}
val someString = "someString"

// Better than Utils pattern
// 1. By-design chainning from top-to-bottom which is better for reading
// 2. Extension are statically import(Unlike Swift), extension usages are tracable.
// 3. IDE autocomplete works well to identify extensions on a Type,
val typeAResultwithRounding = someString
                                .toTypeA()
                                .calculateResult()
                                .toTwoDecimalPlace()

// Even new comer would see the extra functionality in the IDE auto-complete list!!

“Java Utils Pattern” is not IDE-friendly, new comer won’t notice some functionalities are already implemented in the XXXUtils while Kotlin’s Extension is completely solved this problem.

Here are some screenshots to demonstrate the IDE auto-complete with the Kotlin extension

With Kotlin extension, you would never have to ask

Is that XXXUtils.someFunc() is implemented already?

and never have to search in the .utils folder. 100% of time you will find it in the auto-completed list.

Handy Data Class

In a strongly-typed language, we will create numerous “Value Object” to hold data by a explicit type to classify their domain. For example, API Response, API Request, Data Model, Proxy Object, etc.

It is a very common practice and should be as simple as possible.

After I have met with Scala and recently with Kotlin. The only Java impression on creating a “Value Object”:

Java is too verbose and too costly to be used for Functional Programming (Immutable approach)

Start reading the following Kotlin data class to get some insight and don’t forget to read the comment :) .

data class User(
  // primary construtor
  val id: UUID,
  val username: String,
  val firstName: String? = null,
  val lastName: String? = null,
  val address: String? = null,
  val isEmailVerified: Boolean = false
) {
  // getter only
  var fullName: String get() {
    return "${firstName} ${lastName}"
  }

  // a function inside a User
  fun doSth() {
    println("do something")
  }
}

// By default, Kotlin has generated very useful constructor for a data class
// with the power of the Named and Default Argument
// We can use it in the following ways

// firstName, lastName, address, isEmailVerified is not required
User(
  id = UUID.randomUUID(),
  username = "garylo123"
)

// but you can still override the default value
val gary = User(
  id = UUID.randomUUID(),
  username = "garylo123",
  firstName = "Gary",
  lastName = "LO",
  address = "HK Somewhere"
)

println(gary.username) // print "garylo123"
println(gary.fullName) // print "Gary LO"

gary.doSth() // print "do something"

// developer-friendly for debuging
println(gary) // print "User(id=229c7b64-7dd3-4b5f-80bd-c88dc15ed13e, username=garylo123, firstName=Gary, lastName=LO, address=HK Somewhere, isEmailVerified=false)"



// Data class provide a handy function .copy for pure immutable object
// if we want to update the address of `gary`, we create a new copy
// original gary won't be mutated 
val updatedUser = gary.copy(address = "Hong Kong Somewhere")

In Java, developers have to use comparatively poor way (mutable or builder pattern) to create an complex Object. For example,

// Only used for holding the Data. 
class MutableJavaDataObject {
  @NotNull UUID id;
  @NotNull String username;
  @Nullable String firstName;
  @Nullable String lastName;
  @Nullable String address;
  bool isEmailVerified = false
}

// Problem?
// 1. All properties are mutable
// 2. No Constructor, how do others know `id` and `username` should NOT be null?
// 3. In Java, One file can only contain one Class.
//    Even a class is just a few line....

How we use it in Java ?

// MutableJavaDataObject, https://gist.github.com/gaplo917/deee7a16bf9f60c69cfedb47884820fa

// created by empty contructor
MutableJavaDataObject mjdo = new MutableJavaDataObject();

// assign the value directly
mjdo.id = UUID.randomUUID();
mjdo.address = "Hong Kong";

// printing the class reference is useless in 99% of time
System.out.print(mjdo) // print "MutableJavaDataObject@xxxxxxx"

// bugs? missed to assign the mjdo.username but it is compile time safe


// Question:
// A safer way? Builder pattern? Seriously!? for every data object? 

// Using Kotlin would cost you the same amount of time 
// that you write MutableJavaDataObject (work around),
// but gives much cleaner, robuster and safer `data class`

Kotlin provides a very handy data class that

• leverage the power of Name and Default Argument on constructor
• provide handy .copy for writing pure immutable object
• is developer-friendly for debugging

It helps to reduce the verbosity of getter, setter and multiple constructor. What’s more, data class is by-default ready to be used in some popular JSON Serialization library such as GSON, Jackson.

If you are familiar with Java, without Name and Default Argument, you know that it is not feasible to create a “Value Object” that can achieve the same level of convenience as Kotlin's data class does.

“Kotlinize” Java Library

In a large scale application, consistency is the most important role to keep source codes more predictable and maintainable.

By default, Kotlin won’t encourage to create getter/setter function for a variable. Each variable has a get()/set(value) to implement:

class User {
    var name: String? = null
      get() {
        println("getting a username = ${field}")
        return field
      }
      set(nName) {
        println("changing to a new username ${nName} from ${field}")
        field = nName 
      }
  
}

fun main() {
    val user = User()
    
    user.name = "Gary LO"
    
    println("We get the username = ${user.name}")
    
    // Expected console output: 
    // changing to a new username Gary LO from null
    // getting a username = Gary LO
    // We get the username = Gary LO
}

Therefore, in pure Kotlin code we never writegetXXX() or setXXX(value). But, nearly 100% of Java library would use getter/setter.

How does Kotlin solve this discrepancy? Let see the “TextView” in Java Android library.

Kotlin will Kotlinize the Java “default” getter/setter into Kotlin style, you would never feel uncomfortable to use Java libraries.

If you are experience in using Java libraries in Scala, you must damn want this features, at least I do lol.

Better Functional Programming Support

Writing functional style code in Java is comparatively much more expensive than in Kotlin. Because Kotlin provided the following features:

• Type Inference
• Inexpensive Data Class (Immutable .copy features)
• Intuitive Type declaration for Functions/Lamdas, i.e.(Int)-> Int , (Int,Int) -> Bool instead of java.util.functions.BiFunction<T,U,R>...
• Support Destructing
• Every thing is an expression (easier to write declarative code)

// `to` is a infix function to create a Pair<L,R>
val pair = 1 to "one"

// decompose the pair
val (num,str) = pair

val list = listOf(1,2,3,4,5)

// destructing the list
val (a,b,c) = list

println("a = $a, b = $b, c = $c") 
// a = 1, b = 2, c = 3

// already include in kotlin std-lib
val head = list.head
val tail = list.tail

println(head) // 1
println(tail) // [2,3,4,5]

data class User(val id: Int, val name: String, val address: String)

val user = User(id = 1, name = "GARY LO", address = "Hong Kong")

// Destructing order is import!!
val (userId, userName, userAddress) = user

println("id = $userId, name = $userName, address = $userAddress")
// id = 1, name = GARY LO, address = Hong Kong

val list = listOf(1,2,3,4,5)

// destructing the list
val (a,b,c) = list

println("a = $a, b = $b, c = $c") 
// a = 1, b = 2, c = 3

// already include in kotlin std-lib
val head = list.head
val tail = list.tail

println(head) // 1
println(tail) // [2,3,4,5]

// Kotlin - currying function example

fun doCurrying(first: Int): (Int) -> ((Int, Int) -> Int) -> Int {
  return { second -> { f -> f(first,second) } }
}

val add = { a: Int, b: Int -> a + b }
val multiply = { a: Int, b: Int -> a * b }
val minus = { a: Int, b: Int -> a - b }

val curriedFour = doCurrying(4)
val curriedFourFive = curriedFour(5)

curriedFourFive(add) // 9
curriedFourFive(multiply) // 20
curriedFourFive(minus) // -1

// Every Thing is an expression
val input = 1

val result = if(input == 1) "Equal to one" else "Not Equal to One"

val result2 = when(input) {
   1 -> "Equal to one"
   else -> "Not equal to one"
}

val result3 = try {
    input / 0
    "Can be calculated"
  } catch(e: ArithmeticException) {
    "Can't be calculated"
  }

println(result)  // Equal to one
println(result2) // Equal to one
println(result3) // Can't be calculated

Major goodies (aforementioned)

• Compile-time Null Safe
• Zero Overhead Nullable Type, Nullable Chaining and Default Value
• Type Inference
• Default Argument & Named Argument
• Extension is Awesome
• Handy Data Class
• “Kotlinize” Java Library
• Better Functional Programming Support

Minor goodies

• Intuitive String Template
• Lots of handy function are implemented in Kotlin std-lib i.e. array.find …
• Multiple class or object in single file
• Support legacy JVM. Kotlin Runs on Java 6 and its interface can have default implementation just like in Java 8.
• Best IDE Support

Next — Part 3 : Picking Kotlin for Android — Swift in Android?

This is a long article and will be divided into four parts:

• Introduction of Kotlin & The Reasons behind the Choice
• Kotlin’s Killing Features (with details Java comparison)
• How is Kotlin in Android Development compared to Swift Development in iOS?
• Kotlin Pro Tips and Our Kotlin Use Case sharing on Android Development (To be continued)

Who am I ?

I am a senior mobile developer in Harborx. Harborx targets to build a simplified forex trading platform which provide fun, smooth and intuitive trading experience for everyone.

Before I had met with ❤ Kotlin, I have a rich experience with Java & Scala. Every time when a new comer asked me to compare Java with Scala, there are some “Java impressions” straightly come to my head:

• Java is too easy and verbose
• Null Pointer Exception (NPE, The Billon dollar mistake)
• Java 8 is better. But far from enough
• Writing functional style code in Java is comparatively costly — Difficult to use immutable object, no tuples, no type inference, clueless Function<T,R> , BiFunction<T,U,R> , Consumer<T> … , default mutable Collection, Map, Set.

In 2016 Aug, we started to build a new Harborx Android app. It is written by 100% Kotlin with Java Library.

After that, I think these “Java impressions” are still valid when comparing Kotlin to Java.

Kotlin Introduction

Kotlin is a relatively new and statically typed programming language for the JVM, Android and the browser. It is backed by JetBrains —The biggest IDE manufacturer in the world.

Brief Timeline

• In 2010, JetBrains started Kotlin Project.
• In 2011, JetBrains has clearly state their vision — Why JetBrains needs Kotlin.
• In 2012, JetBrains has make a first public Kotlin 0.x release.
• In 2013, JetBrains support Kotlin in Android Studio
• In 2016 Feb, Kotlin 1.0 was officially released.
• In 2016 May, Kotlin meets gradle
• In 2017 Mar, Kotlin 1.1 was officially released (with revolutionary coroutines features in preview).
• In 2017 Apr, Kotlin/Native Tech Preview: Kotlin without a VM

Interesting Facts

• JetBrains Official supports Kotlin for Android development.
• JetBrains claims that Kotlin is a programming language built for industrial instead of general purpose. The basic difference should more likely about thinking of “is this function commonly used in software industrial ? ” instead of “does this function increase the size of std-lib ?”.
  For example, some useful functions like string.replace, collection.find, collection.filterNotNull,are provided in Kotlin standard library while seldom provided in general purpose programming language like Swift and Java.

// Kotlin Standard Library provided

String.replace(
    oldChar: Char, 
    newChar: Char, 
    ignoreCase: Boolean = false
): String

// directly return a object in a collection 
// which is matched with the predicate
fun <T> Iterable.find(predicate:(T) -> Boolean): T?

// filter all null object in the collections
fun <T: Any> Iterable<T?>.filterNotNull(): List<T>

• Kotlin generate JVM byte code instead of source-to-source transpile to Java — No performance degradation if the generated byte code of Java & Kotlin are the same.
• Kotlin 1.1 support from Java 1.6 — Most of the legacy Android or Backend Project are supported.
• “Method Count on a Hello World Android Project(Disable Proguard)”* — Java(17,416), Kotlin 1.1.1(23,587), Scala 2.11(67,608)
• “Method Count on a Hello World Android Project(Enable Proguard)” * — Java (7,608), Kotlin 1.1.1(7,656), Scala 2.11(11,671),
• “Compile Time” of Kotlin is much faster than Scala/Groovy and very close to Java*

* Thanks to https://github.com/SidneyXu/AndroidDemoIn4Languages

The Reasons behind the Choice

1. The belief of ReactiveX. ReactiveX is a combination of the best ideas from the Observer pattern, the Iterator pattern, and functional programming. After spending two month of learning, researching and playing toy projects with RxJava and functional, we compared side-by-side with Java implementation. we found that Kotlin can fundamentally provide a much more intuitive and inexpensive way than Java on writing functional style codes, so that we can maximize the power of ReactiveX.
2. The belief of one of the best Android developer in the world — Jake Wharton. If you have gone through a lot of serious Android development, you must know this man (in Harborx, we use Cantonese “Jake 大神” to represent his name lol, “大神” in english is likely mean “Master”). Jake built a lot of high quality libraries for Android such as ButterKnife, Retrofit, okHttp, RxAndroid, RxBinding, Timber, etc. You can easily find his public Kotlin and Android talk on YouTube/Google plus/Twitter.
3. Kotlin has already reached the 1.0.0 milestone. In 2016 Aug, We expect 1.x.x version API is stable for production. It is the right time to start!
4. Learning curve of Kotlin is not high. Picking up Kotlin by a traditional Java developer should be less than 2 week.
5. Swift is very similar to Kotlin. We can nearly apply the same abstraction (Data structures, Extension, Rx…) to model the business flow. Rewriting same business logics between Android & iOS platform become easier and faster. In contrast, switching from Swift to Java would be very painful. For example, Swift developers usually use a lot of extensions to power up existing class while Java developers use “Utils” patterns and inheritance to give extra functionality on existing class.

Next — Part 2 : Picking Kotlin for Android — Killing Features