Live data from Hacker News

The Rise of Microsoft Visual Studio Code

triplebyte.com

91–100 of 327 posts

Re: The Rise of Microsoft Visual Studio Code

#91
post #58

> However, it seems that the average C# or Java engineer who goes through our process does less well than the average Ruby or Go engineer. I have no idea why. Given that they have the test info... and they're the ones deciding pass/fail... it's a bit strange they "have no idea why". Well, perhaps just this person doesn't? Are people not finishing the projects? Do the projects have syntax errors in them? Or logical bu…

It's because the process is CS heavy. Slinging business logic together while mapping it through some ORM to satisfy the latest priority shift this sprint is what the average C# and Java engineer excels at. It's more craftsmanship and less computer science.

C# is very well thought out language. It development team is super experienced in language design. Its head designer Anders Hejlsberg has made other languages. And they borrow stuff from other languages like lambda etc.

Re: The Rise of Microsoft Visual Studio Code

#92

Earlier quoted context omitted.

I use emacs for Java and Scala development with LSP quite successfully, and VS Code's support for language servers is as good as they come. Is it primarily debugging that's the impediment to switching for you?

I have some time off soon and there's a project I have planned that will use Scala. What LSP server do you recommend, and are you using it with lsp-mode or with eglot?

I'm using lsp-mode and the Eclipse JDT language server. lsp-java is great and the maintainer is very responsive to PRs and feedback.

For Scala I use Ensime at work and have been playing with metals at home. The latter is still very much under active development and you'll likely have to put up with Ensime's quirks for a complicated Scala codebase.

Re: The Rise of Microsoft Visual Studio Code

#93

One of my favorite things about VS Code is how usable it is with its default configuration, and how easy it is to customize to my liking. I found Atom and Sublime Text very frustrating in that regard.

Interestingly, I found Atom to be much easier to customize. There are still things in VS Code I can't customize that I used to have in Atom. That said, I've been on VS Code for a little more than a year now and it's grown on me.

[deleted]

Re: The Rise of Microsoft Visual Studio Code

#94
post #79

Earlier quoted context omitted.

> I paid for sublime so i will use it -- and multiple cursors everywhere is a boon for quick and dirty data munging These days pretty much every serious editor has multiple cursors, including Visual Studio Code.

had to look up "multiple cursors" and it looks like it's the same as "column mode" which has been around in MS editors forever?

[deleted]

Re: The Rise of Microsoft Visual Studio Code

#95
post #75

There are some warts, but it seems nice from afar. The biggest wart is/was the "FUCK FUCK FUCK" git clean vs git reset UX error: https://github.com/microsoft/vscode/issues/32405 . This is a fantastic demonstration of why i exclusively use git from a command prompt -- i know what will happen and nobody's going to reinvent terms to put on buttons that just confuse me. In my life: - I'm committed to emacs for org-mode a…

> This is a fantastic demonstration of why i exclusively use git from a command prompt -- i know what will happen and nobody's going to reinvent terms to put on buttons that just confuse me. This many times. I'll open SourceTree to view a large set of diffs or changes, but still drop back to the CLI to push/pull/rebase/commit/stash/etc... I know what git will do in those cases, and am a little wary of git UIs.

Actually Eclipse's git UI is very practical. I use it whenever I'm developing somehting in Eclipse, however I still command line as much for other reasons.

OTOH, I despise heavily modified bash/zsh/whatever profiles which makes the environment non-portable. Extreme eye-candy in the console makes stuff harder for devs/admins who logs in to thousands of servers.

Re: The Rise of Microsoft Visual Studio Code

#97

There are some warts, but it seems nice from afar. The biggest wart is/was the "FUCK FUCK FUCK" git clean vs git reset UX error: https://github.com/microsoft/vscode/issues/32405 . This is a fantastic demonstration of why i exclusively use git from a command prompt -- i know what will happen and nobody's going to reinvent terms to put on buttons that just confuse me. In my life: - I'm committed to emacs for org-mode a…

Since you're an Emacs user... just wanted to plug magit - it might make you change your mind about command-prompt-only git usage

Re: The Rise of Microsoft Visual Studio Code

#98
post #2

Another interesting angle on this is that VS Code is free (and open source), while Sublime is proprietary and (nominally) costs $80. I wonder how many people don't use Sublime because of the price? Atom is free too and never surpassed Sublime.

A lot of people I know who use Sublime never paid. In fact, I don't know anyone who paid for it IRL except myself.

If you don't pay, you only get a nag screen from time to time as you save. And cracks most likely exist if you want to get rid of it without paying.

BTW, I still use Sublime Text. I gave a try to VS Code and it is really great. It has most of the things that made me switch to Sublime (from Emacs), plus some more. The issue I had was performance. Sublime is generally more responsive for me, with less subsecond but still noticeable pauses.

Re: The Rise of Microsoft Visual Studio Code

#99
post #39

Earlier quoted context omitted.

Emacs has multi-cursor support. http://emacsrocks.com/e13.html

Is that native?

It isn't, and it's better because of that.

All "advanced" features should be a plugin so you can pick your favorites. This way, if someone comes up with a better multi-cursor system, there's no politics involved about which multi-cursor system to come to a global consensus on. Just switch your personal config over to the new plugin and get on with your life.

Re: The Rise of Microsoft Visual Studio Code

#100

There are some warts, but it seems nice from afar. The biggest wart is/was the "FUCK FUCK FUCK" git clean vs git reset UX error: https://github.com/microsoft/vscode/issues/32405 . This is a fantastic demonstration of why i exclusively use git from a command prompt -- i know what will happen and nobody's going to reinvent terms to put on buttons that just confuse me. In my life: - I'm committed to emacs for org-mode a…

amen people look at me like I'm an old crazy dude because I don't use a git UI or eclipse, or intellij, or from sublime. Git already has plenty of quirks, adding another layer of unknown on top of it is a no-go

I've started using VSCode for git push/pull/branch and staging. This is what I use git for 99% of the time anyways and since they are simple commands, triggering them from VSCode is faster than falling back to CLI.

Staging/diffing is especially convenient with VSCode. `git add -p` used to be my most-used command, but VSCode just makes the process easier.

Post reply on HN