<

Kenneth Lundin

Head of the Erlang/OTP Team at Ericsson

Kenneth Lundin has been working with SW development since the late 70s. As a curiosity it can be mentioned that Kenneth was one of the pioneers in the use of C++ at Ericsson. He joined the Erlang/OTP project in it's early stages 1996 and has been working both with application components and the run-time system since then. Has been a technical leader and manager for the OTP team since 1998.

Past Activities

Kenneth Lundin
Code BEAM V
29 May 2020
13.00 - 13.15

An update from the OTP team

Kenneth will give updates on what the OTP team has done in the last few months, what are the projects they're working on, and what's going on on the research side.

Kenneth Lundin
Code BEAM Lite Virtual
03 Apr 2020
15.35 - 16.00

An update from the OTP team

Kenneth will give updates on what the OTP team has done in the last few months, what are the projects they're working on, and what's going on on the research side.

Kenneth Lundin
Code BEAM STO 2018
01 Jun 2018
09.50 - 10.05

OTP team update

An update from the OTP team.

Kenneth Lundin
Code BEAM STO 2019
16 May 2019
10.00 - 10.15

OTP Team update

Kenneth will give updates on what the OTP team has done in the last few months, what are the projects they're working on, and what's going on on the research side.

Kenneth Lundin
Code BEAM STO 2018
31 May 2018
12.25 - 12.50

Logger a new API for logging

The main goal with "logger" is to standardise an API for logging, allowing the application implementer to use this API without making any assumptions about the logging backend that will be used in the final system. That is, we want to remove the dependency, between applications and logging facility. The main goal is not to remove the need for good logging applications like Lager, but to lift the decision about logging from the low level application implementer to the high level system architect. This will also make it easier to combine applications from different providers - since the same API is always used. Thus, individual applications don't need a dependency to a logging backend such as Lager. That dependency is decided on system level instead.

We want a built-in logging feature which is "good" by default, but which can be customized and extended if needed.

The talk will tell you how it works and explain the design decisions.