Unfortunately, the problem with Nim (as well as D) is the lack of big player support jump starting public opinion.
Languages are inherently vendor-locked* (There isn't any way to foolproofly translate code from language A to language B), so I won't write code in a language which may disappear tomorrow or drop support for my system.
* It's true that there's no real vendor lock-in by OS code, but unless there's a large community around the language which can pick up where the inventor dropped off (like C), you're on your own, and unlike small projects, languages have huge codebases which also require specialized knowledge to maintain.
>data on which they (should) adapt to their user needs.
Then make it optional. Or at least opt-out. Or say that if you don't enable telemetry, your opinion won't count. Or at least tell you what they're getting and how.
1. Sometimes being able to ship is more important than being perfect
2. Sometimes I don'tcare if it's perfect. If I need something for in-house use, Go (and Python) is quite enough for my needs.
>I don't understand people who hate generics. They are just types and they are here to help the developer write compile time type safe code. interface {} everywhere isn't compile time type safe.
You're right, and the FAQ explicitly says that the designers aren't happy with the choice either.
If there would be a one time compile penalty for generics, it may work. The issue is that if large code-bases (Go's reason de'etre) will now take an hour to compile instead of five minutes, it's just dead in the water.
Also, it looks like they want to make Go a language where all code looks the same. So you won't find team A writing C++ like in 1980, team B writing C++ in OO mode, team C writing C++ in FP mode, etc.
It's so fanatical, that the spacing is standardized.
>And Android. Android used to honor the promise of being open. Years ago. This was before every manufacturer was encouraged to lock bootloaders, and back when platform SDK's and drivers for hardware were generally available even if they were kinda hard to get. This was also before the Android kernel heavily diverged from mainline Linux, and before "google play services" grew from a tiny app to a framework that powers half the OS features.
The only thing Google is directly responsible is Google Play Services, and
1. A good of that is a shim to Google's servers.
2. Is small and emulate-able (especially if you don't really intend to connect to their servers).
3. One can run plenty of apps without it. Mostly Open Source, but I've heard of people running CM without Google Play. I've never heard anyone run Windows 10 or iOS in OpenSource mode only.
From a developer's point of view, on one hand, I like this idea. Just about any development environment is better than Android:
1. Callbacks are horrendous. I hate inner classes, they're ugly and unwieldy. I'd honestly rather something like AWT's (Yes, that 90s tech) callbacks over inner classes.
Just have a main function with a large switch. It's much easier to reason that then the current mess-up of trying to figure out your app's lifecycle.
2. Inter-thread communication is horrendous. Android is Java based, so can I pass classes?
No.
Only Strings.
And even that is horrendously ugly.
3. It's a Frankenstein model. It's a Desktop OS like process/file model, but not everything is a file. Now they suggest opening using the new file-picker.
But in many ways files are easier to use.
4. They add new libraries (Material Design, for example) which no one will ever use, because everyone needs to use appcompat. And even in five years, when Lollipop will be like Android 2.2 is now, everyone will still have to use appcompat to get Android Z libraries on Android O, or something. And by the way, now most apps rely on appcompat-7 which relies on appcompat-4.
5. Many classes are broken - Take TextView. You can style it with HTML, but only a small subset (so you can't use it as a WebView). So it's not meant as a "web browser" replacement. But it can parse broken HTML. Wow, so developed.
But you can't style a link color, or change underline color.
------------
But on the other hand, I'd find it horribly annoying (and I think that many others would feel the same way) having to rewrite everything from scratch into Dart or whatever.
It killed the one thing C was good at - simplicity (you know exactly what happens where, note I'm not saying speed, as C++ can be quite a bit faster than C).
>This comes down to one of the key differences between Linux and BSD: BSD "owns" its userland—the people who develop the kernel, or some system utility, can literally decide to change something, and then do a global search-and-replace on all usages of that something across all consuming projects. Because all those projects are "part of" BSD in a very literal sense. You can decide that ifconfig(8) should work differently, and bam, there you go, now it works differently. Now the tools that call it and parse its output work differently, too. Everything works differently; but everything still works. Document the new behavior in the man(1) pages.
1. Linux doesn't care about ifconfig et. al. It's Debian/RedHat/Arch/Gentoo/Slackware that does. And they can do the same grep across their codebase.
They don't now for the same reason BSD doesn't just run in and change things, because lots of admins have scripts which aren't maintained by BSD which depend on existing config.
2. I would assume that the BSD ifconfig came first, so why didn't existing distros copy their system? Is it a BSD vs. SysV thing?
>The Linux community was way more trying to run on everything.
In contrast to some opinions, I like this sometimes.
For example, would the world come to an end if FreeBSD came with neovim?
If the prompt out of the box showed pwd?
I know that some things are controversial (ahem systemd), but when learning a new system, little things matter and make your system popular.
(And, as a side rant, in contrast to some who like to use haskell on nixos (Which I actually like!) running on an obscure chipset, popularity is good. If someone asked me what Unix should he learn, I'd send him to Linux and not FreeBSD, since it's going to be much easier to find noob help online. Then, this noob will go on to become a sysadmin, he'll recommend Linux because he knows it and will be able to find others who do.)
>you can easily run your own pkg repository with binaries compiled for multiple architectures (with build enviroments isolated with "jail") and providing the full range of compilation customization included in the ports tree.
Sure, if you're running a few servers. It doesn't help if you're running one though.
In my opinion (mostly Debian user with a bit of FreeBSD playing), people use Debian as a server for the same reason a lot of people like MacOS over Linux - It Just Works.
1. For many years, the only way to install software was ports. Now if you're a full time sysadmin with time on his hands, it's great. But if you just need something up and running fast (and if you don't know your software internals, and don't know if you'll need perl's FLAG_ABC) , it's horrible.
It just feels like Linux in the 90's (been there), where recompiling the kernel/freex86 was a right-of-passage into Linux hackerdom. Nowadays, most of the time it's just not worth it.
2. apt vs ports/pkg. This is actually the biggest thing keeping me on Debian - stable + backports.
If I'm running my server, I want things to be stable. Now I know that there's no other project the size of Debian, which can backport security fixes to two year old software (and sometimes four year old software), but there's nothing like apt update && apt upgrade and 99% of the time have everything update without a hitch.
Yes, FreeBSD is more elegant (why couldn't GNU/RedHat have just modeled ifconfig rather than ifconfig, ifup, ip, etc.). Yes, FreeBSD's man pages are amazing (which is quite important, as there's not as many FreeBSD blogs around), but if you're learning a new system (coming from Windows), Linux isn't that much harder to learn than FreeBSD.
EDIT
And RedHat?
They work like Oracle - You pay them, and they'll hold your hand, and (unlike Oracle) they release their software under an OS license.
If you're a non-tech Fortune 500, that's very important.
Note, by the way, that those two distros have the vast majority of GNU/Linux installs.
Languages are inherently vendor-locked* (There isn't any way to foolproofly translate code from language A to language B), so I won't write code in a language which may disappear tomorrow or drop support for my system.
* It's true that there's no real vendor lock-in by OS code, but unless there's a large community around the language which can pick up where the inventor dropped off (like C), you're on your own, and unlike small projects, languages have huge codebases which also require specialized knowledge to maintain.