Yeah this one seems weird. I would think it's actually the inverse. I used to code a lot in Go two years ago, so I can't speak to it much today.
Lately, I'm all Rust. If you're on Linux, it's so easy going to get it all working right. Windows is a pain, so much so you end up installing WSL2 and just moving on with your day.
A good follow up to this post would be OpenSSL compilation on Golang vs. Rust on each platform. It's a fair test as it's widely used library with both programming languages and all the operating systems.
I am interested in what pain you had beside OpenSSL; I've been exclusively a Windows user for the past few years, and other than it and Postgres, I've had no desire to install WSL.
Three years ago I began working in a new company and was initially on Windows, and was extremely open minded about it. Though, perhaps because I structured my "workspace" as I would under linux, where I put the code in some directory under my home one, things began to break rather quickly. The most common and annoying error was maven builds breaking because the path of the files being compiled was too long. After a bit of struggling I decided to go back to linux, it just wasn't worth the hassle.
Windows path length limits are infuriating, and also really exciting because what the limits actually are varies depending on what API calls the program is using to access the filesystem. What fun!
I've never experienced this with maven and I've been using it for close to 10 years on windows. This is also putting all of my code under my home directory.
In Java, the file names directly reflect the package and class structure. If you have a class "org.example.long.package.name.SimpleInterfaceBeanFactoryFactory" with an inner class "Inner" that has an inner class "InnerInner" that has an anonymous inner class, the source code for it normally resides at "src/main/java/org/example/long/package/name/SimpleInterfaceBeanFactoryFactory.java", and the bytecode for that anonymous inner class, after being compiled through maven, resides at "target/classes/org/example/long/package/name/SimpleInterfaceBeanFactoryFactory$Inner$InnerInner$1.class". That's already over a hundred characters long, and it's not unusual to have even longer names; a quick look at a project I have around here shows bytecode files with path names approaching 170 characters starting from the maven root. Add to that around 30 characters for a "projects/project-group/project-name" hierarchy, plus 30 more for the path to the user directory, and it's already uncomfortably close to the Windows 260-character limit. It's not hard to imagine that a project with a deeper package hierarchy could hit that limit, and it only takes one file to break the whole build.
Based on my own experience with C/C++ projects are built with the assumption that you are on Linux. You have to do quite a bit of fangling to get it working with Windows, that it isn't worth the time. I don't want to setup mingw or cygwin to get things working for one weird library that's included.
I don't have a requirement to build for Windows, so I will always just avoid it. I think Microsoft is making strides in developer experience, but I think it also sees the signs that Linux/Containerization is the way forward thus why they built WSL. Azure itself is over 50% Linux now too.
Comments
Yeah this one seems weird. I would think it's actually the inverse. I used to code a lot in Go two years ago, so I can't speak to it much today.
Lately, I'm all Rust. If you're on Linux, it's so easy going to get it all working right. Windows is a pain, so much so you end up installing WSL2 and just moving on with your day.
A good follow up to this post would be OpenSSL compilation on Golang vs. Rust on each platform. It's a fair test as it's widely used library with both programming languages and all the operating systems.
I am interested in what pain you had beside OpenSSL; I've been exclusively a Windows user for the past few years, and other than it and Postgres, I've had no desire to install WSL.
Three years ago I began working in a new company and was initially on Windows, and was extremely open minded about it. Though, perhaps because I structured my "workspace" as I would under linux, where I put the code in some directory under my home one, things began to break rather quickly. The most common and annoying error was maven builds breaking because the path of the files being compiled was too long. After a bit of struggling I decided to go back to linux, it just wasn't worth the hassle.
Windows path length limits are infuriating, and also really exciting because what the limits actually are varies depending on what API calls the program is using to access the filesystem. What fun!
I've never experienced this with maven and I've been using it for close to 10 years on windows. This is also putting all of my code under my home directory.
In Java, the file names directly reflect the package and class structure. If you have a class "org.example.long.package.name.SimpleInterfaceBeanFactoryFactory" with an inner class "Inner" that has an inner class "InnerInner" that has an anonymous inner class, the source code for it normally resides at "src/main/java/org/example/long/package/name/SimpleInterfaceBeanFactoryFactory.java", and the bytecode for that anonymous inner class, after being compiled through maven, resides at "target/classes/org/example/long/package/name/SimpleInterfaceBeanFactoryFactory$Inner$InnerInner$1.class". That's already over a hundred characters long, and it's not unusual to have even longer names; a quick look at a project I have around here shows bytecode files with path names approaching 170 characters starting from the maven root. Add to that around 30 characters for a "projects/project-group/project-name" hierarchy, plus 30 more for the path to the user directory, and it's already uncomfortably close to the Windows 260-character limit. It's not hard to imagine that a project with a deeper package hierarchy could hit that limit, and it only takes one file to break the whole build.
That limit just isn't a thing anymore....
https://duckduckgo.com/?t=ffab&q=Enable+Win32+Long+paths&ia=...
Ah, I should have clarified: for Rust development. I can't (well, I guess I mean "won't") fix bugs in Maven :)
Based on my own experience with C/C++ projects are built with the assumption that you are on Linux. You have to do quite a bit of fangling to get it working with Windows, that it isn't worth the time. I don't want to setup mingw or cygwin to get things working for one weird library that's included.
I don't have a requirement to build for Windows, so I will always just avoid it. I think Microsoft is making strides in developer experience, but I think it also sees the signs that Linux/Containerization is the way forward thus why they built WSL. Azure itself is over 50% Linux now too.
Source: https://build5nines.com/linux-is-most-used-os-in-microsoft-a...