Announcing Azure Command-Line Interface 2.0 Preview
azure.microsoft.com
azure.microsoft.com
Half the people complained about VB being good enough and more popular.
But the overall feeling was that once the rapid application dev version is out the door and ok then it's a good time to redo it with something more engineering-y, for long term support before the first version gets too ossified.
(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 (which is good!) but by the same token, invited entire (and continuing) mountains of half-assed, unsupported(unsupportable) code that just begets generations of garbage.
If you are a consultant, fixing this garbage can be a whole career.
Isn't it possible to say this for just about every programming language?
The lower the barrier to entry, the more "inexperienced" people you get
And with nodejs the inmates are running the asylum
There is great nodejs code, for sure. But as left pad has shown us, it seems it is a big "Neverland"
But C++, Java, Perl, even Python has a bit of a learning curve that demands some small amount of commitment (and more importantly, understanding) to get moving with.
Javascript, VB, PHP can get a person creating things in an afternoon (which I am not against, I like that it might inspire people to get into "real" development), which invites hit-and-run development.
Node.JS === Javascript
Maybe Javascript == Node.JS then?
outside of internety places, big iron and academia, that was it. 'must be compatible with windows' started appearing in 'request for proposal' specs.
what microsoft pushed got massive mind share.
I think this was a reference to ActiveX. Although most ActiveX controls weren't written in VB, either, even though you could do it - the resulting control was just too large to download, because you had to include ~2 Mb of VB runtime (remember, we're talking about the time back when dialup was still incredibly common - and 2 Mb takes 5 minutes to download on 56k). Mostly it was done in VC++ with ATL.
Kind of related, it was a COM control you could stretch over your whole desktop, that received push notifications.
Also, I believe it was TOTALLY secure.
Edit: Dang it, I missed where they said "and it made ie the king of browsers." -- Yes, ActiveX
I like Python too (as well as node,) but your characterization of node is over-broad and, imo, inaccurate.
... as an alternative to C++ and Perl. And in that respect, it is a snap to pick up. It is pretty easy, not as easy as, say, Javascript, but still easy to pick up, I agree.
Node.js is cancer. We all use it, because of the momentum it has with designers instantly being able to declare themselves "full-stack devs", but make no mistake -- Node.js and npm are an abomination that we will look back on in ten years and shudder.
* implicit conversions, which you can get rid of at compile time using TypeScript or Flow.
* lack of explicit ints and ints with more than 31 bits (JITs can give you SMIs, or 31 bit integers for things they can prove are always integer values)
And thats about it.
Javascript is fine if you don't use Javascript.
> lack of explicit ints and ints with more than 31 bits
Javascript is fine, except where it's garbage.
I don't really have a problem with javascript. I just don't want to build anything of any real complexity with it.
In ruby, blocks are like lambdas except when they are not, and you can pass a block explicitly or yield to the first block implicitly. But there are also lambdas, which are different. Modules are again uselessly global, and cannot be parameterised over other modules (without resorting to meta programming). Oh yeah they are also another syntactical and semantical concept. Why not just `Module.new`? And there are classes, with private variables, which are prefixed with @.
The above examples are just scratching the surface
So yeah, I'm tired of people claiming that JS has the same amount of quirks as PHP. Boo hoo, its so horrible: no large ints, and implicit conversions. Compared to that, Ruby, PHP or (god forbid) Perl < 6 are total disasters. Pre-ES6, JS had the greatest power-to-number-of-concepts ratio of all current mainstream dynamic languages (1). With just prototypes, closures and objects, it manages to provide features that other languages do not with a dozen of base concepts
(1) cheating a bit here, because you could argue that Lisp or Lua are mainstream enough.
Also, I can't help but wonder how this: http://docs.python-guide.org/en/latest/dev/virtualenvs/ is somehow better compared to npm...
"We rewrote this from JS to Python."
"Guys but JS is better than PHP and Ruby!"
Still cant see how is that relevant.
"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
It's like the castle in the Holy Grail:
When I first came here, this was all swamp. Everyone said I was daft
to build a castle on a swamp, but I built in all the same, just to
show them. It sank into the swamp. So I built a second one. That
sank into the swamp. So I built a third. That burned down, fell
over, then sank into the swamp. But the fourth one stayed up.
And that's what you're going to get, Lad, the strongest castle in
all of England.So I write a ton of JavaScript including plenty in node. But make no mistake bower, webpack, babel and npm are all crap. They're hacks. Bandaids to make ES6, the web and JavaScript modules packaging and installation work correctly. They all have their own issues, huge dependencies (I mean holy crap it took me several minutes to install Babel last time I did it all just so I can use slightly different syntax and deal with map files? ugh).
Do you have a citation for that? My understanding of the timeline and Guido's writings on the subject make it seem very unlikely that C++ or Perl had any significant impact on the decision to create Python or the design of Python. Python would very likely still exist in a world without C++ or Perl, as far as I can tell.
Python isn't even in the same lineage as either of those languages, though it shares a lot of features and patterns with Perl (as there has been some cross-pollination between the communities over the years). And, Python (started in 1989) is only a couple years newer than Perl (1987) and Perl was tiny enough to likely not really even be on Guido's radar at the time.
There may be a bunch of developers who think in terms of their own evolution as coders, and when they discovered various things, and your history may have Python coming well after Perl (I know I only started using Python professionally six or seven years after I first used Perl). But, I think you're overlaying your own perception onto events and it's distorting the actual history.
Look at slide 4 of http://www.aleax.it/Python/ep03_meta.pdf:
>>> "Putting Metaclasses to Work", by Ira Forman and Scott Danforth (AddisonWesley 1998) / strong influence on Python 2.2 & later / based on IBM SOMobjects & C++
That's only one thing coming to mind :) (immediately followed by the quote: "In the past, the subject of metaclasses in Python has caused hairs to raise and even brains to explode (see, for example Metaclasses in Python 1.5). Fortunately, in Python 2.2, metaclasses are more accessible and less dangerous." by Guido at https://www.python.org/download/releases/2.2/descrintro/ -- referencing same C++ book(s), actually)
https://en.wikipedia.org/wiki/Python_(programming_language)#...
"Over six years ago, in December 1989, I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. My office ... would be closed, but I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately: a descendant of ABC that would appeal to Unix/C hackers. I chose Python as a working title for the project, being in a slightly irreverent mood (and a big fan of Monty Python's Flying Circus)."
I agree that it's cancerous, and that making the server side more accessible to front-end developers isn't worth all the problems Node introduces long-term. My dream is still a statically-typed version of Erlang.
I personally have found my go-to tool for web development - Scala. It is a breeze to work with, and I advise anyone looking to develop web apps to give it a try, especially if you're tired of dynamic languages
Reminds me of these post: http://prog21.dadgum.com/203.html
Your (our) dream is about to come true: https://github.com/j14159/mlfe
Huh? How can you get tripped up by hoisting? I'm genuinely curious.
for (var i = 0; i < 100; ++i) {
foo().then(function() { bar(i); });
}
for (var i = 0; i < 100; ++i) {
var j = i; // this is inside the block, so it's scoped to it, right?
foo().then(function() { bar(j); });
}
It's not that other languages don't have similar limitations - Python also doesn't have block-local variables, for example. The problem with JS is that is uses syntax that strongly implies that it does have block scope, but then quietly makes it do something unexpected when you try.
Ironically, the only other language that I know of that has the same exact problem is VB (pre-.NET one) - its "Dim" statement can similarly be used anywhere inside a function, including inside loops and other block constructs, but the scope is always the entire function.
And as I'm sure you know, JS now supports block scoped variables through `let` and `const`.
So something like Haskell?
But I do agree: Sometimes I see people try to push Node/Express as a good choice for teaching basic APIs. Its not the worst choice, but its startling how easy it is to forget how insanely confusing async callbacks are for new devs.
I like to think of C++ and Python as of concrete and wood: if you are to build houses, you better know concrete and wood. There are more fancy materials and prefab assembly, true, but these are better left for quick and dirty work for now, and used by people who already know concrete and wood.
It's sad Object Pascal has died, it was a good language with good history. C# has some of its legacy, I'd use it more but last time I checked, Mono still has severe performance problems.
The process was not without its challenges, but developing on a modern platform and backporting was a breeze, and I'm not worried about upgrades.
This is in stark opposition to "just let me quickly do stuff, and I don't care if the resulting code is buggy and unreadable" - the VB6/PHP school of language and framework design. Which, unfortunately, seems to be a rather popular approach in the JS ecosystem, as well.
I think VB is more similar to Python in the sense that both languages were designed with some sense of simplicity and straight-forwardness in mind.
Both PHP and Javascript are much more complex from a language design standpoint, which makes them more difficult to learn "well" for beginners. Yes, they are both hugely prolific because of the web, and lots of people copy/paste code around not having any clue how it works, so I won't deny your "generations of garbage" comment. But you're assessment is a little too simplistic.
A good engineer can write high quality code in "almost" any programming language. It's the coder, not the language, that determines engineering quality.
Complex in the sense that they were originally thrown together and the results of the program might best be described as "stochastic output", yeah I can agree with that.
> A good engineer can write high quality code in "almost" any programming language. It's the coder, not the language, that determines engineering quality.
Sure, but it sure seems funny that "high quality code" is nearly non-existent in PHP and javascript world ...
Absolutely, they are complex because of poor initial designs, and actually even more complex now due to all the efforts to maintain backwards compatibility...
> Sure, but it sure seems funny that "high quality code" is nearly non-existent in PHP and javascript world ...
jQuery is an incredibly well engineered library by John Resig. I think that jQuery was one of the big technological leaps forward that led to the proliferation of web applications.
For a long time, people thought that cross browser JS inconsistencies and confusing API standards meant that you couldn't build interactive UI applications in the browser. And now they are ubiquitous.
So I guess it depends on your definition of "high quality code". I don't think quality code is about some arbitrary coding aesthetic. It's about results, and it's about what your code does, and how it creates value.
Moving the goal posts so that the definition of 'high quality' is basically code that compiles and runs as long as it 'creates value'? What about when you have to change it later? What about if it has to be really fast?
People who think that Javascript and PHP are crappy languages aren't just comparing these languages to 'arbitrary coding aesthetics'.
I'm not defending the design of JS and PHP. I'm saying that if you are a good engineer, then you can produce code that is quality in these languages.
Also, I'm pretty sure Facebook gets "updated" and is "fast" ;)
PHP code is a breeze to work with using composer, and most packages use namespaces and have great intellisense. But good luck doing anything concurrently.
NodeJS is fast, and boy can it handle a lot of tasks at once using the event loop! But I can't for the life of me figure out modules or get good intellisense.
There's plenty of high quality code in each. I'd just never write a complex app in either.
That's just a platitude, and it's wrong.
Languages with better features allow engineers at varying levels of experience to write better code than they otherwise might.
JS almost forces you to write garbage.
There are ways to work around this...
First, ES6 brings a lot of enhancements to JS. However, it also makes JS even more complex and unwieldy because now you have all of these new and old language features co-existing.
If you use a tool like ESLint, you can limit yourself to a subset of the whole ES6 standard that I think is a decent programming language.
There's also other ways to go at it, by using a language that compiles to JS like TypeScript, however maybe that would be considered cheating in the context of this argument.
It didn't even have a regular syntax for the sake of backwards compatibility. For example, Line was a method on Form (kinda eh, but okay); but you couldn't actually invoke it as you'd normally invoke a method. It had to look like the LINE statement did in BASIC circa 70s:
form.Line (1, 1) - (100, 100), vbRed
But wait, it gets better. Say, you want to draw a filled rectangle. Well, a rectangle is also defined by two points, so BASIC has historically used the LINE statement for that as well, and VB follows suit:
form.Line (1, 1) - (100, 100), vbRed, BF
Note that you can have a variable named BF. And if you do something like, say:
form.Line (1, 1) - (100, 100), BF
Note that all of this is part of the language syntax, not the library. The actual function just takes a bunch of arguments, same as any other; but the language then piles all this useless syntactic syrup on top of that.
This is just one tiny corner of the language, and not even the most headache-inducing one - you hit it once, you read the manual, and mostly that's that. But then there's stuff like default properties and the Let/Set distinction:
Let x = y
Set x = y
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.
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?
...hopefully that quiets down the nonsense :)
I've seen .NET (and even C) programmers that after a year of coding using node still don't have a clue what the hell is happening.
Dynamic typing vs. Static typing doesn't make a language harder. If you prefer dynamic languages you are just a bit lazier and short sighted.
Async vs. Sync (specially the way node handles it) IS harder, though.
> If you prefer dynamic languages you are just a bit lazier and short sighted.
In theory, the only drawback of a statically typed language is the up front work required to make the compiler happy. In practice, you end up losing a lot of expressive power, and abstractions that were previously effortless now either add a lot of verbosity/complexity, or are simply impossible. Scala is the most expressive statically typed language I've seen, but even there you often have to jump through hoops to implement certain abstractions in a type safe way. The decision to use a dynamic language is not about laziness.
I can definitely see prototyping something in whatever language is convenient and after proving its usefulness rewrite it in a language that fits wider goals. Their motivation[1] seems pretty solid.
- 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://github.com/Azure/azure-cli/wiki/Motivation
The main issue for me is how Node.js is forcing you to have all I/O operations asynchronous. For what I'm doing, this is exactly what I don't need. It makes the code so much more complicated. It's callback into callback into callback and returning "promises" within "promises"... simple functions are turned into beasts. It works but it's obvious I'm not using the right tool for the job.
Don't get me wrong. I'm actually glad I dived into Node.js and learned a lot of new things. It's just that Node.js is very specialized framework which is amazing for certain use-cases and totally inappropriate for others.
On the other hand, Python is general-purpose. It's never the best tool for the job but it's almost always good enough. So once you know Python, you know you can use it in many diverse projects without giving up your sanity. Can't say the same about Node.js.
Not that I'm complaining. Love Python, dislike JS being everywhere.
Good ole' inveteracy. Unfortunately, it's really as good a reason as any when it comes to managing resources on a long-term project (people, time, $).
Always needs to be balanced against using the right tool for the job, even if that means the initial pain of carrying a codebase written in a "relatively" newer language. To be clear, both Python and JS (NodeJS) are great tools with excellent communities and ecosystems.
http://jugad2.blogspot.in/2013/01/some-google-command-line-t...
My IBM developerWorks tutorial on writing command line utilities (C) is not at that IBM link in post now (archived after 10 years), but can be found here:
http://jugad2.blogspot.in/2014/09/my-ibm-developerworks-arti...
https://azure.microsoft.com/en-us/blog/announcing-azure-cli-...
Also, I've had nothing but trouble with recent Node versions (and I'm a pyenv/rbenv/*env/etc. guy, have multiple runtimes of everything around, etc. - but most people would try once and never try again).
When I switched to Ruby dev-work though, my tools changed. I found myself writing a lot more scripts for things which I previously would have made a C# console app for, mostly because osx/linux make it a lot easier. Soon I started writing a little Python, and found I was just plain productive (things that might have taken me many hours would take minutes), and now it's becoming a primary language for me. I'm not sure I'd use it for the majority of my work, but it's probably my #2 language tool.
I could make a snarky comment about "you'll never go back" being correct, but I do make the occasional commit to a Python project. But honestly I'd rather deal with well-written PHP than well-written Python despite the fact that the Python language is -1 times better than PHP. Just the way my mind works.
I still love and use python quite often, but more in data analysis/manipulation projects with Jupyter - Node definitely doesn't have anything on python in that dept.
p.s., check out pandas if you're not already familiar with it.
If you need to visualize from Python without touching JS try http://bokeh.pydata.org/en/latest/
https://github.com/Azure/azure-sdk-for-go
Azure is mostly a lot of REST apis.
Why click? http://click.pocoo.org/dev/why/
http://imgur.com/gallery/MWcxIMA
Congrats!
Python built into Windows 10, Azure CLI in Python, Python Tools for Visual Studio, Azure Jupyter Notebooks, ... exciting times for Python devs on the msft stack!
I'm on 10 and I had to install it.. Am I missing something?
* I'm interested in seeing how they plan on handling keeping an 'evergreen' state on ubuntu repos that they don't control.
* jmespath! It's great to see it spread more! Such a useful spec.
* There's an awful lot of dependencies, 59 vs 10 in the aws cli.
* No windows installers?
* Does that server side completion cost money?
* With such a crazy file structure, it would be great to see a getting started guide for contributing.
* The readme should really list the supported python versions.
* It's hard to tell how much is code generated and how much is custom.
* Help text prints right to the shell without using a pager.
If you (or anyone else) has any feedback on places we can improve, we are happy to hear it (azfeedback [at] microsoft.com]).
Jason - Microsoft Azure CLI
But I am so curious to know how people who have worked with them find them? Which one is better ? What is advantage of each one?
I couldn't find any useful information in web either.
Update: I am familiar with basic stuff. But I am so curious about heavy load, for example why Spotify chose gcp or etc. Was there technical reason or it was preference.
(I work for Google Cloud and am happy to answer questions about GCP)
What was the reason behind these, personal preference? Or technical superiority?
The reason for my curiosity is Microsoft and Oracle kind of sees Cloud Computing as life and death situation.
gce has really nice apis but limited features and unless you do things like google you'll have to do a lot of your own integration work
i've never seriously used azure
Google Compute Engine alone has lots of nifty features that even AWS EC2 lacks, like custom VMs, generalized VM types (no need to go for specific instances to get fast networking, for example), preemptible VMs, live migration, disk hot-grow, and sustained use discounts, while generally being cheaper.
(work on GCP)
Amazon and Azure are going to be around for at least a decade.
Google Cloud is paid b2b, not free b2c - companies like Disney, Spotify, Evernote build very close multi-year relationships with Google, rely on Google, pay Google, etc. Google Cloud going away would shut down, for example, all of Snapchat.
(work at GCP)
With AWS, the ecosystem is massive. They also have the most features (though GCP and Azure have their own unique features and are catching up fast).
I haven't used Azure, can't really comment on it.
Disclosure: I'm an Azure Batch engineer.
azure-cli/src/azure-cli-core/azure/cli/core/
That's.... definitely not beautiful
Instead they could have created 17+ github repo's and had each part have it's own repo... instead it's now all contained in a single place.
Type annotations in py3 might change that, but lets be honest - py3 is still far from broad adoption.
This could be in haskell or F# and it still wouldn't matter because it's the CLI itself that matters. (to which the question must be: is Azure popular? Is a new version of the CLI utility big news?)
https://github.com/Azure/azure-cli/blob/master/scripts/dev_s...
EDIT:
Nah, only 3. So much for Microsoft and it's legendary backwards compatibility.
https://github.com/Azure/azure-cli/blob/master/scripts/gener...
Microsoft tends to build tools that are backward compatible with earlier versions of the same tools; it doesn't particularly tend to build tools that are compatible with outdated versions of the platforms they are implemented on top of, though.