Live data from Hacker News

The Rise of Microsoft Visual Studio Code

triplebyte.com

281–290 of 327 posts

Re: The Rise of Microsoft Visual Studio Code

#281

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 mention both using git directly from the command line and Emacs, have you tried magit?

Re: The Rise of Microsoft Visual Studio Code

#282

Earlier quoted context omitted.

Since when LoC is a meaningful metric?

Since always but it depends on what you actually take into account. More LOC means more opportunities for error, and more resources needed to review that code and more time required for a new developer to get familiar with the code base. That said if you have 85 LOC vs 1000 it usually means that the 85 LOC “app” used a metric ton of external dependencies which are on their own a good source for problems. When compari…

I LOLed on this one :) I can literally double LOC in any project, just by putting { } on separate lines

Re: The Rise of Microsoft Visual Studio Code

#283

Earlier quoted context omitted.

Since always but it depends on what you actually take into account. More LOC means more opportunities for error, and more resources needed to review that code and more time required for a new developer to get familiar with the code base. That said if you have 85 LOC vs 1000 it usually means that the 85 LOC “app” used a metric ton of external dependencies which are on their own a good source for problems. When compari…

I LOLed on this one :) I can literally double LOC in any project, just by putting { } on separate lines

If you LOLed at this one you likly don’t understsnd how LOC are counted.

Re: The Rise of Microsoft Visual Studio Code

#284

Earlier quoted context omitted.

> I would probably choose Go for core infra for being able to move quickly as a developer At the company I used to work at it took nearly a 1000 lines to replace an 80 line bash script. So I can't help but laugh at this statement.

I've helped port some bash-based CLI tools to Go. The amount of code produced was pretty similar, just some overhead for typing and adapting some of the `awk` and `sed` functionality to be self-contained in the program. What kind of stuff was this 80 line bash script doing that resulted in over 12.5 times more code?

[deleted]

Re: The Rise of Microsoft Visual Studio Code

#285

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…

> I paid for sublime so i will use it I purchased Sublime when it was the least bad editor out there, but finally realized that I was suffering from the sunk cost fallacy. I still consider it the worst software purchase I've ever made, and it's also why I'm reluctant to pay a single buck for software nowadays.

I mean I use VS Code a lot more often, and PyCharm / JetBrains IDES moreso than I do Sublime Text but I wouldn't say it's the worst purchase. I bought a text editor that's got out of the box syntax highlighting for most languages and decent enough linting plugins to catch some of the syntax errors I may be about to miss.

I only wish Sublime Text were able to (out of the box) mount / SSH into any server like emacs does (using TRAMP). I'm finding myself using VIM lately mostly because it's a step up from nano which uses tabs, not sure how to tell it how to space things, nano is perfect for Go I suppose. I have to figure out how to configure VIM for spacing things properly though, but I mostly install Sublime Text on VM's I write code in.

Re: The Rise of Microsoft Visual Studio Code

#286
post #53

VS Code has taken me off Emacs for Python development on Windows. I was never able to get a clean and speedy code completion, navigation, or refactoring to work with Emacs. I hope the situation changes someday.

It's hard to beat pycharm especially on Windows...

Re: The Rise of Microsoft Visual Studio Code

#287

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…

I am much the same. I have stickers for IntelliJ (as a stand in for all JetBrains IDEs), Emacs and Vim on my laptop because each has a different use case and preferred language. I even have Atom, Sublime and others installed and use them on rare occasions when they have plugins that are useful for a task at hand.

I also exclusively use the command line for source control (of which I use at least four, but mostly git and hg). I just do not trust IDEs to do the right thing, although JetBrains does get close (but my colleague devs hate the properly pruned .idea in the repos).

Re: The Rise of Microsoft Visual Studio Code

#288
post #37

Earlier quoted context omitted.

> This is a fantastic demonstration of why i exclusively use git from a command prompt... Thanks for this. I've always felt the same way but haven't been able to put my finger on why. As more things get integrated into my editor (I use VSCode) I feel like I should use the shiny features, but for source control I think I'm going to only use the commandline forever. (Edit: though plugins such as GitLens that give you s…

Same here w/o fancy tooling around Git, but a couple of aliases. I will refuse to use any Git tools or UIs, but the standard CLI, until the end of my career. Besides that, my IDE/Editor is neither a build tool manager nor should it run my app from within an integrated console having specific settings. The projects people are going to inherit from me will always be editor-agnostic, the environment they run in will nev…

I agree on part of that -- VSCode has a pretty good Node debugger, and you can run it with a listen hook (and therefore set it to run via a npm/yarn package.json script). Similarly, I feel like it's OK for an editor to run a script from the app in an integrated terminal, as long as that script is still accessible from a standard CLI.

Git is complex enough that I don't trust more complex operations (basically anything beyond push, pull, add, and checkout) to be handled by a GUI, but a GUI can make for a great code review tool.

Re: The Rise of Microsoft Visual Studio Code

#289

Earlier quoted context omitted.

If Go adds generics and a smoother method of doing error handling, I could see it eventually taking Python's place. It already is doing so to an extent, but with those features plus everything else it can do better than Python, it'd be tough to beat. 95% of my programming is in Python, and I honestly don't really enjoy coding in Go that much, but with those changes I could see myself switching.

Same. 99% of my back-end and robot code is Python. Maybe this is a grass is always greener kind of thing but I'm hitting projects of a size where I miss static typing. I will say that asyncio is amazing and really solves concurrency for me. But Go looks like you also get parallelism without a lot of work.

Asyncio is good but it will not give you true parallelism: asyncio still uses the GIL, on a single thread

Re: The Rise of Microsoft Visual Studio Code

#290
post #255

Earlier quoted context omitted.

VSCode is only on the rise because alternatives are really bad. Meanwhile, it offers good defaults, and decent latency on modern hardware but for me it is just a glorified syntax highlighter. VSCode becoming so popular should not tell us it is a great product, but that most modern alternatives suck.

So almost as if it's a relatively good product when compared with the alternatives

It is sad when all the alternatives are the same problems.

I want low latency and very very fast browsing through pages of code. Sublime text wasn't so bad, with support for VI bindings. But it did not offer more than just opening VI.

I lost most hope for innovation there.

I will stick to the terminal until something serious arrives.

Post reply on HN