Questions about DirectSharp

Why another .NET language?

DirectSharp puts readable application rules first: case-insensitive names, words for common operations and explicit block endings. Its intended home is business software that people maintain, explain and occasionally inspect, including code generated by agents. Existing .NET libraries supply the application capabilities. The author's story explains why that combination matters to him.

Readability is a design goal, not proof of fewer defects. A review still needs domain knowledge, tests and attention to failure and lifetime boundaries. The Customer showcase gives you concrete code against which to assess the design.

Why not use VB.NET?

VB.NET already offers case-insensitive identifiers, word-based structure and .NET interoperability. It remains a practical choice when it meets a team's needs. DirectSharp draws on that readability while choosing its own contracts for effective defaults, class kinds, explicit asynchronous intent, owned concurrency and consumable sources.

Those choices need evaluation in real code, rather than a claim that familiar syntax makes the languages interchangeable. Start with the C#/VB.NET bridge and equivalent application tasks.

Can I use existing C# libraries and NuGet APIs?

Direct .NET interoperability is central to the design. Use ordinary CLR classes, interfaces, generics, delegates, expression trees, attributes and task-returning APIs. The walkthrough uses FluentValidation, Dapper, ASP.NET Core, Microsoft DI and logging through their normal contracts. A feature adapter is optional.

An import affects name lookup; it does not install a package or create an assembly reference. Framework compatibility, overload resolution, access rules and query-provider restrictions still matter. See .NET integration.

What does a C# backend mean?

A C# backend lowers DirectSharp to readable C# for .NET. The DirectSharp specification defines behavior; superficially similar C# syntax is not always sufficient to preserve it. Effective defaults, String comparison, concurrent outcome policies and authored cleanup are examples that need deliberate lowering.

The C# reference guide explains how those semantics can be preserved using ordinary .NET mechanisms.

Will async code need special .NET libraries?

The design uses normal .NET awaitable contracts and cancellation tokens. Fresh calls require explicit intent: await for a result, task_of to retain an operation, or run inside an owning concurrent scope. Ordinary actions can infer async implementation; explicit async action fixes its asynchronous and standard cancellation contract.

Structured scopes perform their own required waits for joins, enumeration and cleanup. They do not force CPU work onto a background thread. Imported APIs retain their own cancellation, task-consumption and continuation behavior. The developer bridge and bounded report example show those distinctions.

Is DirectSharp faster than C# or VB.NET?

No performance advantage has been established. Runtime costs depend on the generated implementation, libraries, allocations, data and workload. Source brevity and a C# backend are not benchmarks. Comparisons here concentrate on equivalent behavior and failure policies. Performance work will require implementations and representative measurements.

How can I help improve the documentation?

Open the repository's docs directory, find the page and propose an edit through GitHub's normal file-edit/pull-request flow. Include the heading, the confusing input or example, and the behavior you expected. For a contradiction, quote both rules rather than choosing an undocumented behavior.

The contribution guide lists the documentation checks and reference-fixture boundaries. New language design, production compiler/runtime work and licensing policy are outside an ordinary documentation correction. No separate support channel or response-time commitment is implied.