This reminds me of companies rewriting applications from VB to c++/c#.
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'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.
You do realize that Python was not only built to appeal to "non-devs" as well ad devs but, does, in fact, enjoy some of its strongest support from them- scientists, engineers, statisticians, etc., who do not consider themselves to be good developers. And, man, they can develop some crappy code/systems in Python too.
I like Python too (as well as node,) but your characterization of node is over-broad and, imo, inaccurate.
> You do realize that Python was not only built to appeal to "non-devs"
... 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.
I'm surprised to see JS described as easier than Python. I'd say it's considerably harder and more complex. The first reason being that it forces you to think about asynchronosity constantly, and that's something a beginner's going to struggle with -- not just the idea that your code won't run in order, but that there are so many ways to deal with it (callbacks, promises, async/await, event emitters) all with their own tradeoffs. The second being that the standard library is anemic, so a ton of what you'd just hit the Python Stdlib for you have to either write yourself or sift through npm to find. Then there's the wildly varying code styles: this person/book encourages the traditional imperative style using loops and mutations, this other person encourages a functional style using folds and maps to do the same things. Prototype-based inheritance is less intuitive than class-based inheritance. There are multiple ways to do everything, even things as simple as variable assignment (var, let, const, implicit global, function foo() vs let foo = function() vs const foo = () =>), weird invisible things that trip you up like hoisting and how creating a global variable looks exactly the same as reassigning an existing local variable. New users will inevitably encounter the multiple competing module systems and either confuse syntax or fret about which to use.
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.
You are absolutely correct. JavaScript is by no means as easy for a beginner than Python. Once you get beyond the most basic of programs , JavaScript starts throwing a lot of crazy concepts at you like prototypical inheritance,hoisting, and this (and I'm only counting es5)
Don't confuse Node with Javascript. Node and the browser are where all the async behavior comes from, not JS. Specifically; if you've ever done any backend coding in Meteor, there is practically no async behavior at all.
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 agree completely, but doubt I could have put it as eloquently as you did.
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
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 < 100; ++i) {
foo().then(function() { bar(i); });
}
Then when they realize why this doesn't work, try something like:
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); });
}
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. 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.
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`.
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.
"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 don't remember it, but I wouldn't doubt it. Certainly, both Guido and Larry have made tongue-in-cheek comments about Perl and Python and the (good-natured) competition for mind share. And, features have been borrowed in both directions, and many developers have gone back and forth (I certainly have multiple times across a couple of decades).
>> 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.
>>> "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)
"x is cancer" is cancer. These sorts of hyperbolic generalizations lower the level of discourse. You haven't actually given any reason for your opinion.
So you're saying bower is cancer? Webpack is cancer? Babel is cancer ? JavaScript module system made popular by nodejs is cancer? I largely prefer Python as a language but Nodejs is the best thing that happened to web development in years/ever
> So you're saying bower is cancer? Webpack is cancer? Babel is cancer ? JavaScript module system made popular by nodejs is cancer?
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).
I'm not convinced it's that they aren't just more layers of cruft piled on top of a shoddy foundation. One of these days the whole thing is going to subside into the morass, and maybe we'll get to start over on top of WebAssembly or whatever comes after that.
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.
Hurray, here we go again! Uhh no, JavaScript is just fine, baring:
* 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)
What I'm saying is that JS actually has a small amount of quirks compared to other dynamic languages. Just think about PHP's named functions, which are always in the global scope. Except when they are in namespaces (oh hi another concept), and then its kinda weird because namespaces are relative. There are no first class named functions, but function expressions can be assigned to variables. Which must be prefixed with $. There are no real modules, or proper scope; JS in turn implements modules cleanly on top of closures with lexical scope and objects.
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.
"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
Can't answer for webdev, but for anything else, python and c++ with some mature library packs (boost, qt, eigen, scipy etc). They are not 'dated' in that tey don't have any expiration date. As N.Taleb points out in Antifragile, the best predictor of an idea's remaining lifetime is its current lifetime.
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.
Python is outstanding for nearly every purpose I've thrown at it, and I was a strong Java developer. Now if anyone asks me if they should learn R/Matlab/Java/C, I say "Sure, but learn Python first."
I've recently completed a project of moderate complexity. I began development on Python 3 in a Jessie vm, and later ported to and deployed on Python 2.6 on CentOS 6.
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.
Python 3 for all intents and purposes, unless you're in a field where Python 2 is still prolific (but if you are, then you probably already know that).
Python was built to be simple, yes. But it was built by people who understood that simplicity means things like "explicit is better than implicit" and "there should be one - and preferably only one - obvious way to do it". So it's a language that takes an inexperienced coder, and makes things easy for them, while also gently guiding them towards the safer (if possibly longer) path.
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 agree with most of what you said, but this is a bit naive:
> 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.
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.
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 ...
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.
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.
As someone who does a ton of Node/JS coding as well as some Python, I am personally offended! Ok, not really, but I think you're wrong :)
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.
> Both PHP and Javascript are much more complex from a language design standpoint
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 ...
> 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.
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.
>> 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'.
They're both sequential by default and lack threading, and that's hard to mess up. They're both great languages for easy projects.
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.
>> A good engineer can write high quality code in "almost" any programming language. It's the coder, not the language, that determines engineering quality.
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.
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.
I think they differ in that PHP is copypasta and Javascript is an infinite dependency tree of third party libraries that the developer has no idea (or care) of their inner workings.
VB is also an incredibly complex language, especially the pre-.NET versions.
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
Note that parentheses here are not some kind of tuple syntax. Instead, they're a part of the special Line syntax, as well as the dash between. On the other hand, vbRed is just a named constant.
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
Unlike vbRed, BF here is not a variable name - it's more special syntax. "B" stands for "block", and "F" stands for "fill" (so you can do "B" without "F").
Note that you can have a variable named BF. And if you do something like, say:
form.Line (1, 1) - (100, 100), BF
That is legal, and uses the value of that variable as the color of the line (instead of drawing a rectangle, as you might have expected). And it'll probably work, too, regardless of the type of "BF", because VB tries incredibly hard to implicitly convert something to something else when types don't match.
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
In VB, these two statements are both assignments, but what they assign to is different. And you actually have to know and understand the difference, because there isn't just one assignment syntax that does the right thing for everything - some types only work with Let, and some types must be assigned with Set to get what you want.
>> but by the same token, invited entire (and continuing) mountains of half-assed, unsupported(unsupportable) code that just begets generations of garbage.
Isn't it possible to say this for just about every programming language?
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.
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
Oh boy did you miss something in the 90s! It was call active pages (or some bullshit, I have tried to block it from my memory) and it made Internet Explorer the king of browsers and still locks in a lot of government agencies and business from upgrading their infrastructure, because they don't want to lose or have to pay to redevelop "critical" applications to their daily work.
ASP was programmed using VBScript (and actually extensible - it used Active Scripting, so you could also do JS, and third parties added support for e.g. Perl). And, since it was server-side tech, and very low-level at that, it didn't care what browser rendered the output.
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.
Meh. Microsoft built a text editor with it and only because it was the simplest choice to have finally a os-independent editor (maybe now they would have go for .net core if they had a good cross-ui library). Facebook and Google had to use it because you are talking about framework for the web, and sadly our browsers support directly only javascript as scripting language... they have not chosen it, they were forced to use it.
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.
Funny enough, I use Python primarily, but when it comes to deploying small standalone tools I have a list of things I want to rewrite into something like Go so I don't have to deal with dependencies. In my little experience with Node it seems even worse. One petty but relevant fact is that Node isn't installed by default while Python generally is.
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.
Well, the entire premise was "your script-kiddie GUI code, but on server!". Microsoft on the other hand is just chasing the ball (Node/Python) or where it will roll (TypeScript, C#).
I'm currently starting one project on Node.js and just this morning I thought to myself. This is too hard. I might as well rewrite it in Python.
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.
There's a mention of it in the "Motivation" page on the GitHub wiki. Basically the big thing seems to be the feedback from Linux users that most distributions bundle Python but not Node. Also that AWS and Google CLI tools are still more Python than Node.
I am the author of the Motivation page; the choice of language was really focused on what's best for partners and customers; I believe either language could have "done the job".
> Basically (..) most distributions bundle Python but not Node. Also that AWS and Google CLI tools are still more Python than Node.
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.
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:
I think a part of it must be that writing synchronous code in NodeJS is nowhere near as elegant as in Python. We started writing some tooling in NodeJS (for dealing with REST API's in particular, posting and receiving JSON, which is native to JavaScript so should be perfect), but ended up reverting to Python mainly for this reason.
One advantage of using a dynamic language like Python is that you don't necessarily have to update the client code to be able to use new functions. You can just generate the necessary code during runtime after loading the specification from a web API. I believe this is what google does with their gcloud tools (and that's probably also the reason why it sometimes feels slow to react).
Yes, you can probably do this using Node as well, but Python comes installed on a lot of Unix based systems nowadays, as far as I can tell Node does not.
Yeah, absolutely no reason you couldn't do this (quickly) with Node. The only reason I see to use Python over Node here is for a smaller dep tree (sane Node development still requires a lot of dependencies) and some more mature CLI libraries - lots of CLI apps are written in Python.
"have also heard, especially from customers working with Linux, about our XPlat CLI and its poor integration with popular Linux command-line tools as well as difficulties with installing and maintaining the Node environment"
Yep. This. I know it's not cool to point this out and that front-end folks upgrade Node all the time, but installing Node on a "normal" machine inside your average IT environment is a complete pain, whereas you can do pip install azure-cli as a regular user without installing anything else on most Linux distros out of the box.
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).
Python is the language that, once you know it, you'll never go back. It's gotten to the point where I use it to run an entire backend as well as simple terminal scripts. It's faster to write a Python script to "switch the first and third columns in a file", rather than Googling for an appropriate awk command (or spending the time to come up with one myself).
Funny. I know it, and still hate it. For every opinion that is held universally true, there is at least one person (but far more likely, many people) for whom that opinion is demonstrably false.
I've been primarily a C# programmer for the majority of my career, with probably equal parts dabbling in Ruby, PHP, Javascript, Sql (large sprawling analytics framework sql), and a bit of R.
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.
Python is a great language, but just not one that suits my mode of thinking. I learned Perl first, spent my time in college learning Python, C, Javascript, and FORTRAN 90 (at least the code that had been updated from F77), and eventually went back to Perl as I liked it the best.
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 know python fairly well, and had previously done most web development with flask or django. I had to learn JS so that I could do front end web dev, things like D3 and such for visualizations of data. I tried out a few of the frameworks that I came across for back-end web dev as well, things like Koa, knex, passport, etc - and I have to say that these days I start far more projects as JS/Node.JS projects than I do python.
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.
While I agree with the sentiment, I do still love the concise format of awk commands. Although arguably, they can get rather confusing when trying to do complex stuff.
I wish they had used GO. If you worry about distribution and dependencies, GO static binaries are clear winner. One issue with GO binaries is that they can become very big.
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!
One feature I'm loving in the new Azure CLI is a new command (`az ad sp create-for-rbac`) that will create a new Service Principal and grant it a RBAC Role assignment in a single shot. It should make the first step of setting up CI/CD scenarios a bit easier.
I haven't used the new Azure cli, but a major issue with the node.js based cli was that it was heavily oriented towards interactive use and not well suited for use by scripts. Hard to parse output, prompt for parameters instead of accepting them on the command line, etc.
Was the submission edited?? The point I wanted to make was about the choice of language, rather then the announcement of the new tools. It's kind of rude TBH...
Personally I don't have any experience with working with neither of AWS,Azure,GCP,etc.
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.
Thank you , but what I meant was in heavy work load. I know the basic ideas. But I am curious in heavy work load which one is preferred for what. AFAIK Spotify went with GCP, many big companies went with azure, most startups chose AWS.
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.
People generally say Azure suits the enterprise, AWS suits tech-driven companies (i.e. those where the CEO knows what an API is), and Google supports special/hobby projects. Google is probably awesome but nobody trusts them to not just abandon the whole thing in a few years time.
Amazon and Azure are going to be around for at least a decade.
Google is not going to abandon cloud. I'm not sure anything I say can convince you, but the fact the Spotify, Evernote, Disney, Home Depot, Snapchat, etc all run on GCP says a lot.
Google doesn't have a good track record supporting its products. I have no doubt that GCloud will stick around, but the fact remains that Google has trust problems.
This comes up sometimes, and is really not well supported. Happy to discuss every time it does come up :)
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.
I understand that, which is why I don't worry about the future of GCP. However, the negative perception gained from some of those free b2c endeavors will still damage the reputation of unrelated Google products and services like GCP.
I'd say with GCP, the managed services are key. Pub/Sub, Global Load Balancing, Firebase, BigQuery, Container Engine, etc. They just work, no need to mess with things. Price to Performance and simplicity is also good, but that's secondary IMO. I'm obviously biased, but hey!
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'm genuinely curious on what limitations you've seen with Google's Cloud.
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.
Just to complete your comparison, Azure has some great MS-based PaaS offerings (e.g. hosted DB, hosted IIS, etc) and great integration with MS environments, but I find their interfaces (API and portal) more clunky than AWS.
Completely agree with this. Since each one is a massive group of product offerings, it is really difficult to evaluate each on the whole. Your experience is directly tied to your use case.
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.
You can do this on AWS EC2 with MIT StarCluster; it's got an MPICH2 plugin. StarCluster is pretty great although development has stalled a bit. I haven't used it for MPI-type workflows, but I have done a lot of embarassingly parallel modeling on tens of EC2 instances, and it works pretty well.
the src directories, and command_modules directory inside of that all contain separate Python projects. This allows them for instance to make changes/updates to particular parts of the azure-cli but without releasing a new version for each small sub-part.
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.
Can someone please explain why the fact that it was in Node and is now in Python matters in the slightest, given that it's a command line utility that doesn't seem to, in any way, expose the language it is written in?
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?)
Are you not interested in why they rewrote it and what made them choose Python? Did they have a problem with it in JS that JS could not solve? Lots of interesting questions here.
Personally I find it interesting observing technology choices of large projects, thinking about if I started something similar, what should I choose...
> Nah, only 3. So much for Microsoft and it's legendary backwards compatibility.
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.
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...)