3 ms·
... which is still in a fairly early state, like I said. And NGEN doesn't help the issue of runtime dependence at all. I'm not really a fan of Go, but being ab
by johncolanduoni 10y ago
... which is still in a fairly early state, like I said. And NGEN doesn't help the issue of runtime dependence at all.
I'm not really a fan of Go, but being able to write small tools in it without pulling in a huge runtime is a big drawback.
- pjmlp 10y agoBut that isn't a language feature, rather a toolchain one. Once upon a time, on the PC we only had static compilation, regardless of the language. .NET Core would help with the runtime dependencies (XCopy Deploy), but currently it is also WIP for those of us that care about desktop applications.
- johncolanduoni 10y agoIs the .NET stack and tooling any more a language feature? You were happy to argue that tooling was important a moment ago. In any case, when choosing a language for a project which doesn't fit your requirements because maybe the tooling will get there someday, I think you're going to pretty consistently end up in a sticky situation. I like C# a lot more than Go for most things, and some of the reasons are things you listed, but the goalpost shifting is getting ridiculous.
- pjmlp 10y agoI am just digressing, sorry if you see it as goalpost shifting.