6 ms·

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 co

by umvi 7y ago

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.

karatestomp 7y ago
There's some stuff in there about it not handling valid edge cases on Linux particularly well, either, though.
The_Colonel 7y ago
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"?
- umvi 7y ago
  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.
  - The_Colonel 7y ago
    That's just word play.
fortytw2 7y ago
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.
- TheOtherHobbes 7y ago
  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.
  - bartwe 7y ago
    Stuff exists on those file systems outside of your application, and at some point you'll have to interface with them.
  - _jal 7y ago
    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.
  - msla 7y ago
    > 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.
  - msla 7y ago
    > 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 https://yarchive.net/comp/linux/utf8.html
whatever_dude 7y ago
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.
- paul_milovanov 7y ago
  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.
jjuel 7y ago
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.
- eudoxus 7y ago
  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.
- talideon 7y ago
  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.
eithed 7y ago
Then don't support it at all instead of trying to support it and failing half way
jayd16 7y ago
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.
rob74 7y ago
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...
zgramana 7y ago
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.
- stjohnswarts 7y ago
  absolutely, not sure why this dude is dumping on it? Has he even used it in the last 5 years?
GordonS 7y ago
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.
nickm12 7y ago
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.

by umvi 7y ago

karatestomp 7y ago

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

The_Colonel 7y ago

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

umvi 7y ago
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.
- The_Colonel 7y ago
  That's just word play.

fortytw2 7y ago

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.

TheOtherHobbes 7y ago
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.
- bartwe 7y ago
  Stuff exists on those file systems outside of your application, and at some point you'll have to interface with them.
- _jal 7y ago
  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.
- msla 7y ago
  > 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.
- msla 7y ago
  > 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 https://yarchive.net/comp/linux/utf8.html

whatever_dude 7y ago

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.

paul_milovanov 7y ago
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.

jjuel 7y ago

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.

eudoxus 7y ago
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.
talideon 7y ago
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.

eithed 7y ago

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

jayd16 7y ago

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.

rob74 7y ago

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

zgramana 7y ago

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.

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

GordonS 7y ago

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.

nickm12 7y ago

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.