Scala Creator Martin Odersky Warns Software Engineers Overuse Rust

Ryan Peterman

Martin Odersky argues that writing non-garbage-collected code in memory-abundant application layers is an unnecessary intellectual exercise rather than a practical engineering choice.

AI-assisted summary of Creator of Scala: Rust, Zig, Python vs Scala | Martin Odersky — original source. Check the original for full context.

Source published: 2026-09-26

Key ideas

Martin Odersky argues that Rust is increasingly overused higher up the application stack, where garbage collection would simplify development with negligible latency impact if memory is available. (0:00)
Scala research is exploring static reference tracking within its type system to allow safe manual memory allocators akin to Zig without runtime garbage collection. (0:00)
Odersky favors Zig's compile-time system over Rust's macro system, comparing Zig's metaprogramming to Scala 3's guaranteed inlining model that prevents post-expansion type errors. (3:15)
While mainstream languages like Python converge toward functional features like pattern matching, Python's optional typing remains distinct from Scala's always-on, foundational type guarantees. (6:17)

Detailed notes

## Background Published on YouTube by Ryan Peterman on September 19, 2026, this video features an interview clip with Martin Odersky, the creator of Scala. The conversation focuses on comparing Scala to other major programming languages, specifically Rust, Zig, Go, and Python.

## TL;DR Martin Odersky evaluates the practical trade-offs of modern programming languages, arguing that while Rust excels in low-memory environments, it is often overused in application layers where modern garbage collectors simplify engineering. He contrasts the expressive power and compile-time inlining models of Zig and Scala 3 against Rust's macros, while also discussing ongoing Scala research into statically verified manual memory allocation. Finally, Odersky examines dynamic languages like Python and Scheme, highlighting industry-wide convergence toward functional paradigms while emphasizing Python's dominance as a glue language against Scala's foundational, always-on static type safety.

## Atmosphere & style The discussion carries a measured, deeply analytical, and reflective tone grounded in decades of compiler engineering experience. Rather than defending dogma, Odersky offers candid, nuanced critiques—such as calling non-GC usage in high-memory environments an intellectual flex—while maintaining genuine admiration for the distinct design philosophies of systems languages like Zig and Rust. Listening feels like an insightful technical masterclass where practical engineering realities are weighed carefully against theoretical purity.

## Bulletin - [00:00](https://www.youtube.com/watch?v=SyltKRA8ErU&t=0s) Martin Odersky argues that Rust is increasingly overused higher up the application stack, where garbage collection would simplify development with negligible latency impact if memory is available. - [00:00](https://www.youtube.com/watch?v=SyltKRA8ErU&t=0s) Scala research is exploring static reference tracking within its type system to allow safe manual memory allocators akin to Zig without runtime garbage collection. - [03:15](https://www.youtube.com/watch?v=SyltKRA8ErU&t=195s) Odersky favors Zig's compile-time system over Rust's macro system, comparing Zig's metaprogramming to Scala 3's guaranteed inlining model that prevents post-expansion type errors. - [06:17](https://www.youtube.com/watch?v=SyltKRA8ErU&t=377s) While mainstream languages like Python converge toward functional features like pattern matching, Python's optional typing remains distinct from Scala's always-on, foundational type guarantees.

