> 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.
If you want your spend to be capped then there’s nothing stopping you from setting a CloudWatch alarm at a budgeted threshold that then scales down your infra.
AWS is like Lego. You’re supposed to build on it to create the behaviour you want
> Consider a scenario where you're consulting on someone else's small- or medium-sized project and your bug costs the client a huge amount of money in the middle of the night
You can also set alarms that warn you of projected usage.
> Now who pays? Say goodbye to your paycheck or reputation, even though it should have been preventable.
If it’s legitimate usage then I’m not really sure what you’re advocating; are you implying a service being suspended in the middle of the night because a hard spend limit has been hit is somehow better for your reputation?
Or maybe you’re suggesting that it’s not legitimate costs, in which case you’ve set AWS wrong to begin with and thus your reputation probably deserves to be queried.
> Another scenario: you launch a startup, and a bug empties the bank account and kills the company. If the solution is to just not use things like AWS and GCP (including Firebase, which has no billing cap) when you're getting started, why are they advertised that way?
No cloud service operates that way. In that situation you’ll almost always get charges refunded. Even in instances of gross negligence (which would be the case here since for the bank account to be emptied it means you’ve not been watching your spend for more than a month and no business should operate that way)
I do get the points you’re trying to make but I’ve been working with the cloud for some time and have seen plenty of horror stories, all of which were due to gross negligence and most of which were still refunded by AWS as a gesture of good will. They’d much rather have your repeat business than burn their users with bills that cannot be paid.
> > and at an individual level it’s very manageable
> And yet, we have horror stories of students and even experts being hit by surprise AWS bills.
They obviously didn’t bother to manage it. But that doesn’t mean it’s not manageable. It takes all of 5 minutes to set up a budget alarm on CloudWatch. It was one of the first things I looked into doing when I set up my own AWS account years ago specifically because I didn’t know what I was doing back then and thus didn’t want any surprises. If I managed it then, then I find it hard to believe others cannot too.
That’s not entirely fair. While I’m not going to defend the complexity of billing in enterprise cloud services it’s also not really that hard to set an billing alert in CloudWatch and track spend in Cost Explorer. Sure it requires a little bit of AWS knowledge but you shouldn’t really be using enterprise services like AWS (over other more accessible services like Digital Oceans) if you’re not willing to spend the time learning it; and at an individual level it’s very manageable.
The reason those consultancy firms exist is because billing scales terribly. Once you’re a business using AWS you’d likely have a multitude of projects running across a multitude of departments which need to be billed to a multitude of different customers and internet cost centres. This all needs to be processed by an internal 3rd party financial system managed by non-technical people who wont even know what AWS stands for let alone what it does and how it works. In those situations the problem of billing becomes exponentially more difficult than a one person hobby project.
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.