Comment by daniel-levin | Hacker News Reader

Comment by daniel-levin | Hacker News Reader

I've just introduced a new engineer to a project in a language he hasn't used before. All of these points ring true! I want to suggest C# on .NET Core as a pleasant, fast language and ecosystem to learn.

I used to avoid anything Microsoft like the plague. A friend of mine used to call me "the Unix beth din" [1]. By necessity I needed to use C#/.NET for a project. It changed my view, mostly because almost all of Mr Wayne's questions could be answered quite easily. The package management, build system, IDE, installers, test framework, debugger, and documentation are all from Microsoft, come well-documented, and on all platforms of consequence. It's a breath of fresh air compared to the clusterfuck of competing tools (e.g. gulp, webpack, yarn and friends for JS) with overlapping features and bad docs that some other languages are plagued with. In C# on .NET Core, MSBuild + NuGet handles this for you. Compiler selection, package installation, building, test running, custom build steps, code generation, etc etc. Plus, NuGet's website and interface in the canonical IDE (Visual Studio) shows you the "'canonical' packages the community has consensus on".

[1] https://en.wikipedia.org/wiki/Beth_din (the autority for what is and is not kosher)

Agreed. .NET Core and C# have been genuinely pleasant to work with from the start because of who was behind them — Anders Heijlsberg, who was author of Turbo Pascal and architect of Delphi. Anders is one of those guys with good taste and a practical streak.

Many of us dismissed Microsoft back in the 80s and 90s, not primarily because it was predatory but because most of its stuff felt like commoditized output, had rough edges and lacked taste (Java today continues to have this latter problem). It was a bad halo effect.

I’m primarily a Linux guy but I started out in .NET Framework a couple of years ago, and am now writing in .NET Core. The experience is definitely much more cohesive, more curated and less fragmented than the JS ecosystem.

Anaconda Python for the most part is pretty cohesive in the Python world. (The Python packaging story is somewhat broken still but it works — packaging is a very difficult problem and no one gets it right entirely unless one is willing to tolerate opinionated inflexible solutions).

R/Rstudio and CRAN pretty much just works.

Besides focusing on language 1 vs language 2 I think the author is also highlighting just how hard it is for people to get started in any language. You mentioned R/Rstudio ....

I just wanted to work through an example in a book that I'm reading that has corresponding R code. I type require(package_name) into the command window and that doesn't work. I look at the help for "require" and there is nothing about how to install packages - I would think a reference to the install packages command would be useful (they link to how to check, but nothing obvious on how to install, maybe I missed it). After some searching I find the command and it prompts about whether I want to use the source code or not (after a few reads I understood what was going on but it could be improved). Things started compiling and then I tried to run my package again, no luck. So then I try reinstalling and this time I noticed the error - something like "exited with non 0 status". Awesome. Looking a bit closer I noticed one of the dependencies was not installing. After trying to install the dependency manually I somehow realized it was only for R version > 3.6, I'm on 3.5. So I figured updating RStudio would fix the problem, no luck. It's not like RStudio advertises what version of R they are shipping with Rstudio .... Now I'm on someone's Linkedin post (wtf?) looking at how to upgrade R from within RStudio. They indicate that on my mac I should updateR (or wait, they say that turns out to be not good, so just install from CRAN). Hopefully that works. Do I try my luck with R v4? Nothing's going to break there right ...?

This isn't meant to be a "R is bad" rant. Maybe C# or some other language really does avoid these problems, I don't know. However my experience has been the problems the author mentions are a problem everywhere.

You make a good point -- these problems exist everywhere. It's a trade-off between flexibility and restrictions/constraints. Some platforms manage this balance better than others.

The other issue is that many of us don't notice certain roadblocks because we're so used to working around them. In your case, my first instinct would be to `install.package(package_name)` and if something breaks, I google the error. Usually within 3-4 steps I'm on my way. But if something has just been released and no one's hit issues yet, google might not turn up anything. So then I'd have to open an issue on their github page and wait.

CRAN generally does a good job curating -- it has strict policies like if a package submission doesn't pass tests and doesn't succeed on automated builds on x number of platforms, it doesn't make it to the repo. That said, I've experienced a few package breakages before so I also want to validate your experience.

While I'm here, I also want to say as a Linux person, I hate the "compile first" culture of UNIX based software -- I'm not sure where it originated, probably GNU and open-source? Sometimes I just want to install a library and have it work -- just give me static binaries, don't make me compile stuff. I really don't care about the source code. To me as an end user, the appeal of open-source is that the source is available if I want it, but most of the time I really don't.

