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?
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.
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.
> 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.
"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.
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?
14 comments
[ 3.0 ms ] story [ 52.0 ms ] threadAlso, are there other language ecosystems with a similar capability?
Microsoft
https://news.microsoft.com/source/2001/10/22/massive-industr...
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.
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.
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.
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?