Live data from Hacker News

Announcing Azure Command-Line Interface 2.0 Preview

azure.microsoft.com

151–160 of 161 posts

Re: Announcing Azure Command-Line Interface 2.0 Preview

#151

Earlier quoted context omitted.

There is this radical idea in software development that sometimes you use the language that is best for the job -- not just the one you are already using!

Right...but it still wasn't built for people who do not know how to program very well. It was written for JavaScript programmers. Nothing else really needs to be said other than that.

Well I disagree. It was written as a limited browser scripting language in 1992. I was never meant to be a full-blown development language. So, I guess that needed to be said ...

Re: Announcing Azure Command-Line Interface 2.0 Preview

#152
post #34

motivation: - Dependency management for Node.js adds maintenance costs for Linux distributions. - Cloud tooling vendors prefer Python to match AWS CLI and GCloud CLI. - Python offers a more mature platform for building CLIs Python is typically available on Linux distributions by default. - While none of these reasons precluded building the next CLI in Node.js, Python was the natural choice. taken from here - https://…

I think Golang would have been a better choice. They already have a fairly mature Go SDK, and redistribution of Go binaries is so much easier.

Re: Announcing Azure Command-Line Interface 2.0 Preview

#153
post #150

Earlier quoted context omitted.

So how exactly is a comparison of JS/PHP/Ruby relevant in a dicussion about a tool rewritten from JS to Python?

It debunks the mistaken popular belief that JS is somehow a significantly worse language. Also, I can't help but wonder how this: http://docs.python-guide.org/en/latest/dev/virtualenvs/ is somehow better compared to npm...

ok, let me rephrase that:

"We rewrote this from JS to Python."

"Guys but JS is better than PHP and Ruby!"

Still cant see how is that relevant.

Re: Announcing Azure Command-Line Interface 2.0 Preview

#154
post #150

Earlier quoted context omitted.

It debunks the mistaken popular belief that JS is somehow a significantly worse language. Also, I can't help but wonder how this: http://docs.python-guide.org/en/latest/dev/virtualenvs/ is somehow better compared to npm...

ok, let me rephrase that: "We rewrote this from JS to Python." "Guys but JS is better than PHP and Ruby!" Still cant see how is that relevant.

Conveniently skipped the cancer part:

"We rewrote this from JS to Python!"

"They did this because JS is so horrible, its cancer!"

"Uhh, actually, JS is not significantly worse. It does well when compared with typical mainstream dynamic languages"

I think its worth debunking this supposed "cancerness" of JavaScript and the importance of the cited-to-death superficial "wat" talk on implicit conversions, by providing some perspective on where JavaScript's quirkiness actually lies on the popular dynamic languages spectrum.

Maybe then we will be able to have an actual discussion on the pros and cons of the language choice (like runtime availability, and the fact that package managers don't know what the heck to do with node and npm's sandboxed-by-default modules), instead of the middlebrow "its all just JS insanity" dismissals

Re: Announcing Azure Command-Line Interface 2.0 Preview

#155

Earlier quoted context omitted.

Right...but it still wasn't built for people who do not know how to program very well. It was written for JavaScript programmers. Nothing else really needs to be said other than that.

Well I disagree. It was written as a limited browser scripting language in 1992. I was never meant to be a full-blown development language. So, I guess that needed to be said ...

OK but I was talking about Node, not JavaScript.

You certainly cannot say that JavaScript was NEVER meant to be a full-blown development language though because now it is since it has grown into that overtime. Just because it wasn't originally conceived as such does not mean anything. The same thing happened with BASIC and Visual Basic. It doesn't mean anything.

It's like saying that wheels have no value because the original wheel was never meant to be used in autonomous cars.

Re: Announcing Azure Command-Line Interface 2.0 Preview

#156

Earlier quoted context omitted.

All of these platforms offer a free trial and a lot of products have free tiers. I'd check them out and decide for yourself. (I work for Google Cloud and am happy to answer questions about GCP)

Are you familiar with people porting code/applications that were intended to be run on a Linux cluster (using MPI over Infiniband) to one of these cloud services? We have some people at work asking whether this is possible. Sort of like HPC on demand. I'm guessing the interconnect between the nodes isn't as low-latency, high bandwidth as IB, but I may be wrong.

Yes, this is possible. The Azure A8-A11 VMs have Infiniband, as do the 'r' (RDMA) variants of the new H series. Azure Batch includes support for MPI-like runtimes although you need to get the MPI runtime and application onto the virtual cluster yourself. There's documentation for it here: https://azure.microsoft.com/en-us/documentation/articles/bat... and some more Linux-focused material here: https://blogs.technet.microsoft.com/windowshpc/2016/07/20/in...

Disclosure: I'm an Azure Batch engineer.

Re: Announcing Azure Command-Line Interface 2.0 Preview

#158

Earlier quoted context omitted.

> i'm sure i'm going to burn karma for comparing node with vb but... I'll take the hit for you and flat-out say that node.js is the new VB. In fact, for those of you that have been around a while, I think we can all agree that node.js is the new PHP was the new Visual Basic, etc. Not in the sense that they do the same things, but that they were purposely built for non-programmers (baby-devs) to be able to program (wh…

Node.js wasn't built for baby devs, it was built for professional devs who had to use JS anyway because browsers to be able to use the same technology on the back-end rather than using different languages front- vs. back-end.

While I agree that it wasn't created for 'baby devs', wasn't the primary reason for Node.js' creation that Ryan Dahl wanted an async ecosystem/platform, and javascript had the 'advantage' of not already being used server-side, so there would be no confusion over sync/async libraries/modules?

At least that's what I recall from reading/watching the initial videos back when it was released. At the very least I've never heard the 'same language front and back' argument until later on in Node's life.

But perhaps I misremember?

Re: Announcing Azure Command-Line Interface 2.0 Preview

#159

Earlier quoted context omitted.

> i'm sure i'm going to burn karma for comparing node with vb but... I'll take the hit for you and flat-out say that node.js is the new VB. In fact, for those of you that have been around a while, I think we can all agree that node.js is the new PHP was the new Visual Basic, etc. Not in the sense that they do the same things, but that they were purposely built for non-programmers (baby-devs) to be able to program (wh…

Seems like javascript is picked up by giants (microsoft build its IDE) facebook (React?) Google (angular) so I guess you cant compare it with VB unlesss I missed something in the 90s

many comments here, still my argument that there were no major projects and IT giants building important stuff with VB holds. Downvotes or not, you can't compare these two languages.

Re: Announcing Azure Command-Line Interface 2.0 Preview

#160

Earlier quoted context omitted.

> weird invisible things that trip you up like hoisting Huh? How can you get tripped up by hoisting? I'm genuinely curious.

Any time you have a closure that captures the hoisted variable. Most often, this happens with loops. Say, someone might start with this: for (var i = 0; i Then when they realize why this doesn't work, try something like: for (var i = 0; i And then that breaks too, and it's not at all clear why. It's not that other languages don't have similar limitations - Python also doesn't have block-local variables, for example.…

Ok, thanks. I would call that a problem with not having block scope, not a problem with hoisting. Not trying to be pedantic; I was just confused about how hoisting could be such a problem. A language could have variable/function declarations hoisted to the top of block scope rather than the top of function scope.

And as I'm sure you know, JS now supports block scoped variables through `let` and `const`.

Post reply on HN