ZH version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
57% Positive
Analyzed from 501 words in the discussion.
Trending Topics
#language#net#package#constructs#languages#understand#already#code#compilation#case

Discussion (16 Comments)Read Original on HackerNews
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.
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.
Also, are there other language ecosystems with a similar capability?
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.