## Key takeaways - [00:00](https://www.youtube.com/watch?v=SyltKRA8ErU&t=0s) Rust delivers superior low-level performance guarantees and operates with a minimal memory footprint, making it ideal for embedded and systems programming. - [00:00](https://www.youtube.com/watch?v=SyltKRA8ErU&t=0s) Modern garbage collectors reduce pause times to negligible amounts, but achieving high GC performance inherently requires a substantial allocation of memory. - [00:00](https://www.youtube.com/watch?v=SyltKRA8ErU&t=0s) Writing non-GC code in high-level application layers with abundant memory often acts as an intellectual exercise rather than a sensible engineering decision. - [00:00](https://www.youtube.com/watch?v=SyltKRA8ErU&t=0s) Go deliberately constrained language features and delayed generics, creating an exceptionally uniform coding style that makes reading unfamiliar codebases easy. - [00:00](https://www.youtube.com/watch?v=SyltKRA8ErU&t=0s) Scala cannot disable its garbage collector in production today, but active research focuses on type-level reference tracking to safely enable custom manual memory allocators. - [03:15](https://www.youtube.com/watch?v=SyltKRA8ErU&t=195s) Zig's `comptime` metaprogramming and smart inlining provide a cleaner and more expressive alternative to Rust's macro system. - [03:15](https://www.youtube.com/watch?v=SyltKRA8ErU&t=195s) Unlike C++ template expansion which frequently causes deep post-expansion type errors, Scala 3 verifies type correctness prior to inline rewriting. - [03:15](https://www.youtube.com/watch?v=SyltKRA8ErU&t=195s) Scala's `inline` modifier is mandatory rather than discretionary, assuring developers that function call overhead will be completely eliminated at compile time. - [03:15](https://www.youtube.com/watch?v=SyltKRA8ErU&t=195s) Inlining in Scala operates directly on typed abstract syntax trees, enabling optimizations like unrolling known lambda literals to remove allocation costs. - [06:17](https://www.youtube.com/watch?v=SyltKRA8ErU&t=377s) Among dynamically typed languages, Python stands out for ubiquity and readability, whereas Scheme represents theoretical elegance rooted in lambda calculus. - [06:17](https://www.youtube.com/watch?v=SyltKRA8ErU&t=377s) Modern programming languages across ecosystems are converging toward functional features, including pattern matching, closures, and polymorphism. - [06:17](https://www.youtube.com/watch?v=SyltKRA8ErU&t=377s) Scala maintains an 'always-on' foundational type system, contrasting with Python's optional type annotations evaluated by external tools like Mypy or Pyright. - [06:17](https://www.youtube.com/watch?v=SyltKRA8ErU&t=377s) Scala 3 adopted indentation-based syntax, bringing its visual readability close to Python while preserving strong static typing. - [06:17](https://www.youtube.com/watch?v=SyltKRA8ErU&t=377s) Python's enduring superpower is acting as an effective glue language that bridges high-level developer scripts with high-performance C and C++ backends.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=SyltKRA8ErU&t=0s) Comparing Rust, Go, and Scala: Memory Management and Language Constraints

When evaluating Rust against Scala, Martin Odersky points out that Rust operates much closer to the metal and provides superior performance guarantees. Scala relies on garbage collection; while modern garbage collectors are "brilliant" and reduce pause times to negligible lengths, running GC fast fundamentally requires a substantial chunk of memory. Rust, by contrast, can operate within a minimal memory footprint, making it far better suited for embedded systems and low-level environments.

However, Odersky argues that Rust is currently overused across the industry. Developers frequently push Rust higher up the software stack into domains where a garbage collector would perform perfectly well. To him, writing non-GC code in application layers where ample memory exists feels like an intellectual flex—"an exercise in... just intellectual that I can do it"—rather than a practical engineering choice. If memory overhead is tolerable, using a garbage collector simplifies development considerably.

Turning to Go, Odersky characterizes it as a language that intentionally lags behind modern language evolution. Designed around the conventions and standards of the 1990s, Go remained deliberately minimal for years. While the eventual addition of generics represented a major step forward, the language remains constrained in what developers can express. That limitation brings a distinct cultural and practical benefit: it forces an exceptionally uniform coding style. Because developers have few stylistic ways to solve a problem, jumping into an unfamiliar codebase and reading someone else's code is straightforward.

When asked whether developers can disable Scala’s garbage collector, Odersky explains that this is not possible in production today. Research initiatives in Scala explore custom memory allocators akin to Zig's manual allocation model. The classic peril of manual allocators is leaking references into memory that has already been reclaimed, causing dangling pointers to access undefined memory. Scala's advanced type system can now track references statically to prevent such safety violations at compile time while allowing custom allocators, though this work has not yet shipped for production use.

- **Rust's Core Advantage:** Minimal memory footprint, no GC pauses, ideal for embedded and systems programming. - **The Rust Misuse Case:** Forcing borrow-checker semantics higher up the stack when heap memory is abundant. - **Go's Trade-off:** Feature minimalism and historical delay in adopting features like generics, offset by code readability and cross-team consistency. - **Scala Non-GC Research:** Exploring static reference tracking within the type system to allow safe, custom manual allocators without runtime GC panics.

---

