Programming without a stack trace: When abstractions become illusions

This insightful article by Gregor Hohpe covers:

* Evolution of programming abstractions. * Challenges of cloud abstractions. * Importance of tools like stack traces for debugging, especially in distributed systems.

Gregor emphasizes that effective cloud abstractions are crucial but tricky to get right. He points out that debugging at the abstraction level can be complex and underscores the value of good error messages and observability.

The part about the "unhappy path" particularly resonated with me:

"The unhappy path is where many abstractions struggle. Software that makes building small systems easy but struggles with real-world development scenarios like debugging or automated testing is an unwelcome version of “demoware” - it demos well, but doesn’t actually work in the real world. And there’s no unlock code. ... I propose the following test for vendors demoing higher-level development systems:

1. Ask them to enter a typo into one of the fields where the developer is expected to enter some logic.

2. Ask them to leave the room for two minutes while we change a few random elements of their demo configuration. Upon return, they would have to debug and figure out what was changed.

Needless to say, no vendor ever picked the challenge."

Why it interests me?

I'm one of the creators of Winglang (https://github.com/winglang/wing), an open-source programming language for the cloud that allows developers to work at a higher level of abstraction.

We set a goal for ourselves to provide good debugging experience that will allow developers to debug cloud applications in the context of the logical structure of the apps.

After reading this article I think we can rephrase the goal as being able to easily pass Gregor's vendor test from above :)