Python support in Visual Studio 2017 | Hacker News Reader

Python support in Visual Studio 2017

blogs.msdn.microsoft.com

Official support for Python, Node, and Docker in Visual Studio. Full Linux shell on Windows. You know how almost every developer has a Macbook? I think that might change.

I am also on Windows, Total Commander and Visual Studio Code are my main tools. What is a general experience with Linux shell? I don't have it since I am on Win8, but isn't it still better to use VirtualBox?

Yep Virtualbox is still the way to go. I actually run it the other way around at work, Linux on my host and Windows guest. Seems to work pretty well. I doubt Linux shell on Windows will ever be that good until Microsoft makes a new file system (or adopts an existing Linux based one, although that's unlikely given differences in how the two OS's do permissions and such).

Personally I think you only should use Virtualbox if you're using Linux apps with a GUI. For every other situation WSL has less overhead (no, I don't have a citation for that) is far easier to start (literally just type "bash" in any shell) and interops better with your existing filesystem (cd /mnt/c/ and you can access everything on your C:/ drive, it's that simple).

>WSL has less overhead

In my experience, Linux in Virtualbox is a lot faster then WSL. I'm not talking barely noticeable here, I'm talking operations taking 0.2 seconds vs 10-15 seconds (on an SSD) in the worst case. It's literally faster for me to do shit in Linux and rsync it back to Windows than it is for me to deal with WSL at this point. The only overhead is memory and CPU, of which I have plenty. I don't have plenty of time.

>far easier to start

I just keep my Linux virtual machine open, so it's just an alt-tab away. At work, I run it the other way around (Windows as the virtual machine). It's basically the same story.

The bottleneck is file system as far as I remember. I can compile my a linux kernel in VM with static file system in reasonable time. But try to do it in WSL, the file system overhead makes it miserable (Make and Configure open and close file extensively). other than that, ordinary computation is almost same as Desktop Linux (better than VM).

There was a benchmark on http://phoronix.com which proves my point.

Oh I get that, I mentioned the file system being the culprit elsewhere in the thread. Doesn't really change the point regardless, the gist of the matter is that until Windows fixes its filesystem it's much more efficient for me to run it in a VM than to use WSL.

Allow me to hijack this thread with a question to a wider audience: Has anyone managed to run a VM with Linux on a Windows host that has acceptable performance?

My previous attempt a while ago to run Linux on a Win7 host via Virtualbox was unsatisfactory because the performance of Linux's GUI was very slow I tried to run PyCharm but it was painfully slow with noticeable lag.

I've never had performance issues with Linux in a VM. Barely slower than running it dual booted. I mean, I run light WMs (originally AwesomeWM, but the past year or two I've been using xmonad). But I don't remember the interface being slow when using, say, Gnome 3.

The only things I can think of that might be special about my setup is that I generally: 1. Run the VM off of a different physical disk than the host OS (only necessary if you're using HDDs) 2. Allocate generous amounts of RAM (4-8gb) even though very little RAM is required. 3. Use machines that have 4+ cores.

Disagree. Not in the near term anyway. Windows docker support is sketchy at best, Linux shell is slow (due to things like the file system) and a lot of python/node developers don't feel the need to use an IDE. Don't get me wrong, I use Windows as my primary OS and I'm a Microsoft fan (love my Surface Pro 4) but I don't see the immediate pull here. I certainly won't be using Windows on my work PC.

Microsoft's definitely doing the right things these past few years so I'm definitely excited for the future. I suspect the we'll see more people adopt .NET before we see Mac/Linux though.

Before you throw away your MacBook, also consider that a lot of the 'ecosystem', e.g. the way you install libraries such as NLTK have a 1 step process for installation on Mac/Linux and a may-or-may-not-work multistep process for Windows, with sometimes sheepish apologies from maintainers of said libraries that sometimes they simply couldn't get it working and couldn't afford to waste any more time on it.

Example: http://www.pitt.edu/~naraehan/python2/faq.html Read the question "How do I install NLTK 3.0 (Windows)?"

Or you could just use anaconda and type 'conda install nltk'.

edit: most of the steps in the instructions you linked to are how to install pip, which is now included if you install the latest version of python. So on a current version of python the instructions should reduce to run:

   pip install pyyaml nltk

You are reinforcing my point in a way.

If you look at the nltk site's docs on installing on Windows [1], you see there isn't even any mention of anaconda. In fact, there is basically a set of links asking you to go and figure it out for yourself. Either the maintainers of the NLTK project are not aware that there is a better way (using anaconda like you suggest) or they are aware but haven't seen any good reason to update their documentation.

So why do they (and broadly the 'ecosystem') not update their docs to be more Windows friendly, or to even develop their software so as to be pain free to install on Windows in the first place?

That is the ecosystem effect at play here. How many people are likely to stumble on to your comment when they search "install nltk on windows"? On second thoughts, with my double quotes and all, now they might :-)

[1] http://www.nltk.org/install.html

