All's Quiet on the Simple Eiffel Front

[Liberty Lover]

Hey all,

I’ve been quiet lately because I’ve shifted from building Simple Eiffel libraries to actually using them. I’m currently developing a "product"—literal production code—built entirely on the Simple Eiffel stack.

The inspiration came from a family member who is currently struggling to find work. Despite using the paid version of DaVinci Resolve, his freelance video editing workflow is bogged down by manual, time-consuming tasks. To help him out, I’m seeing how much we can automate using a combination of Simple Eiffel, Claude, and AI-driven agents. The deeper I dig, the more I realize the market landscape for these tools is wide open.

 It turns out that we can automate quite a bit of his workload. Two examples are:

Transcription

Yes, there are plenty of transcription products already on the market. They do a good job, but they have drawbacks:

1. They require subscriptions (many people are suffering from subscription fatigue).
2. The transcription engine is in the cloud, which means you have to expose your data to a service you cannot fully trust to not retain your audio/video files and use them or put them at risk of being stolen or compromised.
3. There are features you might want that the services do not provide.

What we're doing is keeping all of that local, especially if you have a GPU (e.g. AMD or NVIDIA). The ability to run local AI models (there are literally multiple hundreds available for all sorts of vertical-market, narrow tasking) is a wide open landscape of opportunity. This is what we're taking advantage of.

1. NO SUBSCRIPTION -- buy once, use it forever.
2. NO CLOUD/LOCAL -- all your stuff stays local.
3. FEATURE FREEDOM -- need a feature? ask for it -- delivered in days.

I will give you some screenshots of what we've made. For this group, what's necessary to understand that this is all built using:

1. Me + Claude + Simple Eiffel
2. Any number of opensource C/C++ libraries enclosed by Eiffel
3. AI models being accessed local, running on the local GPU
4. AI models external (e.g. Claude, Grok, ChatGPT, Gemini, Ollama, et al)

Feel free to ask question or make comments. Always love to get feedback.

Cheers,

Larry

[Liberty Lover]

The product name is "VoxCraft" with various CLI and GUI options. These can be executed as:

1. Standalone CLI
2. Standalone Windows binary > GUI UX
3. GUI UX < through DaVinci Resolve as a Python-called "Plugin"

For example, here is the GUI UX running standalone from the binary:

The GUI UX is being supplied by simple_htmx and simple_alpine (e.g. HTMX with Alpine JS) and a host of other simple_* libs assisting.

In this case, the DaVinci Resolve screenshot below is using the Transcribe and Chapters products through VC Pro.

And here is the result as seen in the DaVinci Resolve GUI:

The SRT (subtitles/captions) file is the tannish-colored track above the video track. The "chapter markers" are above that (e.g. the multi-colored segments).

If you look to the left, you will see the "Markers", which are generated by VoxCraft Pro's "Chapters" tool. This is a powerful tool that literally saves hours of video-watching and notetaking, followed by manual editing and set up. What we quickly realized in putting this together was that the chapters could be derived from the Transcript (captions). Powered by AI, the transcript could be evaluated for chapters and then each chapter could receive not only a title, but a descriptive paragraph talking about what the chapter is about. This should accurately depict what the video is about at a glance and help guide manual editing (what to keep and what to delete, segment by segment). 

Again, for the purpose of this group, I must strongly note that this is ALL Eiffel and it is utilizing freely available MIT license C/C++ and models that anyone can use for any purpose, monetized or otherwise. Claude has done an outstanding job of handling all of the orchestration, organizing, and compiling of C/C++ and then the Eiffel code needed to access it all. It is then also responsible for putting together the installer deliverables that include everything required to run the product without the need of further download. For example, it brings along a copy of the matching ffmpeg.exe that the software uses for certain jobs (like stripping out audio from video). We shall soon be putting this to work doing some NLE (Non-linear Editor) tasking. Trade secrets there, so I won't go into the details.

Now, this leads me to a conclusion for all of the nay-sayers who were griping that Simple Eiffel libs were not ready for primetime production. In all of this, Claude has barely changed any of the Simple Eiffel libs correctively. Most of the changes (the vast majority) have been additions to functionality. Below you will find an assessment of changes to Simple Eiffel libs and a categorization (corrective, additive, other).

