Live data from Hacker News

The Rise of Microsoft Visual Studio Code

triplebyte.com

191–200 of 327 posts

Re: The Rise of Microsoft Visual Studio Code

#192

What editor do Go devs use??? Their numbers for Go only add up to 12%! https://d25hn4jiqx5f7l.cloudfront.net/file_attachments/files...

Yes, that chart shows that they have relatively few people doing their interviews in Golang, so their outlier pass rate should have correspondingly large error bars (which you have to imagine because the graphs were drawn without any statistical sophistication).

Re: The Rise of Microsoft Visual Studio Code

#194

Earlier quoted context omitted.

I feel like you should spend some time with Go. If I were building a startup, I would probably choose Go for core infra for being able to move quickly as a developer and write incredibly performant code with about as much mental overhead as most dynamically typed languages. Anecdotally, I've seen it replace Java in quite a few small and medium sized established companies.

I feel like Python is your pepperoni pizza can't go wrong option for almost anything. Go feels similar but younger. I love languages with big standard libraries. Just need their package management story to settle down for a while. There's something wonderful about a language being so popular and around for so long that there's plenty of resources and answers on just about anything. I think that's a core part of what…

Python can go wrong for large codebases. There are exceptions, of course, but if I focus on the consensus: large code bases in a dynamic language have an anecdotally significant likelihood of becoming unmaintainable. It's a glass ceiling that almost everyone I've met, who has done serious work with a dynamic language, has encountered.

There are ways to deal with it, but it requires rigorous discipline, and resisting Python's dynamic siren call earlier on in the process.

Golang naturally guides you into a style of programming which scales. You're not fighting the language (or your own inclinations) to avoid getting entangled later on.

Everything has exceptions†, you can shoot yourself in the foot with anything, yes. But, reasonably, it's about the relative struggle to end up in a similar place. Which is higher for Golang initially, but higher for Python later on.

Not trying to turn this into a Python vs Go thread; they both have their place. But Python can definitely go wrong, in an area significant to many people.

† Except Go... T_T

Re: The Rise of Microsoft Visual Studio Code

#195

Earlier quoted context omitted.

I feel like Python is your pepperoni pizza can't go wrong option for almost anything. Go feels similar but younger. I love languages with big standard libraries. Just need their package management story to settle down for a while. There's something wonderful about a language being so popular and around for so long that there's plenty of resources and answers on just about anything. I think that's a core part of what…

Python can go wrong for large codebases. There are exceptions, of course, but if I focus on the consensus: large code bases in a dynamic language have an anecdotally significant likelihood of becoming unmaintainable. It's a glass ceiling that almost everyone I've met, who has done serious work with a dynamic language, has encountered. There are ways to deal with it, but it requires rigorous discipline, and resisting…

Yeah I'm inclined to agree the more I think about it.

Re: The Rise of Microsoft Visual Studio Code

#196
The only issue I have with VS code is it's awful UI/UX performance - it behaves like an Electron app or something.

I realize that's a fair insult around these crowds, but it really does have that lack-of-polish, weird-UI/UX feeling. I know Microsoft would obviously never build an IDE off it, but I'm almost curious to see what on earth they did wrong.

Comparing it side-by-side with Xcode is certainly the easiest way to tell.

Re: The Rise of Microsoft Visual Studio Code

#197
post #10

"Do Emacs and Vim users have some other characteristic that makes them more likely to succeed during interviews?" I think the Interview Pass Rates chart makes it clear that the answer is a statistical "Yes", at least for Emacs.

I've been almost exclusively an Emacs user since the turn of the millennium or so, even before I was a full-time professional programmer. I briefly tried out TextMate years ago, and I've tried out VS Code, but I stick to Emacs for day-to-day work, and the keybindings are pretty much hard-wired into me at this point.

At the same time, I hate and actively avoid typical tech interview processes, and I suspect my pass rate if I did a bunch of them would start out low and only grow after a while once I got used to "interview coding" (which is basically a separate skill from actual programming).

So I don't know why they see this effect. My first guess would be that it's a kind of survivorship bias; outside of the occasional splash of someone trendy inspiring some new users, using the classic Unix-y editors seems to correlate with older/more experienced programmers. Who, because they've managed to stick around as long as they have, probably can manage to get hired when they want or need to.

Re: The Rise of Microsoft Visual Studio Code

#198
It's a nice editor but it has defaults I don't care for, and I suspect the effort in figuring them all out and how to change them to my liking is not worth whatever marginal advantages it has over Sublime.

For example, out of the box, when you search for a file and then open it, then search for another file and open it, it doesn't keep the first file open. To fix that, I had to guess what to plug into Google to figure out what that "feature" was named, and then turn it off. (Why would I want an editor that offers tabs, then only ever keeps one tab open?!)

I dunno, the older I get the more I just want shit to work so I can do my job. Nowadays the thought of tweaking a tool to make it perhaps 7% better than what I was using just makes me feel exhausted.

Re: The Rise of Microsoft Visual Studio Code

#199
post #142

Earlier quoted context omitted.

My job involves interviewing many engineering candidates, and I see the issue with typing all the time. A competent Java dev is at a disadvantage compared to a competent Python dev, simply because it's statically typed and more verbose, meaning there are more lines of code which means more small problems that can arise. That matters greatly in a short, time-boxed context.

> A competent Java dev is at a disadvantage compared to a competent Python dev, simply because it's statically typed and more verbose I don't think that the fact that it's statically typed is the problem. For example, I don't believe a competent Rust, Go, or Haskell dev would be at a disadvantage due to static typing, but rather the opposite.

As someone else who's run a lot of interviews including tech exercises (as much as I hate the typical way they're done, I haven't been able to eliminate them everywhere I've worked), I have the same experience as the parent commenter. Yes, even with "good" statically-typed languages like $YOUR_FAVORITE_LANG_HERE.

Candidates using those languages can often sketch out the right algorithm and the structure of what the program would look like, but under time pressure have trouble producing something that actually will compile and run properly (and as much as I want "showed they got the right algorithm and how to do it" to be a pass, it isn't always). The "executable pseudocode" nature of the popular dynamic languages is a big advantage there.

It's definitely even worse for C#/Java style languages (though C# is better than it used to be), because of all the heavyweight design pattern stuff you need to implement to do things that are just natural idioms in the dynamic languages. But it's something I've seen happen in a broad range of static languages.

Re: The Rise of Microsoft Visual Studio Code

#200

Earlier quoted context omitted.

I feel like Python is your pepperoni pizza can't go wrong option for almost anything. Go feels similar but younger. I love languages with big standard libraries. Just need their package management story to settle down for a while. There's something wonderful about a language being so popular and around for so long that there's plenty of resources and answers on just about anything. I think that's a core part of what…

Python can go wrong for large codebases. There are exceptions, of course, but if I focus on the consensus: large code bases in a dynamic language have an anecdotally significant likelihood of becoming unmaintainable. It's a glass ceiling that almost everyone I've met, who has done serious work with a dynamic language, has encountered. There are ways to deal with it, but it requires rigorous discipline, and resisting…

Most of the workarounds seem to boil down to de facto static typing in function signatures. That is, using annotations / rigidly formatted comments to provide the type information necessary for IDE support.
Post reply on HN