How would one do dependency injection in scala?

I haven't done so myself, but most DI frameworks work at the bytecode level (AFAIK), so it should be possible to use them with any JVM language.

Standard Java DI frameworks will usually work with Scala, but you can also use language constructs to achieve the same effect without external dependencies.

A new dependency injection library specifically for Scala is Dick Wall's SubCut.

Whereas the Jonas Bonér article referenced in Dan Story's answer emphasizes compile-time bound instances and static injection (via mix-ins), SubCut is based on runtime initialization of immutable modules, and dynamic injection by querying the bound modules by type, string names, or scala.Symbol names.

You can read more about the comparison with the Cake pattern in the GettingStarted document.

In addition to the answer of Dan Story, I blogged about a DI variant that also uses language constructs only but is not mentioned in Jonas's post: Value Injection on Traits (linking to web.archive.org now). This pattern is working very well for me.

I have shown how I created a very simple functional DI container in scala using 2.10 here.

Dependency Injection itself can be done without any tool, framework or container support. You only need to remove news from your code and move them to constructors. The one tedious part that remains is wiring the objects at "the end of the world", where containers help a lot.

Though with Scala's 2.10 macros, you can generate the wiring code at compile-time and have auto-wiring and type-safety.

See the Dependency Injection in Scala Guide

Previous posts covered the techniques. I wanted to add a link to Martin Odersky's May 2014 talk on the Scala language objectives. He identifies languages that "require" a DI container to inject dependencies as poorly implemented. I agree with this personally, but it is only an opinion. It does seem to indicate that including a DI dependency in your Scala project is non-idiomatic, but again this is opinion. Practically speaking, even with a language designed to inject dependencies natively, there is a certain amount of consistency gained by using a container. It is worth considering both points of view for your purposes.

https://youtu.be/ecekSCX3B4Q?t=1154

A recent project illustrates a DI based purely on constructor injection: zalando/grafter

What's wrong with constructor injection again?

There are many libraries or approaches for doing dependency injection in Scala. Grafter goes back to the fundamentals of dependency injection by just using constructor injection: no reflection, no xml, no annotations, no inheritance or self-types.

Then, Grafter add to constructor injection just the necessary support to:

• instantiate a component-based application from a configuration
• fine-tune the wiring (create singletons)
• test the application by replacing components
• start / stop the application

Grafter is targeting every possible application because it focuses on associating just 3 ideas:

• case classes and interfaces for components
• Reader instances and shapeless for the configuration
• tree rewriting and kiama for everything else!

I would suggest you to try distage (disclaimer: I'm the author).

It allows you to do much more than a typical DI does and has many unique traits:

1. distage supports multiple configurations (e.g. you may run your app with different sets of component implementations),
2. distage allows you to correctly share dependencies across your tests and easily run same tests for different implementations of your components,
3. distage supports roles so you may run multiple services within the same process sharing dependencies between them,
4. distage does not depend on scala-reflect (but supports all the necessary features of Scala typesystem, like higher-kinded types).

You may also watch our talk at Functional Scala 2019 where we've discussed and demonstrated some important capabiliteis of distage.