Live data from Hacker News

Visual Studio Code 1.9

code.visualstudio.com

281–290 of 312 posts

Re: Visual Studio Code 1.9

#281
post #87

Earlier quoted context omitted.

How do you like working with Go? I've been meaning to start trying it out here soon, but haven't looked very far. I'm coming from a C# background.

I come from C#. Golang is nice and simple. I really miss generics. Going from the expressiveness of C# to golang is hard at first.

If you come from a C# background, it will feel a bit weird initially. You will more than likely miss generics, you might also miss the strong OOP model.

In the compiled world, I have somewhat of a background in C (haven't really done much with it in the last few years, though), so to me Go feels sort of like "C with a really strong std lib". I have really enjoyed the decisions they have made with the language, tbh, the people behind it have a proven track record. It's fun and very powerful, there is tremendous potential in it.

I miss all the libs available in C, but this is understandable due to the early age of the project. I also feel like it needs better package management (but I read that is a priority for this year).

Re: Visual Studio Code 1.9

#282

Earlier quoted context omitted.

I've been dabbling with PS (using it as my primary console) but my workflow just isn't that complex, so I don't have a compelling reason to write cmdlets (yet!). Can you recommend a good tutorial?

I've used MSDN docs but I wouldn't call that a tutorial :)

The msdn docs are great, it's just difficult to navigate them. Perhaps this would help? https://msdn.microsoft.com/en-us/library/dd878294(v=vs.85).a... There's tutorials in there as well, but I didn't find them very useful compared to the overview/concepts documentation.

Re: Visual Studio Code 1.9

#283
post #282

Earlier quoted context omitted.

I've used MSDN docs but I wouldn't call that a tutorial :)

The msdn docs are great, it's just difficult to navigate them. Perhaps this would help? https://msdn.microsoft.com/en-us/library/dd878294(v=vs.85).a... There's tutorials in there as well, but I didn't find them very useful compared to the overview/concepts documentation.

Yeah that's what I went trough as well but usually tutorials are shorter and more to the point, this is more reference/in-depth style - I'm guessing OP was looking for something along those lines.

Re: Visual Studio Code 1.9

#284
post #19

Earlier quoted context omitted.

I come from WebStorm, Sublime and Atom. Atom and WebStorm felt rather clunky. Sublime was super fast, but somehow lacked behind in new features. VSCode is a revelation for me :)

whenever I try Webstorm, my laptop starts sounding like an Airbus A380. What makes VSCode different from Atom though is, VScode uses Monaco which is significantly better and also the start up is faster with VSCode.

Yep exactly my experience with Android Studio, to the point I started enjoying Eclipse again.

Re: Visual Studio Code 1.9

#285
post #228

I have used vim for years and I was tasked with making an Electron app for a client so I tried vscode... And I love it! I still use vim for sysadmin things but it has been the first thing Microsoft has made since the original Natural Keyboard that I absolutely love. It is good. I recommend it to others. I hate bloated editors and it is good... No config/setup process either - the defaults are enough!

I'm very curious: Don't you miss Vim? After using it for years, doesn't editing code in anything else feel wrong?

I'm all day switching between VSCode and Vim. VSCode's support for my toolset (nodejs, es6, jsx, flowtype, mustachejs...) is fantastic, but even with the (fairly good) Vim plugin, I miss Vim. Whenever something doesn't work in Vimified-VSCode as I expect, it breaks my brain and my focus a bit.

What's so great in VSCode that you abandoned something that, I imagine, was embedded in your head already?

Re: Visual Studio Code 1.9

#286

This is an off topic, but I just learned from the article that PowerShell will soon be the default in place of cmd.exe in Windows 10. I welcome this change as I found the experience of using PS was superior to that of bash/zsh in general cases. But I hope they figured out the performance problem. As of writing, in the stable version of Windows 10, PS is perceptually slower than cmd, so I was forced to use PS only whe…

PowerShell needs the .Net runtime so I doubt it will ever be on a par with cmd.exe.

cmd.exe has a limited set of builtin and relies on external applications with a plain text interface.

PowerShell has builtins, can import code from any .NET Assembly or native code DLL, invoke external processes, full featured programming language and structured data.

cmd.exe will never be on par with PowerShell.

Re: Visual Studio Code 1.9

#287
I'm critical of Microsoft and everything related to it, but I'm impressed with the whole VS Code project.

The team makes very sane development decisions. Code offers a great UI, is fast and configurable. Bugs and issues are handled quickly and despite already having overtaken all other editors IMHO, there's a constant stream of improvements that are documented nicely with every update.

Good job.

Re: Visual Studio Code 1.9

#288

I am surprised at the amount of semi-negative comments here. Yes, some features are yet to be implemented, (it's still a fairly young project and you can always follow GitHub issues on progress), but for an Electron app, it's surprisingly fast and capable. The Microsoft-developed Go plugin makes it the best Go IDE out there, the devs, (Ramya Rao etc.) are super responsive and really trying to resolve issues quickly.…

> makes it the best Go IDE out there I will respectfully disagree and say that gogland (while still in a pre-release state) is much much better.

In what way is it better? Go in VSC is very, very nice. I can't think of any tooling I don't have available with this setup.

Re: Visual Studio Code 1.9

#289
post #125

Earlier quoted context omitted.

> the experience of using PS was superior to that of bash As a Linux dweller, I'm genuinely curious about this one. I've found PS inferior in just about any use case.

I had been a full-time Linux (desktop) user for more than 10 years, and only recently made a transition to Windows. As I'm nowhere proficient at using PowerShell I might be overrating it a bit, as the grass is always greener on the other side. Anyways, what I found to be satisfying while using PS were: 1. The input/output is done using objects. I know that "inter-process communication should be done with text" is the…

i agree with the fact that PS object oriented communication between commands is much better then text. But I disagree about your point (2) saying that command names are more discoverable. with linux style conventions, there is a hierarchy that helps you navigate between command's features. for example `docker image ls` you can type docker, see that there is an images subtree, type docker images, see that there is an ls command, and run it. With Powershell you kind of have to guess and type `get-docker` and tab through commands. Also some times the verb is not easy to guess. So in terms not relying on documentation as you called it, I think PS is worse. That being sayd, once you do know the command you need, using it is much easier with PS as you nicely described. tip - if you liked tab completion, try ctrl+space :)

Re: Visual Studio Code 1.9

#290

Earlier quoted context omitted.

Perl scripts can be vastly more powerful than PS. Perl is a full blown general purpose programming language with a massive collection of libs and frameworks. It is however very powerful that Perl can be used in bash pipelines. But that is also true for any Unix tool that takes I/O. So Bash is also very powerful with the help from all its friends that can be used with pipes. Shell native. And you don't HAVE to code Ba…

> Perl is a full blown general purpose programming language with a massive collection of libs and frameworks. > So Bash is also very powerful with the help from all its friends > you don't HAVE to code Bash in the most convoluted way possible. Sane code structure and naming goes a long way. All of these things are also true for Powershell. Powershell can use any .NET Assembly, and if necessary make native windows sys…

Haven't really touched Windows the last 5+ years but adding .NET to the mix sounds a bit complicated in relation to Bash.
Post reply on HN