Yea, I suppose I cannot really deny that using python on windows is occasionally very slightly harder than on Linux. And many developers are ignorant of windows and don't write good/any windows documentation. But by the same token it has gotten dramatically better over the past couple of years, and there are now people within Microsoft actually working on improving the Python on Windows experience.

Its not just windows is getting better, but also macos getting worst every release

It is pretty OK for those of us that don't care about UNIX and POSIX.

I am quite happy just with XCode, Swift, Objective-C and OS X Frameworks.

That's interesting, as Windows developers have always been very happy with just Visual Studio, C# and WinForms, and now Windows is becoming less horrible for people used to POSIX.

It does look a bit like Apple and Microsoft are on a road to switching their attitudes and roles. Who knows.

Yes, my Windows experience goes back to Windows 3.1 and I think Windows NT architecture is quite good versus traditional UNIX ones, specially when one bothers to read all relevant documentation like the Windows Internals book series.

Lack of POSIX support only bothers me when trying to compile software targeted to pure UNIX systems.

Can someone explain to me what Linux shell has over powershell that makes it so indispensable for developers? I'm a developer and I don't use Linux. I'm dual booting Ubuntu at the moment because I want to get more familiar with Linux, but I can't see how terminal/bash is so much better?

I can't speak for everyone, but for me a lot of the unix-y utilities and commands tend to do 99% of what I need with a couple of keystrokes and are very composable through piping/redirection. It's possible that equivalents exist on powershell but I feel like they're verbose and hard-to-remember or perhaps just plain different from what I'm used to working with for the last decade or so on OS X/Linux. For example if you need to access an environment variable like Path - on Bash you just use $PATH the same way you have forever. On powershell it's $Env:Path - maybe this makes more sense ("in the current execution environment, access the Path variable") but I had to google it to check and my first instinct was "oh it's something like %PATH% I think..." - which is the old windows cmd.exe way.

So maybe the biggest "pro" for the traditional linux command line way is "inertia" - but I'm sure someone else has a much more satisfying answer than mine

If you want to quickly check that your code works on a Linux server, the windows subsystem for linux is quick way to do this without spawning a VM.

That does not replace continuous integration on a real Linux host but that might be a good way to do interactive development and debugging of cross-platform code directly on windows.

> the windows subsystem for linux

Which windows versions are we talking? Do they all have equally good support or are previous (Most people are still using Win7) versions crippled in some way?

the windows subsystem is limited to the latest version of windows 10.

actually - scratch that: its limited to the now coming version of windows 10. there are (to my knowledge) no plans to ever port it to any other system. this was stated in one of the earliest interviews about it iirc

First stable release of WSL was the Windows 10 Anniversary Update, which has been both the Current Branch and Current Branch for Business, since back in November. (The Creators Update out soon includes updates/enhancements/fixes to it.)

It is not expected to be back-ported to Windows 7. (Why would it be?)

Honestly, in my opinion not a lot, except many people have years of experience in unix shell, and many programs you will download will have unix shell scripts, but not powershell.

On the other hand, remember on the scale of computing, powershell is fairly recent. We used to have batch files and the 'cmd' shell, and they were fairly awful.

The main reason I use bash instead of PowerShell on Windows is autocomplete for git [1].

[1]: https://github.com/git/git/blob/master/contrib/completion/gi...

Not much, other than UNIX kind of workflows.

I use Microsoft products since MS-DOS 3.3 and my path into UNIX was via Xenix and DG/UX, before GNU/Linux was a thing.

Being a developer doesn't mean using UNIX, rather producing software with whatever tools our employer uses for producing business value.

Powershell is much better concept for a CLI, taken from Lisp and Smalltalk REPLs than a pure UNIX shell.

IMHO powershell resembles more smalltalk than lisp.

Trying to write powershell scripts without the ISE (Interactive Scripting Environment) is very hard.

Also powershell is not suitable to just open and "bash" thigs out at it. For example to download a file, you need to remember the corresponding .net package. Or to list a directory, you use -without the alias- get-child-item etc.

I think the verb+noun syntax and the ability to use all .net packages are awesome. But you first need to do your research, find the modules, look up the required parameters, put those in a file etc.

In bash, most linux users just "bash" things out, if you don't know something no problem, you just "man" that.

Although the same thing could potentially established with powershell through aliases and extra binaries/scripts for utilities like diff/curl, powershell in its nature is a different beast.

I really like powershell, writing scripts with the ISE and the object oriented design are really powerful. That's why I think powershell resembles smalltalk rather than lisp.

In order to write powershell comfortably and efficiently you need to use its development environment with GUI.

I agree with you, just I don't get " powershell resembles more smalltalk than lisp." part.

While FOSS Lisp environments are pretty bare bones text CLIs, that is not how Lisp should like since Xerox PARC, TI and Genera days.

Sadly Lisp IDEs are all commercial, but the experience is pretty much Smalltalk like, or even better, given that they also AOT to native code.

I was never aware of the existence of a Lisp implementation with an IDE.

