Hacker News Reader

Comment by umvi | Hacker News Reader

Maybe I'm a zealot, but I don't really consider "doesn't work as well on windows" a con of a language.

C# is (or at least used to be) utter garbage on Linux compared to Windows. I don't hold that against C#, but rather recognize that Linux/Windows are very different, and that compiler maintenance and development is non-trivial (and obviously Microsoft is going to prioritize Windows).

This article is basically a rant that Go was designed with *nix in mind and that Windows is a second-class citizen by comparison.

View on HN

I believe you missed half the article, as well as the main point: that trying to hide implementation details too much from the API consumers is not generally a good thing, and that's regardless of the system it's running on.

The OS is just one of many context-dependent axis on an application. Bad decisions done on that level are likely to occur on other parameters that are more important to you.

I'm not sure you can call it "miss" if the article tries to hide its thesis as well as this one. After you keep going about file API and windows for pages and pages, you may insist all you like that "the point is coming", but I'm sorry, I won't believe you.

C# support in linux and osx are actually quite good these days especially in .NETCore. You run into some cross platform issues if you want to go as deep as shell handling when trying to manipulate processes, though.

There's some stuff in there about it not handling valid edge cases on Linux particularly well, either, though.

But you knew C# was Windows only. Go was always touted as a cross platform solution due to statically compiled binaries. If said binaries have issues on Windows due to design decisions it seems like a language fault.

The binaries themselves don't have issues. But Go's descision to make the standard library Unix focused isn't a flawed design decision.

If you need OS/platform-specific precision, you're free to create or use an alternative library. The standard lib was never designed to be the magic bullet for cross-platform, but the language internals, compilation, and execution do a good job for many platforms.

We need to keep in focus what the goals of each part of the language are intended for.

I don't think Go was ever really touted as cross-platform, beyond not having to deal with dynamic linking hell. After all, I can't take a random binary built by the Go toolchain for Linux and run it on FreeBSD, MacOS, or Solaris. The only portability gain you get from static linking and the only one Go was ever aiming for was across versions and distributions of the OS.

What is it then if not a con?

I mean, C# not running well on unix systems was immediate show stopper for a lot of projects but we can't call this a "con"?

It's only a con in the context of your use case and requirements. It's not a con for everybody, so in the general case I would instead call it a limitation.

Every piece of software in the world has limitations. The limitations are only cons in the context of your requirements. Is it a con of SQLite that it is missing features when using it with the JFFS2 filesystem? Maybe, depends on your use case. If your system doesn't use JFFS2, then it's not a con worth considering.

That's just word play.

I absolutely agree. The one time I had the great misfortune of building software for windows I was extremely happy to see Go worked at all.

Linux and OS X largely work the same way due to their shared Unix-ness and pretty much everyone I’ve ever met or talked with uses Go on one of those two platforms.

If you have to develop software primarily for Windows, maybe don’t use Go - it’s easily the least actively maintained OS target and there are many options for languages that are well supported on Windows by vendors who actually care. Kind of the same folly as trying to write an iOS app not in Swift or ObjC and then complaining it doesn’t work well.

No one expects iOS to run on Windows. But given that there's a Windows version of Go, it's reasonable that it should work.

And also, the points about metadata and path management are spot on. It's 2020. Languages should not be assuming that paths are byte strings.

Unix-think is a bug, not a feature. A good language should abstract the file system, not just put a teeny tiny wrapper of modesty around it.

Stuff exists on those file systems outside of your application, and at some point you'll have to interface with them.

For high-level languages you're writing user-facing apps in domains where your file handing needs are simple, I can see the appeal.

But of course you're ignoring the entire category of systems programming, cross platform apps that need something more than easy access to a file picker, integration code that frequently needs to deal with exactly the edge cases that these pretty abstractions ignore, etc. etc.

VB6 had its place. So does C.

> Languages should not be assuming that paths are byte strings.

They are in the real world and you have to live with that.

Screaming at people might sometimes have good results.

Screaming at reality never does.

> Languages should not be assuming that paths are byte strings.

Lots of people who know what they're talking about disagree:

https://yarchive.net/comp/linux/utf8.html

Given than Mono-the first open source C# implementation-was used to build banshee going back 15+ years, C# on *nix deserves more credit than is given here.

absolutely, not sure why this dude is dumping on it? Has he even used it in the last 5 years?

Maybe I'm also a zealot, but this "second-class citizen by comparison" works pretty well - I've been using Go for some side projects under Windows for years, and was actually surprised how well it worked. I even developed a GUI app some years ago (using GTK). So, if you ask me, the glass is ~90% full, not 10% empty...

Not sure what you mean about C# on Linux. More than a decade ago it worked just fine on Linux using Mono. For a few years now it's worked just as well on Linux as it has on Windows, using dotnet Core.

Source: I've been developing using C# on both Windows and Linux for a very long time.

The gripe was not that it doesn't work well on Windows. It was about a culture of not caring about getting details right or valuing correctness. Windows was just used as an example of not caring about correctness. The time API was another.

Then don't support it at all instead of trying to support it and failing half way

Reply on news.ycombinator.com