[03:15](https://www.youtube.com/watch?v=SyltKRA8ErU&t=195s) Zig vs Rust: Compile-Time Inlining and Metaprogramming

Examining the community debates between Zig and Rust, Odersky highlights Zig's compile-time system (`comptime`) and its smart inlining as clean, expressive, and powerful. By contrast, he views Rust's macro system as noticeably more "clunky."

Scala 3 implements a metaprogramming model that closely parallels Zig's philosophy, relying on explicit inlining and compiler optimizations rather than opaque text/token expansions. However, Scala adds a crucial safety restriction: inlining cannot introduce new type errors. In systems like C++ templates, template expansion frequently triggers deeply nested, terrifying type errors after expansion, making debugging miserable. Scala guarantees that expanded inline code remains type-correct by validating types beforehand.

To clarify what "inlining" means in this context, Odersky explains that placing the `inline` modifier in front of a Scala function instructs the compiler to rewrite call sites before generating bytecode or machine code. Working directly on typed syntax trees:

1. The compiler locates calls to the `inline` function. 2. It replaces the call site directly with the function's body. 3. It performs contextual simplifications—such as recognizing when an argument is a known lambda literal and forwarding the call directly to avoid lambda allocation overhead.

Crucially, unlike standard compiler optimizers that exercise arbitrary discretion over whether a function call gets inlined, an `inline` construct in Scala (like `comptime` in Zig or `constexpr` in C++) is mandatory. Developers can architect code relying on the guarantee that the abstraction overhead will be completely eliminated.

```mermaid flowchart TD accTitle: Inline Expansion Pipeline accDescr: Diagram showing how an inline function call is transformed by the compiler into an optimized function body.

subgraph CompileTime ["Compile-Time Typing Phase"] Call["Function Call Site"] --> Inspect["Compiler Inspects Typed AST"] Inspect --> Replace["Replace Call with Function Body"] end

subgraph Optimization ["Compiler Optimization Pass"] Replace --> Unroll["Unroll / Forward Known Lambdas"] Unroll --> OptBody["Optimized Direct Execution (Zero Overhead)"] end ```

---

[06:17](https://www.youtube.com/watch?v=SyltKRA8ErU&t=377s) Dynamically Typed Languages: Python, Scheme, and the Convergence with Scala

Among dynamically typed languages, Odersky single out two standouts: Python, due to its ubiquity and clean, highly readable syntax, and Scheme, for its rigorous foundations in computer science theory and lambda calculus. Although Scheme represents theoretical purity, Python is "100 times more popular."

When comparing Scala to Python, Odersky observes that programming languages across the industry are increasingly converging toward a shared feature set predominantly borrowed from functional programming:

- Pattern matching (recently introduced to modern Python) - Strong type system constructs and optional type syntax - Generics and polymorphism - First-class closures and lambdas

Despite this convergence, a fundamental divide remains between the two languages. Scala's type system is strong, foundational, and "always on," providing rigorous static guarantees that entire categories of invalid states cannot occur. Python's typing system consists of optional type annotations evaluated by external type checkers (such as Mypy or Pyright), embedded in an ecosystem and community culture that historically does not rely on or enforce types as strictly.

Syntactically, Scala 3 has moved remarkably close to Python with its indentation-based, optional-brace syntax, making Scala feel like a strongly typed sibling running on enterprise-grade virtual machines. At the same time, Odersky acknowledges Python's undisputed superpower: acting as the ultimate "glue language," seamlessly and efficiently binding high-level application scripts to optimized, high-performance C and C++ backends such as NumPy and pandas.

## Notable quotes > [00:00](https://www.youtube.com/watch?v=SyltKRA8ErU&t=0s) an exercise in... just intellectual that I can do it — Martin Odersky

> [00:00](https://www.youtube.com/watch?v=SyltKRA8ErU&t=0s) brilliant — Martin Odersky

> [03:15](https://www.youtube.com/watch?v=SyltKRA8ErU&t=195s) clunky — Martin Odersky

> [03:15](https://www.youtube.com/watch?v=SyltKRA8ErU&t=195s) comptime — Martin Odersky

> [03:15](https://www.youtube.com/watch?v=SyltKRA8ErU&t=195s) inline — Martin Odersky

> [06:17](https://www.youtube.com/watch?v=SyltKRA8ErU&t=377s) 100 times more popular — Martin Odersky

> [06:17](https://www.youtube.com/watch?v=SyltKRA8ErU&t=377s) always on — Martin Odersky

> [06:17](https://www.youtube.com/watch?v=SyltKRA8ErU&t=377s) glue language — Martin Odersky

## Mentioned Martin Odersky, Ryan Peterman, Scala, Scala 3, Rust, Zig, Go, Python, Scheme, C++, C, Mypy, Pyright, NumPy, pandas

## Video description This is a clip from the longer conversation when you can find here where I interviewed Martin Odersky who is the creator of Scala: https://www.youtube.com/watch?v=LdN4sPWM-WY

[Source](https://www.youtube.com/watch?v=SyltKRA8ErU)

中文简报

Scala创始人Martin Odersky警示软件工程师过度使用Rust Martin Odersky认为，在内存充裕的应用层编写无垃圾回收的代码，只是一种不必要的智力挑战，而非切合实际的工程选择。 Martin Odersky评估了现代编程语言的实际权衡，认为尽管Rust在低内存环境中表现优异，但在现代垃圾回收器足以简化工程的应用层中往往被过度使用。他将Zig和Scala 3的表达能力及编译期内联模型与Rust的宏系统进行了对比，同时探讨了Scala在静态验证手动内存分配方面的最新研究。最后，Odersky审视了Python和Scheme等动态语言，指出了整个行业向函数式范式靠拢的趋势，并强调了Python作为胶水语言的主导地位与Scala立足根本、始终开启的静态类型安全性之间的差异。 Martin Odersky认为，Rust在应用栈较高层级中被日益过度使用，而在内存充足的情况下，垃圾回收能够简化开发且对延迟的影响微乎其微。 (0:00) Scala的研究正在探索其类型系统内的静态引用跟踪，以期在无需运行时垃圾回收的情况下，实现类似于Zig的安全手动内存分配器。 (0:00) 相较于Rust的宏系统，Odersky更青睐Zig的编译期系统，并将Zig的元编程比作Scala 3的有保障内联模型，后者能防止展开后出现类型错误。 (3:15) 尽管Python等主流语言正在向模式匹配等函数式特性靠拢，但Python的可选类型与Scala始终开启的底层基础类型保障依然截然不同。 (6:17)

Reading summary

Scala creator Martin Odersky argues that while modern programming languages are converging on functional programming paradigms, engineering choices must be guided by practical trade-offs between memory overhead, metaprogramming safety, and type guarantees rather than theoretical complexity. Systems Control Versus Application Garbage Collection (0:00) Odersky contrasts the memory architectures of Rust and Scala, observing that Rust operates close to the hardware with a minimal memory footprint, making it well-suited for embedded systems and low-level development. However, he argues that the industry often misapplies Rust by forcing borrow-checker semantics high up the software stack where ample memory exists. Because modern garbage collectors reduce pause times to negligible lengths when provided adequate heap space, Odersky considers writing non-GC code in everyday application layers an unnecessary intellectual exercise rather than a practical engineering decision. In contrast to Rust's complexity, Odersky notes that Go deliberately constrained language evolution by following 1990s conventions, which, despite delaying features like generics, enforces a uniform style that simplifies code reading. Meanwhile, experimental research in Scala is exploring safe manual memory management similar to Zig's allocator model, using Scala's type system to statically track references and prevent dangling pointers, though this capability has not yet shipped for production use. Deterministic Compile-Time Inlining and Metaprogramming (3:15) When analyzing compile-time architectures, Odersky praises Zig's compile-time system (`comptime`) and smart inlining as clean and expressive, contrasting it with Rust's macro system, which he views as clunky. Scala 3 adopts a similar metaprogramming philosophy centered on explicit inlining and direct compiler optimization rather than token-based expansion. Crucially, Scala requires inlined code to be type-validated beforehand, preventing the deeply nested, difficult-to-debug type errors common in C++ template expansions. Under this model, the `inline` modifier in Scala functions as a mandatory compiler directive rather than an optional optimizer heuristic. The compiler rewrites calls directly on typed abstract syntax trees, substituting function bodies and performing contextual simplifications—such as inlining known lambda literals to bypass allocation overhead entirely. This mechanism provides developers with guaranteed elimination of abstraction overhead at runtime. Functional Convergence and Dynamic Glue Languages (6:17) Odersky highlights that both static and dynamic languages are converging toward core functional programming concepts, including pattern matching, closures, and polymorphism. While Scheme represents theoretical purity in lambda calculus, Python dominates in real-world adoption due to its readable syntax. Scala 3 adopted an optional-brace, indentation-based syntax that visually mirrors Python while operating on strongly typed virtual machines. Despite syntactic similarities, Odersky points out a fundamental division: Scala maintains an omnipresent, rigid type system that guarantees state correctness at compile time, whereas Python uses optional annotations checked by external tools like Mypy and Pyright. Nonetheless, Python retains an unmatched advantage as a glue language, effectively bridging high-level scripting with low-level, high-performance C and C++ libraries like NumPy and pandas. While language designs increasingly share functional syntax and compile-time capabilities, production environments still face distinct operational trade-offs, and Scala's efforts to provide safe manual memory allocation without a runtime garbage collector remain an ongoing research project.

Source quotes

[0:00] Martin Odersky: an exercise in... just intellectual that I can do it [0:00] Martin Odersky: brilliant [3:15] Martin Odersky: clunky [3:15] Martin Odersky: comptime [3:15] Martin Odersky: inline [6:17] Martin Odersky: 100 times more popular [6:17] Martin Odersky: always on [6:17] Martin Odersky: glue language

Original transcript

[0:00] when you compare you know Rust or Go [0:03] with Scola what are the pros and cons of [0:06] the different language designs what's [0:08] something that Rust does better than [0:10] Scola something that Scola does better [0:12] than Rust [0:13] >> so Rust is closer to the metal you have [0:15] better performance guarantees I guess uh [0:18] the fact that Scala is a garbage [0:20] collected language means that you always [0:22] have some pauses I mean garbage [0:24] collection collectors have become quite [0:26] quite capable I mean they're brilliant [0:28] and the pauses are really very very [0:30] small but it's fact it's it's a fact [0:32] that you do need a big chunk of memory [0:36] to run fast and I guess Rust could could [0:39] run in much much smaller memory so I [0:41] believe that's that's better for [0:43] embedded systems and things like that I [0:46] believe right now rust is actually [0:47] overused because a lot of people push [0:50] sort of rush rust for things higher [0:52] higher up in the stack where you a [0:55] garbage collector is fine but uh [0:57] essentially you you still want to write [0:59] code without and that is for me a bit an [1:04] exercise in [1:06] uh I don't know just intellectual that I [1:09] can do it I I don't think really think [1:11] there's a there's a big sense in it that [1:13] if you have the memory for a garbage [1:15] collector you should absolutely use one [1:17] because it makes a lot of things uh [1:19] simpler so yes of course if given enough [1:23] uh brains I can write code around and I [1:26] can do that but why should you I I mean [1:28] it it it it can be much simpler. [1:31] So that was for R. Uh for go is um sort [1:36] of a language a bit that that lags [1:39] behind. I mean was intentionally [1:41] designed to be to be very very small and [1:44] essentially to be the standards of the [1:45] languages in the '9s. Uh so now they [1:48] have gotten generics which is a big [1:50] step. So I believe that sort of is sort [1:53] of a step forward for that but it's [1:56] still a fairly limited language what you [1:58] can do which has an advantage that [2:01] essentially it is forces a very uniform [2:04] style because there's not much of [2:06] different things you can do and that's [2:08] probably it a culture foster to do [2:11] things in a certain way which makes it [2:13] easier to essentially read one's other's [2:15] programs and and essentially jump in a [2:18] new code base and things like that. So I [2:20] think that would be my main advantage of [2:22] go that I see there. [2:24] >> Is it possible to turn off the garbage [2:27] collector in Scola? [2:28] >> Not in production. Uh so we have some [2:31] research that uh would let you use [2:34] essentially your own memory allocators [2:36] and things like that. Uh uh the the way [2:39] let's say Zigg does it. The problem with [2:42] that is always that you uh you you can [2:45] leak references into memory that you [2:47] reclaim and then all hell breaks use [2:50] lose essentially your your pointers [2:53] point to memory that's undefined and and [2:56] so but in in Scala we we now have a very [2:59] good way to actually track these [3:01] references so we can actually prevent [3:03] that statically by the type system that [3:05] this will never happen and you can still [3:06] have your own allocator. That said, we [3:09] haven't really shipped that in [3:11] production yet. So, right now, I would [3:12] say you use the garbage collector, [3:14] escala. Yeah, [3:15] >> I see uh a lot on the internet people [3:18] comparing Rust and Zigg or kind of a [3:20] fierce debate on which one is better. [3:24] When you think about Rust versus Zigg, [3:26] what are the merits of the two compared [3:29] comparing to each other? So what I can [3:31] see is ZIK has a really nifty uh compile [3:35] time uh uh uh construct uh essentially [3:39] inlining where the compiler does smart [3:41] inlining and and and that is quite clean [3:46] and quite powerful and [snorts] Rust has [3:49] has macros but I think they're more [3:50] clunky than there is than the zik [3:52] version. Um in Scala we have something [3:55] quite close to zik. We also have [3:57] essentially very a thing that's based on [4:00] on inlinining and optimizations by the [4:03] compiler. Uh but we have a restriction [4:06] which I believe sik doesn't have and [4:08] that [snorts] is that um there cannot be [4:11] additional type errors after inlining. [4:13] So the thing is you inline and then the [4:16] question is is the inline program [4:17] guaranteed correct uh so type correct or [4:21] might you have type errors. The typical [4:23] example where you might have type errors [4:25] is C++ templates. In fact that's quite [4:28] quite scary in C++ that you can expand a [4:32] template and then you get very very [4:34] complex type errors and very very hard [4:36] to to to debug things. So ZIK is I [4:39] believe is much better because the the [4:40] inlining mechanism is much ser. [4:43] >> When you say inlining can you explain [4:45] the concept? Inlining just means that uh [4:48] in in Scala we can write inline in front [4:50] of a of a function and that means that [4:53] the compiler will uh before it starts [4:57] code generating. So during the time when [5:00] it looks at the type code which are [5:02] trees it will take the function body [5:05] when it sees a function call to that [5:07] function it will take the call and [5:09] replace it by the body and then it will [5:11] do some optimizations. it can say okay [5:14] so here we have essentially an app an [5:16] application to let's say a value which [5:20] is a lambda and but I know where the [5:22] lambda points to so let me forward the [5:24] call right to the function uh so and and [5:27] with that you can already do quite a bit [5:30] of uh essentially optimizations which [5:33] are guaranteed because the the inliner [5:36] must inline that's not a thing like an [5:39] optimizer has essentially discretion [5:41] whether they want to inline things or [5:43] not and so you can never rely on that [5:45] but an an inliner which is uh [5:48] essentially a compile time based on the [5:50] typer must inline so you can rely on it [5:53] and const explore by in in zik and C++ [5:56] is essentially very similar [5:58] >> okay so it's a way to get rid of the [6:01] function call or the overhead of a [6:02] function call and tell the compiler you [6:06] can do more because it's all I guess in [6:09] line [6:10] >> yeah you reveal the implementation and [6:12] That means you you can you can uh the [6:15] compiler can do something with that. [6:17] >> When you think about all the dynamically [6:19] typed languages, um which one stands out [6:22] as one that you think is kind of the [6:25] best among them? [6:26] >> Python is ubiquitous. Um and it has a [6:30] nice syntax. It uh a lot of the Python [6:34] programs look like they're very easy to [6:36] read. So that's definitely an advantage. [6:39] and and the other one would probably be [6:42] something like scheme uh which is sort [6:44] of very grounded in computer science [6:47] theory and lambda calculus and things [6:49] like that. So both of them are sort of [6:51] interesting in their own way but of [6:53] course Python is 100 times more popular. [6:56] >> If you compare Scola to Python for [6:59] instance I guess what are the trade-offs [7:01] that the two languages took? I think the [7:04] gap is closing because Python now [7:06] actually has an optional type syntax and [7:10] and a number of type checkers that check [7:11] that syntax in Python is getting some of [7:14] the features that Scala had since the [7:16] beginning like pattern matching is in [7:18] one of the the recent Pythons. So I [7:21] think actually the gap is closing not [7:22] just between Python and Scala but [7:24] between a lot of programming languages [7:26] in general. There sort of all drift to a [7:30] standard set of features which mostly [7:32] come from functional programming [7:33] actually pattern matching for instance [7:36] strong type systems uh generics [7:38] polymorphism all these things came from [7:41] closures all these things came from [7:43] functional programming and so the gap is [7:46] closing in that in that sense. Um, [7:49] Python is um I think the main advantage [7:53] of Scala over Python is that it is it [7:56] has a strong type system that is always [7:59] on and that gives you essentially [8:01] guarantees uh that essentially certain [8:04] bad states can't can't can't happen. So [8:06] so really can rely on it whereas I think [8:09] I believe the Python type system well [8:11] it's just syntax. it has a number of [8:13] type checkers, but in general there's [8:16] there's le you you have fewer guarantees [8:19] and I believe it's also the ecosystem [8:21] and culture that doesn't value types as [8:23] much in Python. So I think that's [8:25] probably the main difference. F [8:27] syntactically the two languages I think [8:29] with Scala 3 are actually also quite [8:31] close. So Scala 3 looks a lot like [8:33] Python. Um in that sense uh you could [8:37] say well can see it as a [8:41] is a language that has uh strong types [8:44] and uh runs on on different runtimes [8:47] than Python or I should say the other [8:49] thing with Python which is really great [8:50] is that Python is a fantastic glue [8:52] language because I can essentially have [8:55] very very efficient linkages to to high [8:57] performance C++ libraries uh uh pandas [9:02] or numpy or things like