Now I see that there is. The two lisp books I read (Paul Graham's ANSI Common Lisp and gigamonkey - Practical commmon lisp) always used text editors.

Whereas for smalltalk I installed a VM (scratch) that included a GUI.

And also even in an old issue(80s?) of Byte magazine dedicated to smalltalk there were extensive toolings with GUI. https://news.ycombinator.com/item?id=7052479

"By resembling smalltalk" I wanted to mean that the user needs to interact with a development environment to get the full benefits of powershell. And that this is in its nature.

Nevertheless, I stand corrected. I never knew that there were lisp implementations designed to work with an IDE.

You never heard of Lisp Machines or Mac Common Lisp?

Lisp stop being based on text mode environments in the late 70's, when it moved out of mainframes into systems with graphical displays.

Many of the Smalltalk ideas were inspired from Interlisp-D, the Lisp workstations used at Xerox PARC.

Text mode environments for Lisp is a GNU/Linux thing.

If you wish I can provide some links.

I had heard of lisp machines as a term, but none of the others mentioned in your comment.

Thanks for pointing out, I'll do some research on this topic.

If you have links easily accesible to you, I'd appreciate them, if not no problem at all.

>In order to write powershell comfortably and efficiently you need to use its development environment with GUI.

Which really makes it a questionable choice as a scripting language, IMO, and I say this as a fan.

Amen.

Or as said on Quora some time ago: "A fool with a tool is still a fool."

It's 2017 and we're still distracted by obcessing over tools, and neglecting the real goal. That is results.

NO One uses a product because of the tools (the fools?) used to build it.

It's the same shell that runs on your server and the same shell the developers of all the open source tools you might want to use use. Powershell is pretty neat, but bash just has more momentum.

Bash (de facto standard Linux shell) itself is quirky enough to not have any significant advantage over powershell, however, standard GNU utilities have huge momentum with them. Too many tools are built over standard utilities glued together with shell scripts that replacing environment expectations in higher level tools is next to impossible.

In my view powershell was not designed as a shell, but more like programming tool specific for Windows administration with a REPL. Powershell looks designed for .NET programmers intending to write small administration scripts and occasionally drop to interactive shell. Bash and other Linux shells are designed for interactive use with programming features bolted on. All this makes bash much better alternative for glue between various tooling, exactly what a developer needs

Not until Windows HiDPI support stops being a disaster.

Yes, they really have to do something with this. I was surprised how bad it was when I got my XPS15. You can increase the DPI levels and on the surface it looks fine, until some dialog opens and is the size of a stamp.

Where is the disaster? I run Windows 10 on a 4K monitor all day long and I see no disaster...

> You know how almost every developer has a Macbook?

*web developer

I don't know to many good systems engineers or security/forensics people who don't use Linux.

And embedded is mostly on Windows.

Define 'embedded'.

Most embedded stuff I work on has less than 100kb memory. No way in hell it could run an OS.

But if you meant programming the devices... So many vendors compile chains simply don't work on Windows and are badly hacked up versions of gcc.

Yes, I was referring to the development platform: the platform which runs the tooling for development, cross compilation, downloading, debugging etc..

In my experience the decent vendor provided setups that actually work are all on Windows. STMCube and Keil for ST, Atmel Studio, Code Composer Studio for TI.

Yes you can absolutely compile on *Nix using GCC, but none of the vendors target their tooling for anything other than Windows.

> none of the vendors target their tooling for anything other than Windows.

Atmel [0] absolutely does.

ST [1] does.

TI [2] does.

You want to run that one by me again?

[0] http://www.atmel.com/tools/atmelavrtoolchainforlinux.aspx

[1] http://www.st.com/en/development-tools/stm32cubemx.html

[2] http://www.ti.com/tool/LINUXEZSDK-SITARA

Atmel provides their compilers, not their tooling.

I didn't know that ST provided STMCube for other platforms. That's the project generation tool (which is great), it's not the IDE debugging system you get with Keil (which is also great).

You've linked the 'lite' TI toolkit. CCS is available on Linux, but is even less reliable than CCS on Windows.

I'm not trying to argue that all development is done on Windows, or that it's even the best platform to do it on. I am merely pointing out that Windows is the first platform that is targeted for development by the big vendors. Also (more anecdotally) the majority of the companies that I work with and encounter do their embedded development on Windows, until you get to the size of part that is running some form of Linux.

While tooling can be better on Windows, and many do target it first, I took issue with the claim that no one targets anything but Windows.

Anecdotally, I just had Atmel recommend a switch from Windows to Linux, as their compiler toolchain "can work better there".

This space is more diverse than just Windows, and growing in that direction more and more. Atmel, Cadence and Qualcomm are just a few who welcome you with open arms.

I know plenty who do, having worked in the Antivirus industry and I know people reverse engineering Windows software using Windows as their platform.

Sigh. I do. Why? No IT department would allow us to use Linux, since they didn't understand it.

This is across three separate startups and companies. It's infuriating.

> You know how almost every developer has a Macbook?

...in Silicon Valley bubble?

Thanks for the info mate !!!!

Reply on news.ycombinator.com