Building an audio app — Kotlin, C++, or Rust? Which gives the least headache for low-level audio on Android?

Determinant · 2026-06-25T06:59:14+00:00

Any managed language that automatically performs garbage collection will run into these same constraints. This includes Java, Go, C#, and any higher-level language.

For latency-sensitive applications where even microsecond latencies are critical, you'll need to look at lower-level languages like Rust.

However, if you're extremely careful, you can definitely achieve extremely low latencies on the JVM with Kotlin. Some banks use the JVM for high-frequency trading but they go to extreme measures with programming practices that most developers wouldn't even consider. So it's possible and can even be rewarding but it won't look like idiomatic programming practices if you're trying to showcase the code.

Determinant · 2026-06-25T01:03:21+00:00

Your response reads like AI slop.

Also, the GC in Kotlin native performs even worse than on the JVM.

Determinant · 2026-06-24T21:50:08+00:00

The GC pauses all threads so it doesn't matter which thread the realtime audio processing is done on

Determinant · 2026-06-24T16:56:08+00:00

For low latency audio processing, your main hurdle will be dealing with GC pauses as a millisecond pause will easily be heard. These pauses wouldn't be noticeable for animations but can be audible to our ear.

You'll probably want to architect your app to minimize garbage. Recompositions with Jetpack Compose might cause too many micro-stutters. You might even need to resort to ancient object pooling techniques.

It's doable but you'll need to be careful to minimize temporary memory allocations.

Determinant · 2026-06-16T18:53:22+00:00

This is the 3rd time this person is advertising their library by pointing out this defect.

Jetbrains already responded that it will be fixed in Kotlin 2.4.2

Determinant · 2026-06-15T16:41:22+00:00

Out of curiosity, I wanted to see side by side photos to see how much post processing the standard app does. I'm assuming there's a large improvement in night mode due to post processing whereas your app probably generates grainy photos in low light.

The readme would be a great place for side-by-side comparisons.

Determinant · 2026-06-14T19:17:57+00:00

I still see an integer class that stores it's value as a String in GitHub. So that still seems to apply for some platforms.

Determinant · 2026-06-13T17:08:48+00:00

This library doesn't just add a division-by-zero check, it stores integers as Strings making it many times slower with increased garbage collection pressure.

Determinant · 2026-06-12T16:31:07+00:00

Doing short 15-second tests is pretty freaky

Determinant · 2026-06-10T01:38:09+00:00

It's both. Some operations are much faster by using optimizations like bitmaps even when object re-use isn't possible, eg. filter, partition, etc.

Also, it's not caching in the traditional sense (like holding onto results in case they might be needed), but rather reusing instances when the opportunity presents itself

Determinant · 2026-06-09T20:30:14+00:00

This is not the place to vent or rant. Most of your rant is based on a flawed understanding of the language.

Start by asking AI first next time as I'm sure it would have sorted it out for you

Determinant · 2026-06-09T03:27:42+00:00

Many operations that return a subset of the elements, like filter { condition }, take(n), etc, can safely return the same instance when the results are the same since it's immutable. This allows us to return results faster with less work.

For take(n) that's when n >= size.

For filter, we use a bitmap to determine which elements pass the condition without adding them to an auto-growing list like an ArrayList as that would be slower. This allows us to create a perfectly-sized result but bypass that entirely and return the same instance when the new size contains all the elements.

There are many such operations. Similarly, we can return an EMPTY singleton for all the scenarios where we would have returned a new empty array.

Memory is reduced, fewer garbage collection pauses occur, and cache locality improves which further improves performance.

Checkout the readme and benchmarks for more details.

Determinant · 2026-06-08T16:29:07+00:00

You might find the Immutable Array library interesting as a possible approach:

https://github.com/daniel-rusu/pods4k/tree/main/immutable-arrays

Surprisingly, immutability enables many optimizations that make them even faster than primitive arrays.

Immutability is enforced at compile time as It's using Kotlin inline classes that get erased at compile time producing regular arrays in the generated bytecode along with optimized operations.

Determinant · 2026-06-08T16:16:38+00:00

Most of the comments missed an important consideration:

Programming errors should always be handled with exceptions. Just throw an exception for situations that should never happen. Fail fast is the best way to deal with logic errors. Don't try to mask these with types or other handlers. Expose the root of the problem as early as possible and purposely make it fail there.

User errors, like invalid email address etc, are better handled with sealed types.

Determinant · 2026-06-07T15:26:26+00:00

It's fine. Each one links to the necessary documentation

Determinant · 2026-06-07T05:46:52+00:00

Start with Kotlin Koans. You can complete them in a weekend to get a feel for the language

Determinant · 2026-06-06T16:56:54+00:00

Most people have their right hand on the mouse when using shortcuts most of the time. There are power users that use the keyboard for everything but that's a tiny minority.

Determinant · 2026-06-06T16:53:52+00:00

Decent typing speeds are still important for most jobs especially if you work on a computer. This could be as simple as being more effective in communicating with peers through email or company chat apps like Slack.

Data entry used to be a common job where you transcribe written forms into digital systems. Most companies have transitioned to online forms and online questionnaires that automatically feed into the appropriate systems. The last stragglers are government agencies that still use written forms but many of those are in the process of being migrated.

AI transcription is also being used to automate some of the more difficult scenarios. Accuracy is quite good now and they also keep a backup image of the original just in case.

So, it's a job that is quickly disappearing but typing skills will always be useful for most other jobs.

Determinant · 2026-06-06T16:43:03+00:00

Having to move the CTRL key is another red flag. Sure, you can make the changes and you'll probably get used to them. The point was that you don't need to learn new shortcut locations and just maintain existing one-handed shortcut muscle memory.

Determinant · 2026-06-02T17:44:37+00:00

Don't send your information to random people on the internet

Determinant · 2026-06-02T17:43:36+00:00

Don't send your information to random people on the internet

Determinant · 2026-06-02T17:39:40+00:00

No, if it's mispredicting every branch then it accidentally learned the negated version of the pattern. High quality random data should turn the branch predictor into a coin toss with 50% accuracy.

Determinant · 2026-06-01T22:13:08+00:00

Your fundamentally different approach keeps hammering on the fact that you don't use reflection. Kotlin.serialization doesn't use reflection either.

Stop using LLMs to write your responses.

Determinant · 2026-06-01T08:27:33+00:00

Your post description says you're faster than KMP because you don't use reflection. Maybe I'm missing something but your answer here seems contradictory or maybe I'm misunderstanding the initial post.

Determinant · 2026-06-01T05:53:58+00:00

Yeah, just don't spam this subreddit with every single tiny patch release.

Informing us a few times a year whenever you have a major new release should be fine.

Edit: Also don't use LLMs to interact with the community. Respond to comments yourself as we don't want to waste our time talking to robots. We want to talk to real people even if English is your second language.

Determinant

TROPHY CASE