G#: A modern .NET language with Go, Kotlin, and Swift ergonomics

https://davidobando.github.io/gsharp/

by mashally • 11 days ago

50 30 11 days ago

davidobando.github.io

chabad360• 11 days ago

While the language itself doesn't seem very interesting (which is perhaps the point). The idea of building a new language on top of the CLR runtime feels very wise. Instead of a new language suffering from a lack of ecosystem, you get everything else that's already built, even in other (CLR-based) languages. This does leave me wondering what the trade off is. Do you sacrifice any potential language features for CLR compatibility? Or provided you can get it compile, it will run?

Also, are there other language ecosystems with a similar capability?

jluysvi• 11 days ago

The JVM has a ton of languages built on it.

applfanboysbgon2• 10 days ago

I mean, one trade-off is obvious: you get the drawbacks of the runtime too. Any .NET program is opting you into tens of MBs of binary/lib size and RAM usage for what a C program could do in <1mb. This completely rules out using in the language in certain domains eg. embedded.

paddim8• 10 days ago

.NET programs can be AOT compiled

tcfhgj2• 10 days ago

This does leave me wondering what the trade off is.

Microsoft

pjmlp2• 10 days ago

That was the original goal of CLR, hence Common Language Runtime, even though nowadays it feels more like it means C# Language Runtime.

https://news.microsoft.com/source/2001/10/22/massive-industr...

grandpoobah• 11 days ago

Not really anything here which distinguishes it from c#?

cromka2• 11 days ago

I have a strong feeling that no new languages will get adopted at all, now that it's important for AI to be proficient in speaking them.

cultofmetatron• 11 days ago

I've been suspecting this myself and its probably the biggest thing I dislike about ai having taken over the proffession.

vikramkr2• 11 days ago

The best AI models at this point are perfectly fine handling new languages and frameworks and stuff - as long as you can point the llm to some docs and some example code it's not gonna do noticeably worse than it would at another language.

cromka2• 11 days ago

Sure, but you expect of AI the ability to use the vast knowledge on languages and platforms that already exist out there. Just because they can be toughy to understand a new language won't make them proficient in it, able to save problems, etc.

pjmlp2• 11 days ago

If anything, research for AI based tooling for direct code generation is only increasing.

tcfhgj2• 11 days ago

If I could accept a resource intensive plattform, I'd rather choose Java - .NET strongly feels like a Microsoft trap

orphea2• 11 days ago

And you would miss out - .NET is a rare case of Microsoft actually made something quite good.

jiggawatts• 11 days ago

A language controlled primarily by Oracle is certainly... a choice, if you prefer avoiding traps controlled by megalomaniac overlords.

potato-peeler• 11 days ago

One of the things go makes it simple to do is help a reader understand which constructs belong to which package, since any use of external imports is prefixed by the package name.

In go, if I don’t know a constructs definition, i know exactly where to look at and find it.

When exploring a new language I won’t always setup an ide first. I just want to look at the documentation on my own. Heck, any language which requires ide or any mandatory tooling to work with it, is already handicapping a developer.

G# seems to copy go syntax but didn’t copy the things that go makes it easier to understand any go code.

torginus• 11 days ago

Agree, and this is a huge bungle you can make in language design, that will affect compiler performance down the line significantly.

If you know which package each type comes from, you only need to check the exports of that package, otherwise its a local.

Otherwise you have to start compilation by building up a list of every package and its exports. This is particularly bad for incremental compilation, and starts to drag on large projects.

The saving grace of .NET in this case is that most .NET programs traditionally didn't have that many imports. You have mscorlib for the framework itself, which is almost all the basics, and maybe ASP.NET and a dozen other small packages.

But this doesn't have to be the case, and if you have thousands of small packages (because your app is huge), then your performance tanks.

metaltyphoon2• 22 hours ago

since any use of external imports is prefixed by the package name.

And this is also one of its biggest problem, any package can take a good valid variable name that can’t be used without shadowing a package. If it only didn’t make the stupid, IMO, idea of casing for access modifiers and made struct Pascal then this wouldn’t have been a problem.

arisudesu2• 11 days ago

"Go ... ergomonics" "G# compiles straight to managed assemblies and runs on the modern .NET runtime"

These two are nothing close because it completely misses Go's ergonomics of compilation to portable static-linked binaries. For language constructs, maybe they have similar ergonomics, but the language is not only constructs. You have to ship your programs somehow, and this is where requirement to ship both binaries and the interpreter for them, sucks.

orphea2• 10 days ago

.NET is not an intepreter. Also, it has been able to compile to a single binary for years.

arisudesu2• 10 days ago

But it really is, in a sense that another program is required to interpret IL format, even if it is JIT-compiled after loading. Think of it similar to the ELF interpreter for dynamically-linked binaries.

Speaking of compilation to a self-contained binary, I hope in the future G# will support it. No mentions as of today though.

mellinoe• 7 days ago

You can compile .NET to native statically linked binaries, too.

derdi• 10 days ago

The docs could use some cleanup, by which I mean "throw away all the stupid jargon". How does one publish this homepage with the term "width-bearing" on it? This is not a term of the trade. It's not even "little known" or "niche", it has literally zero Google hits outside this project's documentation. (This post will be the first one.) "Fixed-width type" is right there.

The term "extensions" is also weird. It seems to be used for two things: One, "libraries" (any standard types and functions they wanted to include but don't inherit directly from the CLR's library). Two, a "Go-shaped" (*sigh*) "extension" that is both a "library" (some trivial functions like `len`) and also changes the language by adding channels and some new syntax! Wow, syntax can be imported with an import statement! But only this specific syntax, with this specific import!

And this is "opt-in", and an extension. But... it's right there. It ships with the language. It is in the language. That's not what an extension is to normal humans. And opt-in, sure. I guess I wouldn't have to use it. Just like every other language feature I don't feel like using?

nozzlegear• 10 days ago

One surefire way to spot LLM writing (beyond the usual signals that savvy people are trying to hammer out of their bots) is to look for a predilection for these awkward compound adjective words. "Width-bearing primitives," "implementation-grounded specification," "data-shape ergonomics."

throw1234567891• 10 days ago

"Runs on .NET", hits the back button.

G#: A modern .NET language with Go, Kotlin, and Swift ergonomics

Related Stories