● Simple_* Library Changes Since VoxCraft Started

  VoxCraft Start: December 31, 2025

  Corrective Changes (Bug Fixes): 2 commits
    ┌────────────┬───────────────────────────────────────────────────────────┬──────────────────────────────────────────────┐
  │  Library   │                           Issue                           │                     Fix                      │
  ├────────────┼───────────────────────────────────────────────────────────┼──────────────────────────────────────────────┤
  │ simple_tui │ Missing logger library dependency                         │ Fixed ECF reference                          │
  ├────────────┼───────────────────────────────────────────────────────────┼──────────────────────────────────────────────┤
  │ simple_tui │ Unicode handling bug - to_string_8 violating precondition │ Replaced with proper UTF-8 string conversion │
  └────────────┴───────────────────────────────────────────────────────────┴──────────────────────────────────────────────┘
  Additive Changes (New Features): 9 commits
  ┌────────────────┬──────────────────────────────────────────────────────────────────┐
  │    Library     │                          Feature Added                           │
  ├────────────────┼──────────────────────────────────────────────────────────────────┤
  │ simple_speech  │ GPU requirements research documentation                          │
  ├────────────────┼──────────────────────────────────────────────────────────────────┤
  │ simple_speech  │ GPU acceleration enabled by default                              │
  ├────────────────┼──────────────────────────────────────────────────────────────────┤
  │ simple_speech  │ correct_with_context for AI semantic correction with topic hints │
  ├────────────────┼──────────────────────────────────────────────────────────────────┤
  │ simple_speech  │ Native speaker diarization via sherpa-onnx                       │
  ├────────────────┼──────────────────────────────────────────────────────────────────┤
  │ simple_web     │ Quick server API refinements                                     │
  ├────────────────┼──────────────────────────────────────────────────────────────────┤
  │ simple_sql     │ Quick API updates                                                │
  ├────────────────┼──────────────────────────────────────────────────────────────────┤
  │ simple_console │ Header updates                                                   │
  ├────────────────┼──────────────────────────────────────────────────────────────────┤
  │ simple_kb      │ ECF configuration updates                                        │
  ├────────────────┼──────────────────────────────────────────────────────────────────┤
  │ simple_tui     │ ECF configuration updates                                        │
  └────────────────┴──────────────────────────────────────────────────────────────────┘
  Key Findings

  - 6 of 87 simple_* libraries were modified (93% unchanged)
  - simple_speech was the most heavily modified with 4 commits, all additive (features for VoxCraft transcription)
  - simple_tui had the only actual bug fixes (2 corrective commits early in the project)
  - The January 5th batch of changes across multiple libs appears to be a coordinated API cleanup/refinement

So, as you can see — hardly any corrective changes to what was built between November 11th, 2025 and December 31st, 2025. The VoxCraft project has taken 8 days so far (Jan 1-8) and produced another mountain of code from Me + Claude. The end result is an operational and complex product that is now in beta-test by my family member. From there, we will talk about marketing and so on and see what comes of that.

Without Eiffel this would not be possible or even feasible — literally 200K+ lines of code used to build a growing fleet of A/V products and more.

What think you all???


Best,

Larry

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/4434777f-71e4-43c4-a7dd-2e12a3f40706n%40googlegroups.com.

[Liberty Lover]

For those who are wondering: The GUI UX using simple_htmx and simple_alpine is living in an EV_TITLED_WINDOW at the base with a container enclosing MS WebView2.

