Moreover it emphasizes reproducible build and seems to handle dependencies in a sane way.
Nix has very sensible defaults and defining a Nix expression to install a cmake or autotools package is a breath. But even projects with just Make or no build system at are easy to install, you just need to copy the output to the /nix/store in the installPhase (to $out). And I can easily define Python or any other language dependencies in the same consistent and concise syntax. I have no fear anymore I won't be able to install dependencies in the future. Any other dev just does `nix-shell` in the project root and they are sure they are ready to go. I even used to hate the Nix syntax (as opposed to Guix) but at some point it "clicked" and now it makes a lot of sense.
Only drawback is no Windows support. Maybe someone at Microsoft could help with that? It would be so sad to have the community converging to a suboptimal solution just cuz Windows... :/
Does Nix make it easy, or even possible, to bring in dependencies from legacy sources on the network? For example, my company has an FTP server full of carefully-packaged, versioned libraries in tarballs, and it would be great to be able to use those, rather than having to repackage everything.
The documentation is good but it can sometimes be a bit rough. There are some good blogposts on how to achieve specific things that you may find when searching around. Also the IRC community seems is quite active, responsive and friendly :-)
Which is false. DEBs and RPMs are not tied to the OS in any particular way. Especially visible in OpenPKG project (it used RPM), which was running on Solaris just fine.
It's more likely that it's OS distribution that is tied to the package manager, not the reverse.
I would like to see how it would work on the native environment for IBM z/OS, for example.
The problem is extra work is needed to support things like cross compilation.
Instead, you want to pass a toolchain file that describes the build environment(including for cross-compilation) to the build system, and it will compile it correctly for the target. This is the way cmake works, but we should have standard toolchain file that can be used across all build systems instead of requiring everyone to use cmake.
For those on the cheap side, Microsoft had the express versions for quite some years now.
> Other platform vendors also sell their compilers.
Also, no, Apple's platform compilers are free (though obviously somebody pays for them), and so are the platform compilers for the major free operating systems GNU/Linux, FreeBSD, OpenBSD, Solaris. Sure, you can buy ICC or XL C/C++, but it isn't the only supported way to build and link against those platforms.
Sun Forte surely wasn't free.
While you can install gcc on other systems, usually doesn't support all features available on the OS vendor's compiler toolchain.
Specially on commercial proprietary UNIXes, mainframes and embedded systems.
"*Visual Studio Express 2017 is available for Windows Desktop developers. This will be the final version of Visual Studio Express, and there will not be a UWP or Web offering of Visual Studio Express 2017. We encourage all users to look at the free development options offered by Microsoft such as Visual Studio Code and Visual Studio Community for future development needs."
Community has license restrictions that were not in place for express versions.
There is also a build tools package now which has the compiler without an IDE, but i'm not clear on the licensing for it.
Any larger company can surely afford professional licenses.
When I started on IT we had to buy everything, just like on other professions.
The problem is that no matter how far MSVC goes, those with old licenses for one reason or another tend to bring down the lowest common denominator. I would have no qualms buying a VS Professional/Enterprise license and upgrading it if I were in that position, but I can not very well stand on my pulpit demanding that everyone else do so.
The great thing about the free compilers is that there are enough disparate incentives in the world to fund their development. AMD, Intel, Samsung, Qualcomm, ARM Holdings, and basically everyone else who designs and sells CPUs or GPUs, or uses either compiler extensively enough, contributes to LLVM and/or GCC for the purely selfish reason of making sure the code that is generated makes their platform or software product look good.
The efficiency is very high, because nobody has to sell or market the compiler itself, because the compiler is a tool to ensure the marketability of their hardware products. When AMD wants to sell GPUs to the deep learning community, they base their work on LLVM because it is cheaper for them. They put it in the open because it makes it easier to consider using ROCm in your deep learning or image processing workload; because on the long tail of rare bugs, it is more likely that the customer will fix the compiler than the vendor, even if the vendor is being paid.
I don't like the tone or tenor of the responses to me in this thread at all, you folks are making it out like a) I personally don't pay anyone for compilers, or b) I don't think it costs money to develop software. In reality, I just recognize that the recurring licensing cost of MSVC encourages people to use old compilers with lower feature sets, which in turn encourages open source projects to accommodate those lower feature sets way past their due. With the free compilers, yes the majority of people are freeloaders, but you can at least be expected to have the most recent version (and obviously there was enough money in it to make that happen!).
MSVC is not a better compiler, by basically any metric except Windows integration, than either GCC or LLVM. LLVM and GCC are built entirely on the selfish interests of the union of its users. They are free to freeloaders, valuable to exploit, and always fresh. What exactly is not to like here?
If you spend all your time belittling and making light of people, you'll never hear what they have to say for what it is.
The problem with funding open source projects is that monetization can kill the community. You either have a dual license scheme or a support contract scheme where a few guys make money and the rest doesn't.
We have less than 5 devs but failed one of the criteria listed here: https://www.visualstudio.com/license-terms/mlt553321/
For what it's worth, a lot of the glaring issues will soon be alleviated, I'm not that enthusiastic about C++14, C++17, etc. features anyway. C++11 for me is really about catching up with C99.
I don't see any reason for a company to not pay for software licenses.
They don't offer upgrades for free.
Even on macOS eventually getting a new version implies an hardware upgrade to get hold of the newest version, thus indirectly paying for the compiler.
The problem is that the unique combination of ubiquity, expensive upgrades, and relative lack of substantial innovation (which would offer an additional incentive for upgrades) means that MSVC shops can be simultaneously willing to buy licenses one year, and unwilling to buy upgrades another.
I don't like your inquisitive tone and persistent uncharitable reading of my comments, and I will not engage any further without an outright apology.
Good day.
The VS Community license is fine for small companies, and I don't think the licensing fee is a major issue for larger companies. 'Small companies' being defined as those with less than $1 million annual revenue and < 6 employees using the software concurrently.
In my ideal world, nobody would bother with using the MSVC compilers (or they would finally make upgrades free for the compiler at least), and we'd all be running the latest stable or LTS versions, and have similar standards for compiler features and performance. Unfortunately, there is a market incentive for some companies to use MSVC, and there is a market incentive for them to not upgrade that MSVC license until they absolutely must.