Live data from Hacker News

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

davidobando.github.io

21–30 of 34 posts

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

#21
post #16

"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 a…

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

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.

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

#22
post #16

Earlier quoted context omitted.

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

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.

That hasn’t been true for some time.

https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

The reason to dislike .NET is Microsoft’s now weak engineering. Their cloud team has negative impact on the entire org, and Microsoft engineers like Raymond Chen seem to be a rarity.

Even former cash cows like Windows and Office are struggling and infected with Nadella and Azure/Entra/365/who-knows-what-next’s touch.

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

#23
post #14
post #7

Earlier quoted context omitted.

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.

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.

Not really - it doesn't seem to be much of a leap to be able to transfer that knowledge to new language. Honestly there's not a lot that's fundamentally new under the sun in new programming languages and solving a problem in a different language is just another problem for an llm to solve - obviously what's easy and hard for an llm is unrelated to what's easy and hard for a human so human intuition should be taken with a very large grain of salt, but my intuition is that it's not meaningfully different for the llm to figure out a new language vs figure out a weird 3rd party api to integrate with. For both of those cases you do need to give them access to docs and examples, it's not innate to the model, but even for languages it does know from its training data you still need to direct it on what style guide etc you want for your codebase to keep it consistent with your other code patterns.

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

#24
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?

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

#25

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 c…

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.

.NET programs can be AOT compiled

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

#26
post #24

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 t…

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."

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

#27
post #25

Earlier quoted context omitted.

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.

.NET programs can be AOT compiled

I am well aware of that, given that I routinely ship such programs. Compiling ahead of time does not change the fact that the .NET runtime is orders of magnitude larger than a C runtime.

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

#29

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 c…

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...

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

#30
post #3

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 c…

The JVM has a ton of languages built on it.

[flagged]
Post reply on HN