I get really frustrated when some Python packages don't offer wheels, and when the compilation breaks I have to spend hours/day figuring out what went wrong. TensorFlow 1 was particularly bad -- even with Bazel, things would break between releases. It's a huge productivity suck.

My introduction to Python (a long time ago) and "batteries included" was going to some random guys website to download all the compiled packages I needed. Thanks Christoph!

Yes, most people using Python on Windows have encountered Christoph Gohlke's massive unofficial win32/64 Python wheel site at one point or another.

Not sure why the power-that-be don't just make that the official wheel site for Windows binaries.

JS peasant here, I have not touched python recently but had to run a .py script to automate a task with FB website, sure enough had to download a couple of things from this person's website.

I am like the "before" version of you, so I have a question.

How did you get around the problem of not having any integration with Unix tools (or did you just not bother)? Maybe I'm not familiar with .NET. I see you can run it on Linux or Mac, but I don't imagine you can use Make or helper shell scripts if you want developers who use Windows to be able to build your code.

Quite apart from my loathing for Microsoft products, the reason I don't try things like .NET is that building for Windows when you're developing on Linux or Mac seems like POSIX, but 100 times harder.

You could use nmake and use a build.sh (well, build.cmd) if you wanted to, although it's not really common. My sense is that the hierarchy of build tooling goes something like this depending upon complexity:

1. Hit the "Build" button in Visual Studio with the MSBuild file it generates for you.

2. Write a custom MSBuild file that embeds your logic in XML and run it via the msbuild CLI.

3. Write the build script with something like Cake. Closest to writing sh to perform your build except that your script is done in C#/F#/etc. the same as your app. More verbose than sh for simple things but you get the same tooling assistance you would writing normal code.

> Quite apart from my loathing for Microsoft products, the reason I don't try things like .NET is that building for Windows when you're developing on Linux or Mac seems like POSIX, but 100 times harder.

It's actually less bad than you think. At the low end it's just `dotnet build` everywhere; maybe a `dotnet publish` is involved but you can cross-compile fairly easily. At the high end the build libraries are cross-platform, and should work anywhere dotnet itself does as long as you avoid embedding any platform-specific assumptions into your logic.

> How did you get around the problem of not having any integration with Unix tools (or did you just not bother)?

Emacs with Omnisharp gives you the usual autocomplete/inline docs/semantic rename/etc., although I'm not sure if you'd consider Emacs a Unix tool ;) I'm told it works well in Vim though I've never used it myself.

There should probably be a website that answers these questions for every language.

Just a giant table with language names on one side and standardized tooling names on the other.

This should be the top comment. Maybe we could collaborate on it via a github repo?

Sure, I made a stub: https://github.com/Kinrany/awesome-ecosystems

Realworld [1] is the closest thing I know. The implementations usually have everything except the list of tools necessary to actually run and develop the app.

[1]: https://github.com/gothinkster/realworld

Rust (Rustup) + IntelliJ (Jetbrains Toolbox) is the single best way to get the same thing for native code. Version manager for environments, cross toolchains, package management and building (Cargo).

Another approach is to just not use these stupid tools. I don't want to propose anything in particular, but it is nice to have an environment with bounds. I like to have something that just lets me create my own shit. And lets me use the occasional library to avoid a year-long extra project, without requiring me to buy in to another ecosystem.

Microsoft changed the official way to write Windows apps so much in the last decade(s), that it's hard to keep track of what combination of tools/SDKs and languages one should use.

They're the least stable platform by far when it comes to tooling right now and the perfect example of "fire and motion". Linux, Mac, Android, iOS all had fewer major changes in their development toolchains.

on all platforms of consequence

Those are quite the weasel words. Stay within the narrowly-defined targets for any language or ecosystem and you'll be happy. Once you start trying to do something interesting and supporting multiple versions of Windows Server $oldversions-that-your-customers-insist-on you will run up against the rough edges and will be screaming at Microsoft's handling of: codepages, charsets, filenames, installer standards (anyone actually using MSIX now? Do you enjoy writing your own installers using WiX or one of the proprietary fragmented toolchains?).

Microsoft still sucks, still seeks to restrict your freedoms with licensing and copyrights and is infinitely more fragmented and complex and incompatible than *NIX.

Reply on news.ycombinator.com