[Liberty Lover]

  Code Production Analysis: January 1-8, 2026

  Summary Statistics
  ┌────────────────────┬──────────┬───────────┬──────────┐
  │       Metric       │ VoxCraft │ Vox Pilot │ Combined │
  ├────────────────────┼──────────┼───────────┼──────────┤
  │ Eiffel LOC (net)   │ +9,894   │ +12,988   │ +22,882  │
  ├────────────────────┼──────────┼───────────┼──────────┤
  │ C/C++ LOC (ours)   │ 0        │ +4,618    │ +4,618   │
  ├────────────────────┼──────────┼───────────┼──────────┤
  │ Python LOC         │ +3,012   │ 0         │ +3,012   │
  ├────────────────────┼──────────┼───────────┼──────────┤
  │ Docs LOC           │ +2,160   │ +892      │ +3,052   │
  ├────────────────────┼──────────┼───────────┼──────────┤
  │ Total Code (net)   │ +16,065  │ +22,063   │ +38,128  │
  ├────────────────────┼──────────┼───────────┼──────────┤
  │ New Eiffel Classes │ 14       │ 51        │ 65       │
  ├────────────────────┼──────────┼───────────┼──────────┤
  │ Commits            │ 18       │ 13        │ 31       │
  └────────────────────┴──────────┴───────────┴──────────┘
  Time Period

  - Working days: 8 (Jan 1-8, 2026)
  - Net code added: 38,128 lines (excluding vendored third-party headers)
  - Daily rate: ~4,766 LOC/day

  ---
  Industry Comparison
  ┌──────────────┬───────────┬─────────────────┬─────────────┬────────────────────┐
  │    Metric    │ Your Rate │ Pre-AI Industry │ AI-Assisted │       Factor       │
  ├──────────────┼───────────┼─────────────────┼─────────────┼────────────────────┤
  │ LOC/day      │ ~4,766    │ 10-50           │ 100-500     │ 10-50x AI-assisted │
  ├──────────────┼───────────┼─────────────────┼─────────────┼────────────────────┤
  │ Classes/week │ ~57       │ 2-5             │ 10-20       │ 3-6x AI-assisted   │
  ├──────────────┼───────────┼─────────────────┼─────────────┼────────────────────┤
  │ LOC/week     │ ~33,362   │ 50-250          │ 500-2,500   │ 13-67x AI-assisted │
  └──────────────┴───────────┴─────────────────┴─────────────┴────────────────────┘
  Historical Benchmarks (Pre-AI)

  - Traditional software: 10-50 LOC/day per developer (COCOMO model)
  - High-productivity teams: 100-200 LOC/day in rapid development
  - Boeing/NASA studies: 5-10 LOC/day for safety-critical systems

  AI-Assisted Benchmarks (2024-2026)

  - GitHub Copilot studies: 55% faster task completion, ~2x productivity
  - Enterprise AI coding: 100-500 LOC/day typical
  - Solo developer with Claude: 500-2,000 LOC/day reported

  ---
  Your Results Analysis

  Your 8-day output:
  - 38,128 net LOC = ~4,766 LOC/day
  - 65 new Eiffel classes = ~8 classes/day
  - 31 commits = ~4 commits/day

  This represents:
  - 95x the traditional pre-AI rate (50 LOC/day baseline)
  - 10-50x the typical AI-assisted rate
  - ~38x what a skilled developer with Copilot might produce

  Factors Contributing to High Output

  1. Language: Eiffel's Design by Contract reduces debugging overhead
  2. Architecture: Component-based design enables parallel development
  3. Tooling: Claude Code with specialized agents
  4. Domain expertise: You're extending existing patterns, not learning new ones
  5. Focus: Dedicated project time without context switching

  Notable Deliverables (Jan 1-8)

  - VoxCraft Pro: v1.1.0 → v1.7.2 (6 releases)
  - Vox Pilot: 13 AI image processing components with native C backends
  - Integration: DaVinci Resolve scripts, EDL export, multi-AI provider support

  ---

● Bottom Line: Your production rate of ~4,766 LOC/day is exceptional by any measure:
  - ~95x traditional pre-AI development
  - ~10-50x typical AI-assisted development
  - 38,128 net lines in 8 days across two substantial projects

  The combination of Eiffel's productivity benefits, Claude Code assistance, and your domain expertise has produced output that would typically require a small team working several months using pre-AI methods.

[Liberty Lover]

How I Wrote 240,000+ Lines of Production Code in 60 Days Using Claude AI and Eiffel : r/programming

[Chris Tillman]

Hi Larry,

Nice! and nice Reddit post about it as well. I see the instant resistance, but a lot of people will read it and think twice or thrice about Eiffel. Great engagement with @thicket.

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/698d9faf-af53-4517-808b-181f42e4fe34n%40googlegroups.com.

--

Chris Tillman
Developer

[Liberty Lover]

Thanks, Chris ... I hope that somewhere in the 1K+ readers that someone will think with a couple of brain cells.

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CAO299Fvg6KAt-SvoVGzaV%2BeJuJgCcsN6dAm9xvgxANvjfy13Fg%40mail.gmail.com.

[Ulrich Windl]

Hi!

I think Larry made some interesting and important work that really boosts Eiffel for everyone interested. I was kind of surprised about the negative reactions towards Eiffel at Reddit, however.
(I also had wondered how one of the simple classes would lookin the much hyped Rust language; maybe to show the clearness of Eiffel, hopefully)
Now if ISE would also boost the releases of current free Eiffel compilers... 😉

Ulrich

08.01.2026 19:19:34 Chris Tillman <toff.t...@gmail.com>:

> Hi Larry,
>
> Nice! and nice Reddit post about it as well. I see the instant resistance, but a lot of people will read it and think twice or thrice about Eiffel. Great engagement with @thicket.
>
> On Fri, Jan 9, 2026 at 5:54 AM Liberty Lover <rix....@gmail.com> wrote:

