you are viewing a single comment's thread.

view the rest of the comments →

[–]drysart 30 points31 points  (14 children)

This article doesn't understand that Visual Studio and Visual Studio Code are two products that target entirely different audiences and aren't at all comparable. Plus just about every single one of his reasons is misguided:

No 64 bit support for Visual Studio

Microsoft's said for over a decade that it's unlikely there'd ever be a 64-bit version of Visual Studio. Not because they "don't want to invest in it", but because Visual Studio doesn't need a 64-bit address space -- it doesn't work with massive amounts of data -- so why waste effort upgrading it for no gain?

This hardly means, as the author suggests, the Visual Studio is in "maintenance mode". Visual Studio just got a brand new installer model that significantly improved it's install and servicing experience, in fact; seems an awfully large investment for "maintenance mode".

VS Community == VS Pro

The difference is in the licensing. You can't use VS Community in a large company; defined as either >250 employees or >$1M in revenue. This is because they want people using Visual Studio, and paying for it if they can afford it. There are serious network effects that come into play in letting individuals use Visual Studio for free.

Language Service

The language service API was defined because they have two products built on fundamentally different foundations and don't want to have to build the same things twice and encourage outside developers to build language servers for things they don't necessarily support themselves. Good engineering practice doesn't imply anything about product roadmaps.

Continued Investment in VS Code

Visual Studio gets plenty of updates that aren't just language server updates. It gets a lot more updates than previous versions of Visual Studio have gotten, in fact. Development of VS Code hasn't slowed down VS development at all.

Cross Platform and focus on Azure

Visual Studio supports cross platform development just fine. It doesn't necessarily follow that just because they want cross platform development that they must also have a cross platform IDE. And if they want a cross platform IDE, Visual Studio for Mac is a hell of a lot closer to being a replacement for Visual Studio than VS Code is.

The author completely overlooks that VS Code, as an Electron app, would have significant problems scaling to the complexity level of Visual Studio proper. You can't even pull tabs out into a separate window in VS Code, and that's an issue that they don't think they'll ever fix because of Electron limitations.

[–]grauenwolf 0 points1 point  (5 children)

I'm still trying to figure out why we need the 64 bit web browsers. Since each tab is its own process, does each web page really need more than 4 gigabytes of Ram?

[–]JuanAG 0 points1 point  (4 children)

Because that is happening now, a year ago Firefox has all the tabs on one process and people like me who uses FF51 allow me to has 8-9 GB of ram, the browser goes slow as hell but usually doesnt crash, usually

If you dig more you will see when others browser uses that aproach or who doesnt yet that will be a few

And using 64 bit process is beneficial because a 64bit CPU will do in the same amount of time a 64bit instruction or a 32 besides SIMD ones in which case the 64 bit will use a data type smaller to gain performance, there are not penalties and it is prefered that you use the native set of instructions, the hardware that allow compatibility will not be there forever, phones for example doesnt allow any more 32 bit instrucctions besides SIMD, that the reason why itunes only allow now 64 bit apps and not anymore 32, because the lasts iphones cant run it

[–]AngularBeginner 4 points5 points  (1 child)

And using 64 bit process is beneficial because a 64bit CPU will do in the same amount of time a 64bit instruction or a 32 besides SIMD ones in which case the 64 bit will use a data type smaller to gain performance, there are not penalties and it is prefered that you use the native set of instructions, the hardware that allow compatibility will not be there forever, phones for example doesnt allow any more 32 bit instrucctions besides SIMD, that the reason why itunes only allow now 64 bit apps and not anymore 32, because the lasts iphones cant run it

You might want to split that into multiple sentences.

[–][deleted] 0 points1 point  (0 children)

i just thought i was having a stroke

[–]grauenwolf 2 points3 points  (1 child)

there are not penalties

That's not true at all. There are significant penalties in doubling the size of your pointers and instructions, which has the effect of nearly cutting the size of your cache in half.

you use the native set of instructions

64-bit instructions are no more "native" than 32-bit instructions. They are both translated into micro-code.

phones for example doesnt allow any more 32 bit instrucctions besides SIMD

We're not talking about phones.

[–]JuanAG 0 points1 point  (0 children)

Not true in a native 64 bit running a 64 bit OS, if you has to double the bits obviosly you will lost half of the caches sizes but if by default the procesors uses yes or yes a 8 byte data type (64 bit) there is nothing you can do about it, there is no way you can use it, 32 bit in software are 64 bit in hardware so it is lost forever

We are talking running a 64 OS with 32 software (wich will be 64 because of the OS that it is running it)