> You are comparing Go to Python, JS, and C++, arguably the three most complex languages to build.
No, I'm comparing to more than a dozen different languages that I've used commercially. And there were direct references there to Perl, Java, Pascal, procedural SQL, and many, many others too.
> There are languages out there that are easy to build, have a reasonable std lib
Sure. And the existence of them doesn't mean Go isn't also simple.
> and don't offload the complexity of the world onto the programmer.
I disagree. Every language makes tradeoffs, and those tradeoffs always end up being complexities that the programmer has to negotiate. This is something I've seen, without exception, in my 40 years of language agnosticism and part-time language designer.
As someone who's written commercial software in well over a dozen different languages for nearly 40 years, I completely disagree.
Go has its warts for sure. But saying the simplicity of Go is "just virtue signaling" is so far beyond ignorant that I can only conclude this opinion of yours is nothing more than the typical pseudo-religious biases that lesser experienced developers smugly cling to.
Go has one of the easiest tool chains to get started. There's no esconfig, virtualenv and other bullshit to deal with. You don't need a dozen `use` headers just to define the runtime version nor trust your luck with a thousand dependencies that are impossible to realistically audit because nobody bothered to bundle a useful standard library with it. You don't have multi-page indecipherable template errors, 50 different ways to accomplish the same simple problem nor arguments about what subset of the language is allowed to be used when reviewing pull requests. There isn't undefined behaviour nor subtle incompatibilities between different runtime implementations causing fragmentation of the language.
The problem with Go is that it is boring and that's boring for developers. But it's also the reason why it is simple.
So it's not virtue signaling at all. It's not flawless and it's definitely boring. But that doesn't mean it isn't also simple.
Edit: In case anyone accuses me of being a fanboy, I'm not. I much preferred the ALGOL lineage of languages to the B lineage. I definitely don't like a lot of the recent additions to Go, particularly around range iteration. But that's my personal preference.
I was a developer in the 90s and 00s and frankly I thought peoples dislike of Qt was pretty superficial. The problems being that GTK sucked. I’d have forgiven NIH (not invented here) syndrome if GTK was at least as good as Qt but it wasn’t. Frankly I even preferred oldskool Tk over GTK.
In the time frames we are talking about, I also cared very little for NeXT. It did have its fans and deservedly too. But I was banking on BeOS becoming the POSIX workstation of choice. I even preferred that over Linux. But 90s Linux wasn’t exactly a smooth experience like it is today.
These days little has changed my mind about GTK vs Qt.
Modern C is very different to K&R's C. Which itself was based other programming languages before it (like B - got to love their naming convention for programming languages!). But the history of C aside, it wasn't the only language that operating systems were built on. LISP, Pascal and obviously assembly / machine code too. In fact Pascal was a very popular systems language on home computing in the 80s and early 90s. If I recall correctly it used heavily by Microsoft and Apple too.
Don't get me wrong, I do like C. But it wasn't the run away success nor holds quite the monopoly you suggest it does.
I'm not about to tell people which platforms they should run - each to their own and all that - but I do feel it's worth mentioning there's no need to use emacs nor vim on Linux if you didn't want to.
Is that a new thing? I didn’t see that option when we looked and I seem to recall it was a common complaint at that time too. I wonder if that’s come about because of GDPR?
Anyhow, it’s handy to know it is there so thank you.
Most people are not at uni and rented boxes usually have root open by default expecting customers to then disable root access and create a user with su / sudo rights. Plus I tend to take things further and create a dedicated groups for ssh so that rsync / sftp users cannot use a system shell nor port forward and are chrooted while a very small subset of administrators have full ssh access.
Plus even if you do borrow someone else's box, can you be sure that they'd even be grateful that you're using up their bandwidth?
Ssh is a dangerous protocol to leave open to the WAN, so setting up an ssh server properly, while not a time consuming job, will still take longer and more effort than simply deleting a few files afterwards.
If you need an SSH server to begin with, then there's still some setting up you need to do before hand. The pain of having to delete a few files afterwards is really nothing compared to renting a Linux box, setting up SSH accounts with fail2ban and/or SSH keys; and so on.
So file-share doesn't even work as a pain free solution like you suggest it does.
As I said before, I don't like to stamp on another's creativity. I'm just saying that there are better tools for doing this which already come pre-installed with most Linux distros, UNIX's and OS X.
FTP is just a horrible and massively outdated protocol which we really shouldn't be advocating for the modern internet[1]. Particularly when everything you've suggested can be much more cleanly done using existing tools on Linux / UNIX / OS X: scp, rsync, git, sshfs (some of which are often pre-installed on the *nix image)
So he's built a file sharing tool which requires an SSH server to work? So why not just use sshfs, scp or rsync?
I don't mean to stamp on someone's creativity, but SSH already has a whole bunch of tools for transferring files - all of which already work pretty well.
No, I'm comparing to more than a dozen different languages that I've used commercially. And there were direct references there to Perl, Java, Pascal, procedural SQL, and many, many others too.
> There are languages out there that are easy to build, have a reasonable std lib
Sure. And the existence of them doesn't mean Go isn't also simple.
> and don't offload the complexity of the world onto the programmer.
I disagree. Every language makes tradeoffs, and those tradeoffs always end up being complexities that the programmer has to negotiate. This is something I've seen, without exception, in my 40 years of language agnosticism and part-time language designer.