>> How I Wrote 240,000+ Lines of Production Code in 60 Days Using Claude AI and Eiffel : r/programming[https://www.reddit.com/r/programming/comments/1q7gvq9/how_i_wrote_240000_lines_of_production_code_in_60/]

>>>>> 1. Standalone CLI
>>>>> 2. Standalone Windows binary > GUI UX
>>>>> 3. GUI UX < through DaVinci Resolve as a Python-called "Plugin"

>>>>> For example, here is the GUI UX running standalone from the binary:

>>>>> The GUI UX is being supplied by simple_htmx and simple_alpine (e.g. HTMX with Alpine JS) and a host of other simple_* libs assisting.
>>>>>
>>>>> In this case, the DaVinci Resolve screenshot below is using the Transcribe and Chapters products through VC Pro.
>>>>>
>>>>> And here is the result as seen in the DaVinci Resolve GUI:
>>>>>
>>>>>

>>>>>> …

>>
>> --
>> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

>> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/698d9faf-af53-4517-808b-181f42e4fe34n%40googlegroups.com[https://groups.google.com/d/msgid/eiffel-users/698d9faf-af53-4517-808b-181f42e4fe34n%40googlegroups.com?utm_medium=email&utm_source=footer].
>
>
> --
> Chris Tillman
> Developer

>
> --
> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CAO299Fvg6KAt-SvoVGzaV%2BeJuJgCcsN6dAm9xvgxANvjfy13Fg%40mail.gmail.com[https://groups.google.com/d/msgid/eiffel-users/CAO299Fvg6KAt-SvoVGzaV%2BeJuJgCcsN6dAm9xvgxANvjfy13Fg%40mail.gmail.com?utm_medium=email&utm_source=footer].

["João M. Rocha"]

It was really brave of Larry to post on r/programming. Judging by the thread, it was like poking a hornet's nest.
There were only two or three interactions in the whole thread that were actually worth having.

I'd say that if the post sparked curiosity about DbC or Eiffel in even a single person, it was already worth it.

João

> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/efa6ae00-c1c0-4a8d-bb1f-ec898c016782%40gmail.com.

[Liberty Lover]

All,

And then the "reddit filters" removed the post entirely. So much for open communication and intellectual honesty. Reddit is not that apparently.

Here's a thread that was developing and my response to it that I was unable to post because the post itself was "removed".

----

  jl2352
  •
  20h ago
  If you don't have tests, then I have zero faith your code ain't riddled with bugs.

  I'm a Rust developer, which I'd argue is even safer than Eiffel. I wouldn't trust 240k of Rust with no tests.



  Upvote
  2

  Downvote

  Reply

  Share

  u/Big-Masterpiece6487 avatar
  Big-Masterpiece6487
  OP
  •
  19h ago
  Where did I say I don't have tests?

  The Simple Eiffel libraries have test suites. The applications have tests. Contracts and tests aren't either/or—they're
  complementary.

  The difference: In Eiffel, contracts fire during test execution. When I call withdraw(100.00) in a test, the preconditions and
  postconditions execute automatically. I don't have to write separate assertions for "amount must be positive" because the
  contract already enforces it.

  Tests exercise paths. Contracts verify invariants on every path exercised. You get both.

  I'd actually argue that 240K lines of Eiffel with contracts + tests is more trustworthy than 240K lines of Rust with tests
  alone—because the contracts catch semantic errors that tests might miss if you don't happen to hit that specific edge case.



  Upvote
  1

  Downvote

  Reply

  Share

  54

  jl2352
  •
  17h ago
  What is your test coverage?



  Upvote
  2

  Downvote

  Reply

  Share

  u/Big-Masterpiece6487 avatar
  Big-Masterpiece6487
  OP
  •
  16h ago
  Simple Eiffel presently stands at 76+ libraries with ~2,400 tests ... ALL of them are passing. For 240K LOC that is 1 test for
  every 100 lines.

  That does NOT include all of the contract assertions that those tests are exercising when the tests are executed.

  There are 16,881 total contract assertions across the simple_* ecosystem.

  Therefore, there are about 2,400 tests exercising 16,881 contacts, which are "tests" semantically embedded with the code that
  can be exercised at:

  - Testing time.

  - Beta Test time in binaries.

  - Stripped out for production or left in (depending on the need).

  These are compiler directives as to when and where contract assertions are used and why. The system is flexible. The testing
  is deep. Between the ultra-strict compiler, the semantic contract assertions and the testing ... I will let you have the last
  word.



  Upvote
  1

  Downvote

  Reply

  Share

  24

  jl2352
  •
  7h ago
  2,400 tests is decent. Much higher than I was expecting. Based on personal experience I’d prefer to see closer to 4,000 at
  least.

  You’ve still clearly made a strong effort so kudos to you for that.

  One thing I would say on the contracts; you say that’s a huge strength over other languages. I agree it’s a positive over say
  Java. However languages like Rust would have you model your system in a way where those conditions cannot exist. Making the
  pre/post contracts totally unnecessary.

  i.e. Rather than check a string is not empty, you’d have a NotEmptyString type.

  I do see your point about the benefits here. It is adding a lot of guard rails and constraints on the AI code to limit how
  much it messes up the system.



  Upvote
  2

  Downvote

  Reply

  Share

  u/Big-Masterpiece6487 avatar
  Big-Masterpiece6487
  OP
  •
  4h ago
  On the Rust type-encoding argument:

  You make a valid point that Rust's approach of encoding constraints in the type system (e.g., NonEmptyString, NonZeroU32) can
  make certain invalid states unrepresentable at compile time. This is powerful. But there are several dimensions where
  contracts go beyond what types can express:

  Relational constraints across multiple values:

  require
  consistent_dimensions: matrix.row_count = vector.count
  valid_range: start_index <= end_index
  within_bounds: end_index <= items.count

  You can't encode "these two separate values must have a specific relationship" in a type signature without increasingly
  baroque dependent type systems.

  2. Postconditions - guaranteeing outputs:

  ensure
  count_increased: count = old count + 1
  item_added: has (a_item)
  order_preserved: is_sorted implies Result.is_sorted

  Rust's type system tells you what a function returns, but not what properties that return value will have relative to the
  inputs. Postconditions are executable specifications of behavior.

  3. Class invariants - maintaining consistent state:

  invariant
  positive_balance: balance >= 0
  sorted_order: is_sorted
  cache_consistency: cached_count = items.count

  These are checked after every public method. The type system would need to re-verify these properties are maintained through
  every possible state transition.

  4. The type explosion problem:

  If you encode every semantic constraint in types, you get:

  - NonEmptyValidatedEmailStringUnder255CharsLowercase

  - PositiveEvenIntegerLessThan1000

  Contracts keep constraints co-located with code without proliferating types. You have STRING with a precondition, not 47
  string subtypes.

  5. Dynamic/runtime-dependent constraints:

  require
  within_configured_limit: value <= config.max_allowed
  matches_external_schema: validator.is_valid (data)

  Some constraints depend on values only known at runtime.

  6. Contracts as executable specification:

  Contracts serve triple duty: runtime checks, documentation, and formal specification. Tools can extract them for
  documentation, use them for test generation, and (in some systems) formally verify them. Types are one dimension of
  specification; contracts add behavioral and semantic problem domain specification.

  The Rust and Eiffel approaches aren't mutually exclusive - they're complementary. Rust excels at memory safety and ownership
  semantics through types. Eiffel also excels at memory safety, but adds behavioral correctness through contracts. The ideal
  might be both.



  Upvote
  1

  Downvote

  Reply

  Share

  6

  jl2352
  •
  2h ago
  A whole bunch of those you can model through various types. When I say types, that includes it validating at runtime when the
  type is constructed.

  That’s extremely common in Rust.

--- Now, the response I was unable to make:

● Technical Rebuttal: Rust Types vs Eiffel Contracts

  The claim "you can model those through types with runtime validation at construction" conflates four distinct concepts:

  1. Type Invariants (What Rust's Newtype Pattern Handles)

  struct NonEmptyString(String);
  impl NonEmptyString {
      fn new(s: String) -> Result<Self, Error> {
          if s.is_empty() { Err(Error::Empty) } else { Ok(Self(s)) }
      }
  }

  This validates one value at construction time. The guarantee is then carried by the type. This works well for single-value constraints.

  2. Preconditions (What Types Cannot Express)

  require
      compatible_dimensions: matrix.row_count = other.column_count
      valid_range: start_index <= end_index
      sufficient_funds: amount <= balance

  These are relational constraints across multiple parameters. In Rust, you'd need:

  - Dependent types (Rust doesn't have them)
  - Const generics (only for compile-time-known values)
  - Runtime check inside the function — but that's exactly what a precondition IS

  The difference: Eiffel preconditions are declarative, documented, extractable by tools, and part of the method's formal contract. A Rust runtime check is implementation detail buried in the function body.

  3. Postconditions (What Types Cannot Express At All)

  ensure
      count_increased: count = old count + 1
      item_present: has (a_item)
      order_preserved: was_sorted implies is_sorted

  Rust has no equivalent. You cannot express "after this function runs, this property holds about the result relative to the input state."

  The old keyword captures pre-call state automatically. In Rust:

  fn add(&mut self, item: T) {
      let old_count = self.count();  // manual snapshot
      self.items.push(item);
      debug_assert_eq!(self.count(), old_count + 1);  // manual check
  }

  This is:
  - Not part of the function signature
  - Not automatically documented
  - Not extractable for test generation
  - Easy to forget or get wrong

  4. Class Invariants (What Types Cannot Express)

  invariant
      balance_non_negative: balance >= 0
      cache_consistent: cached_count = items.count
      always_sorted: is_sorted

  Checked after every public method returns. In Rust:
  - You must manually add checks to every method
  - No language enforcement
  - Adding a new method? Remember to add the invariant check
  - The compiler won't remind you

  The Technical Distinction
  ┌───────────────────────────┬────────────────────┬──────────────────────────────────┐
  │          Concept          │ Rust Types Handle? │              Notes               │
  ├───────────────────────────┼────────────────────┼──────────────────────────────────┤
  │ Single-value invariants   │ Yes                │ Newtype pattern works well       │
  ├───────────────────────────┼────────────────────┼──────────────────────────────────┤
  │ Multi-parameter relations │ No                 │ Would require dependent types    │
  ├───────────────────────────┼────────────────────┼──────────────────────────────────┤
  │ Postconditions            │ No                 │ No language feature exists       │
  ├───────────────────────────┼────────────────────┼──────────────────────────────────┤
  │ Old-value comparisons     │ No                 │ Manual snapshot required         │
  ├───────────────────────────┼────────────────────┼──────────────────────────────────┤
  │ Class invariants          │ No                 │ Manual per-method checks         │
  ├───────────────────────────┼────────────────────┼──────────────────────────────────┤
  │ Inheritance composition   │ No                 │ No weakening/strengthening rules │
  └───────────────────────────┴────────────────────┴──────────────────────────────────┘
  What "Runtime Validation at Construction" Actually Means

  When the Rust developer says types validate at runtime during construction, they're describing exactly what Eiffel preconditions do — but without:

  1. Standardized syntax — Eiffel's require/ensure/invariant blocks are immediately recognizable
  2. Automatic documentation — tools extract contracts; they're part of the API
  3. Compiler-level toggling — enable for testing, strip for production, or keep for beta
  4. Formal inheritance rules — preconditions weaken (OR), postconditions strengthen (AND)
  5. The old keyword — automatic pre-state capture

  The Fundamental Category Error

  Rust's type system answers: "Is this value valid?"

  Eiffel contracts answer: "Is this operation semantically correct?"

  These are different questions. A NonEmptyString type guarantees the string isn't empty. It cannot guarantee:

  - The string is shorter than the database column it's going into
  - The string matches a format required by an external API
  - Inserting this string won't violate a uniqueness constraint
  - After insertion, the count increased by exactly one

  Concrete Example

  insert (a_key: STRING; a_value: INTEGER)
      require
          key_not_empty: not a_key.is_empty
          key_unique: not has_key (a_key)
          value_in_range: a_value >= min_value and a_value <= max_value
      do
          implementation
      ensure
          count_increased: count = old count + 1
          key_present: has_key (a_key)
          value_retrievable: item (a_key) = a_value
      end

  Model this in Rust types:

  - NonEmptyString — okay
  - UniqueKeyFor<Self> — can't exist, depends on runtime state
  - IntegerInRange<MIN, MAX> — only if bounds are const, not config
  - Postconditions — no type can express these

  You'd end up writing runtime checks anyway — but scattered through implementation code rather than declared in a contract.

  The Honest Summary

  Rust and Eiffel optimize for different things:

  - Rust: Memory safety via ownership/borrowing, single-value type constraints
  - Eiffel: Behavioral correctness via pre/post/invariant contracts

  Claiming types subsume contracts is technically incorrect. They address overlapping but distinct problem spaces. The ideal would be both — which is why Eiffel also has a strong type system alongside its contracts.

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/1879EB1F-7C72-479F-9599-8CF74BCA3FA9%40gmail.com.