Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming

Node.js/Deno Creator Discusses Rust, C++, TypeScript, and Vim (evrone.com) 87

Posted by EditorDavid from the not-my-types dept.
Ryan Dahl, creator of Node.js and Deno, gave a new interview this week to the IT outsourcing company Evrone: Evrone: You have hands-on experience with lots of programming languages: C, Rust, Ruby, JavaScript, TypeScript. Which one do you enjoy the most to work with?

Ryan: I have the most fun writing Rust these days. It has a steep learning curve and is not appropriate for many problems; but for the stuff I'm working on now it's perfect. It's a much better C++. I'm convinced that I will never start a new C++ project. Rust is beautiful in its ability to express low-level machinery with such simplicity.

JavaScript has never been my favorite language — it's just the most common language — and for that reason it is a useful way to express many ideas. I don't consider TypeScript a separate language; its beauty is that it's just marked up JavaScript. TypeScript allows one to build larger, more robust systems in JavaScript, and I'd say it's my go-to language for small everyday tasks.

With Deno we are trying to remove a lot of the complexity inherent in transpiling TypeScript code down to JavaScript with the hope this will enable more people to utilize it.

Evrone: Gradual typing was successfully added into core Python, PHP, and Ruby. What, in your opinion, is the main showstopper for adding types into JavaScript?

Ryan: Types were added to JavaScript (with TypeScript) far more successfully than has been accomplished in Python, PHP, or Ruby. TypeScript is JavaScript with types. The better question is: what is blocking the JavaScript standardization organization (TC39) from adopting TypeScript? Standardization, by design, moves slowly and carefully. They are first looking into proposing Types-As-Comments, which would allow the JavaScript runtimes to execute TypeScript syntax by ignoring the types. I think eventually TypeScript (or something like it) will be proposed as part of the JavaScript standard, but that will take time.

Evrone: As a respectable VIM user, what do you think of modern programmer editors like Visual Studio Code? Are they good enough for the old guard?

Ryan: Everyone I work with uses vscode and they love it. Probably most people should use that.

I continue to use VIM for two reasons. 1) I'm just very familiar and fast with it, I like being able to work over ssh and tmux and I enjoy the serenity of a full screen terminal. 2) It's important for software infrastructure to be text-based and accessible with simple tools. In the Java world they made the mistake of tying the IDEs too much into the worldflows of the language, creating a situation where practically one was forced to use an IDE to program Java. By using simple tooling myself, I ensure that the software I develop does not become unnecessarily reliant on IDEs. If you use grep instead of jump-to-definition too much indirection becomes intolerable. For what I do, I think this results in better software.
This discussion has been archived. No new comments can be posted.

Node.js/Deno Creator Discusses Rust, C++, TypeScript, and Vim More

Node.js/Deno Creator Discusses Rust, C++, TypeScript, and Vim

Comments Filter:
  • Please explain how this affects me.

    Thank you.

    • Please explain why you think the world should revolve around you.

      Oh, you said C programmer. ... Nevermind.

      • I really love the fact that the Rust guys built the first Rust Compiler with Ocaml with the very neat side effect that we can reduce the smug pretentious remarks from the C crew to a minimum. :-)

    • It doesn't, the PDP-11 is obsolete, and the world has long since moved to unicode strings.

      • What are you on about? C supports multibyte and wide strings just fine, all flavors of Unicode plus other things the world at large uses like JIS.

        The OS and infrastructure developed on the PDP-11 in C has concepts and code that endure to this day and you're using them.

        C and its libraries have evolved and are extremely relevant to what everyone here does.

        • Not quite sure how "C" and "supporting strings just fine" belong in the same sentence, given the disastrous security results we've found ourselves in. And I'm saying that as someone who actually (weirdly enough) likes C.

          • disastrous bugs have been done in all languages. Certain fanbois like to claim their language of choice will reduce disasterous bugs, like say Rust evangelists, but truth is of course to get certain stuff done they have to go into unsafe mode, heh. If the language takes off, gets the libaries and dynamic linking of mature languages , they'll be making their fair share of disasters too, that's a certainty.

            I'll say it again, C supports strings just fine.

            • Certain fanbois like to claim their language of choice will reduce disasterous bugs, like say Rust evangelists

              Well in Rust, strings have a pointer and a length. That eliminates a fair number of possible bugs in C. There's no such thing as null pointers in Rust*, so that entire class of errors is gone. The ownership/borrowing system guarantees no use after frees, no dirty cows, no dangling pointers, and no buffer overruns, so a lot of security vulnerabilities that you often find in big C/C++ projects aren't even possible.

              but truth is of course to get certain stuff done they have to go into unsafe mode, heh

              Unsafe still retains a lot of safeties. For example, you can't ignore the borrow checker in unsa

          • Because you can (and should) write your own string library (or at least replacements for the string.h standard functions) when you are writing in C. It's not hard to do in a way that makes C string overflows impossible.

            • Already been done and have been added to standard C string functions, lolz.

              strncpy and friends and their wide versions.

              • strncpy() is crap. Don't use it. Also the wide versions are horrible to use. Don't use them.

                • You're making proclamations and orders without a shred of proof or reason.

                  I'll make the suggestion that perhaps those functions are bad for YOU to use because you suck as a C programmer.

                  • You're making proclamations and orders without a shred of proof or reason.

                    You are most certainly a moron, who doesn't think and can't use Google. However if this is actually a topic you care about, here is a good summary of some of the problems [open-std.org]. Feel free to skip to the part about strncpy().

                    • I'm a C programmer and don't need google to tell me how to continue to properly handle strings. The only thing you link does is tell how to properly do things, if you think there is a *problem* with the string n functions that just shows your ignorance and lack of experience. There is no problem, the functions can be used properly for bug free code.

                    • The only thing you link does is tell how to properly do things,

                      Reading comprehension fail. Do you need to go back to kindergarten so you can learn to read properly?

                      I'm a C programmer and don't need google to tell me how to continue to properly handle strings.

                      You're obviously not a very good C programmer. You can't read English text. You get angry and insult for no reason.

                      How do you use strncpy() correctly with only one line of code? You can't answer.

                    • You only show yourself to be an incompetent C programmer; what nonsense you spew with "with only one line of code", you show your ignorance right there.

                      Stick with visual basic. it's your speed.

            • This is like the age-old argument about exceptions and object systems in Scheme vs. conditions and CLOS in Common Lisp. Sure you can roll out your own strings in C, just like you can roll out your own objects in Scheme, but then *everyone* has to roll out his own and the lowest common denominator for communication between code written by different people is still the thing that you tried to avoid by writing the extra code in the first place. Some elementary things simply *should* be in the language, otherwi

              • Some elementary things simply *should* be in the language

                They should be in the language, but if you care about security, you won't use the standard library string functions. They are bad.

                • In that case, I can't even open a file. (Although for the things I need with C or its derivatives, that's actually perfectly fine; I can set up the C code's working environment from elsewhere. But other people might not like that.)

                  • You can wrap fopen() in your own function. It is true that you may write a bug in your wrapper function, but you'll only make that bug once. After it's fixed, you'll never make that mistake again.

                    Another option is to have a c_str() method, like C++ does. Then for functions that don't have problems (and I think fopen() is one of those), you can just keep the original implementation.

        • Re: (Score:2)

          by gweihir ( 88907 )

          C and its libraries have evolved and are extremely relevant to what everyone here does.

          Indeed. Any claims of C being obsolete are about as stupid as claims that screws or nails are obsolete because we have glue now.

        • Nice string you've got there. It would be a shame if a null character were to land in the middle of it.

          • Depends which string functions you use, some don't care. Bad bugs can be done in any language. I've seen "enterprise java server" apps with hundreds of thousands of lines of code go kaboom when something pulled out of an object was null because never initialized. Doh!

      • Re: (Score:2)

        by gweihir ( 88907 )

        It doesn't, the PDP-11 is obsolete, and the world has long since moved to unicode strings.

        Nope. Unicode is for user interfaces. Anything else stays ASCII, at least if the designer is sane.

        • Easy to say for those of us whose first language can be expressed unambiguously using ASCII alone, but for the rest of us, that might not be practical.

          The only problem I see with Unicode internally, is the possibility for confusion over characters that are different, but look similar. And you can't completely eliminate that possibility even in ASCII. (1/l, 0/O), etc.). A sane programming font will at least help.

    • You like having a job, right? Then it affects you.

      (Me too, although my current drug of choice happens to be C#, which, in my part of the world, is used only to deliver content developed using Javascript and some framework-du-jour.)

  • I co-learned vi screen movement (H, J, K, and L keys) and Rogue back in the early days of dial-up UNIX terminals. Times were simpler then now get off my lawn. Still think VIM is a good rendition of the editor though.

    • For years I could not find a IDE that would support vi/m properly. I tried IntelliJ and Eclipse. I tried Eclim and Visual Studio. Finally I found a IDE that didn't try to emulate vim, and incorporated it perfectly, which is now my IDE of choice. That IDE is VScode with neovim. It works in Linux and Windows perfectly.

      Microsoft nailed it, I feel dirty.

      • Re: (Score:2)

        by kackle ( 910159 )
        +1 Funny.

        I wish I could recommend Open Watcom [github.com]. I bought Watcom in a brick-and-mortar decades ago and still use its vi editor now and again. But, it doesn't look popular/well-supported today.

      • It's not your parents' Microsoft. When forced by the existence of genuine competition to innovate and play nice with open source, today's Microsoft mostly does. I'd not have imagined that even 10 years ago - roughly the midpoint between Ballmer's "Linux is a cancer" speech, and today.

        I've not yet made the switch to vscode only because I have the full Visual Studio at work and I'm lazy. :) At some point I do hope to.

  • It's a proof of concept that was prematurely hurled into production 25 years ago. It was designed to twiddle DOM elements, not as the general purpose language it has been hacked into resembling.

    Apparently the Web hasn't learned from the years of stagnation brought on by IE having >90% market share. Javascript is arguably a more dangerous monoculture. Ten years ago Mozilla had a project to put Perl, Python, Ruby, and other language interpreters in the browser... if they hadn't abandoned that, Javascrip

    • Hadn't it been for manager meddling, you would have had Scheme instead of Javascript in your browser.

    • Re: (Score:1)

      by Tablizer ( 95088 )

      What do you propose it be replaced with? Every existing language has warts and loud critics.

      • I for one don't want to replace one monoculture with another. I'd have liked it though if browsers would have offered first-class support to multiple languages, Javascript being one but not necessarily the only one.

        • Re: (Score:1)

          by Tablizer ( 95088 )

          That's the alleged promise of Web Assembly. However, so far it's used more by slimebags like bitcoin miners than real stuff.

          I'd like to see a good state-ful GUI markup language standard so that we don't have code as much on the client side.

    • Javascript will be replaced soonish by WebAssembly, which will allow you to write in your language of choice.

      • I just wish they'd get on with WebAssembly being able to access the DOM without assistance from Javascript.

        • Yes, especially since it can already access the DOM, no reason to not make it real.

        • Re: (Score:1)

          by Tablizer ( 95088 )

          DOM sucks also. Web Assembly can't de-suck the DOM. If DOM worked properly, people wouldn't need to use PDF's to keep web browsers from mangling intent. DOM is an intent mangler created by academics lacking real world office experience.

      • Re: (Score:2)

        by Dracos ( 107777 )

        WebAssembly isn't a replacement for Javascript, it further canonizes Javascript and its interpreters. Which is exactly what Google wants.

  • He Absolutely Does Not Get JavaScript (Score:5, Interesting)

    by Slicker ( 102588 ) on Sunday February 21, 2021 @02:15PM (#61086830)

    I have been writing software since the early 1980's. Since then, the trend has been to try and reduce complexity by reducing developer freedom and visibility--keeping him or her more constrained to use only approved ways of coding. This makes micro-level code more readable but at substantial expense to execution performance is macro-level complexity. But that is the instinct--force people, through the language, to code better. However, experience has taught me that better is a very relative thing for which one needs freedom and visibility. Solving the problems of sloppy code are far better addresses by better management practices and in allowing developers to spend the time to improve code readability through revisions. The idea of checklists on code leads to very poor code quality of the kind that absolutely plagues the industry today.

    Typeless languages offer huge advantages in terms of the speed of development and maintenance. The common argument against is that it can introduce hard to find bugs but, in practice, that just isn't the case. In fact, I found it more often the opposite. I also used to believe in strongly typed languages because it seemed intuitive that more specificity would lead to clarity and unambiguity. It was PHP that finally convinced me that I was mistaken. JavaScript confirmed that and taught me also that I was wrong about conventional object orientation. The truth is that the vast majority of the time, the compiler/interpreter can be more efficient at deciding the underlying type and this takes a lot of complexity out of the programmer's necessary thinking processes. Consequently, the actual functional importance of the software your writing become your focus and, in the rare times that a typelessness induced bug occurs, it tends to be easy--not hard--to find. It's simply lost among far less complexity.

    As for C++, I was a very strong advocate for object orientation for a number of years. Once again, the theory I followed wound up getting me bit, repeatedly, by practice. Software tended to be all the things exactly opposite of what the theory offered--vastly more complex (not less), far less re-usable (not more), for example. The most typical struggle was in trying to re-use because changes to base classes often broke all kinds of things downstream. And working in one class, you have to constantly look around and wonder what is in other files with other classes and various abstracted things. Even just to pass parameters into a method, you have to pass the right kinds of things among a vast and growing list of them. And to get the objects your need as parameters can require a long laundry list of other things you need to do... Some stable class libraries, like KDE, are kept reasonably stable within each major version, at least (and I really like KDE). However, even the language specification itself and the boost library has grown extraordinarily in complexity. It's not generally an efficient way to write applications software...

    JavaScript's proto-type object orientation solves the problems with conventional object orientation. I also like how Rust does it, though. I think a big part of JavaScript's success is in freedom and visibility--the two things conventional object-orientation specifically aims at taking away from you. In JavaScript, you can inspect the objects you have at any point. You can act different based on what is in them so it can be reasonably safe for them to be changed. And JavaScript is not only faster at developing but also at executing. Conventional object-orientation has huge processing overhead just to instantiate one object. Every property in it, for example, must has new memory allocated. Memory allocations are the most CPU expensive activities an operating system typically has because memory must also be defragmented, on the fly.

    --Matthew C. Tedder

    • Since then, the trend has been to try and reduce complexity by reducing developer freedom and visibility--keeping him or her more constrained to use only approved ways of coding.

      You mean Python?
      Because with Perl, the cat is out of the bag, went to town, participated in a massive pub crawl, and is now busy walking on the keyboard, producing extremely efficient 1-liner that solve major computing problem. But are mostly "write-only". (Note: I joke, I've written tons of Perl. Though I don't guarantee I'll be able to read back all of it).

      Typeless languages offer huge advantages in terms of the speed of development and maintenance. The common argument against is that it can introduce hard to find bugs but, in practice, that just isn't the case.

      ...until you have major component in a complex bioinformatics pipeline that crashes because some bit of Python attempt to divide an int by a string.

      The

    • Re: (Score:3)

      by gweihir ( 88907 )

      Well, I certainly agree that languages cannot fix coders. Coders either know what they are doing and are given the time to do it right or you better forget about the whole thing completely. Hence a "good" language offers help if the coder explicitly wants it, but does not stand in the way of the coder. Python is an example. C at least does the second and modern C compilers do mote and more of the first.

      Bit the real problem is "management" that thinks coders are somewhere barely above a janitor. (With apolog

    • Re: (Score:1)

      by Anonymous Coward

      > Typeless languages offer huge advantages in terms of the speed of development and maintenance. The common argument against is that it can introduce hard to find bugs but, in practice, that just isn't the case. In fact, I found it more often the opposite.

      You need to explain this, because it runs contrary to a number of key studies on the topic. The fact is there is a substantial body of evidence demonstrating that typeless languages do indeed lead to a greater number of defects, and it's really not rock

    • Re: (Score:1)

      by Anonymous Coward

      Did you really just put your name to that drivel?

      >>> As for C++, I was a very strong advocate for object orientation for a number of years. Once again, the theory I followed wound up getting me bit, repeatedly, by practice. Software tended to be all the things exactly opposite of what the theory offered--vastly more complex (not less), far less re-usable (not more), for example. The most typical struggle was in trying to re-use because changes to base classes often broke all kinds of things downstr

    • Re:He Absolutely Does Not Get JavaScript (Score:4, Insightful)

      by phantomfive ( 622387 ) on Sunday February 21, 2021 @06:58PM (#61087822) Journal

      Typeless languages offer huge advantages in terms of the speed of development and maintenance

      That's a lie.

      • Re: (Score:1)

        by Tablizer ( 95088 )

        It's subjective and domain dependent. I don't personally like the way JavaScript does dynamic types, by the way, but do enjoy dynamic typing done well.

        For example, it's really stupid to overload "+" for both addition and string concatenation. Things were cleaner and clearer with "&" used by VB-script for concatenation. (I'm not promoting VB-script in general.)

    • I agree about typed languages: i just realized that I never face bugs related to the variables types. But I disagree regarding OO: every framework or language that has bad OO support/design gives much more trouble to find defects that the ones following a good OO design.

    • Try writing untyped code when money is at stake! (Score:5, Insightful)

      by Somervillain ( 4719341 ) on Sunday February 21, 2021 @09:33PM (#61088266)

      Typeless languages offer huge advantages in terms of the speed of development and maintenance. The common argument against is that it can introduce hard to find bugs but, in practice, that just isn't the case. In fact, I found it more often the opposite.

      OK, so you have been writing software for 40 years. That is impressive, but you didn't indicate if that was professional or not. I am guessing from this comment you've never worked on a large team.

      Any nonsense about how a beautiful language makes you more productive is thrown out the window once you do it professionally for a profitable company with millions of dollars at stake. By myself, I am awesome in many tools. With my most trusted colleagues, we can do amazing things with many tools. The problem is I work for a profitable company.

      My profitable company has a large dev team across many continents. We have 100s of contributors to our common code base. Some teams have tried writing backend code in JavaScript and it was a DISASTER...same for Python. The Java and C teams have done the best.

      I'll assume you're talented. I'll assume lots of your coworkers are talented. Here's the problem, in a growing, profitable company, talented people get promoted. Their salary gets tripled as they go to the director level. My project? It's been passed off to 10 different teams. My first project is on it's 6th team. You need compilers, unit tests, static code analysis and heavy CI pipelines to keep things running smoothly and efficiently. For artisanal code with a team small enough to fit in a minivan, you can do whatever you want. When you have a decent sized team, the product has been in production for 10 years, and it switches hands, the tediousness of Java makes sense. it's not even Java's fault. It's business software best practices.

      We have a large project written in Python 2 from a company we acquired. They had to port it to Python 3. Took a year and had several major incidents that resulted in a rollback. We've upgraded major Java versions like 5x since I joined and never had a rollback. Switched entire environments from hosted to cloud, no rollback, for our C or Java code. We had a project written in node.js. We had to upgrade one library, something we do monthly in Java. Took us 2 months to find all the bugs...because the maintainer changed all the API signatures. In Java, the compiler finds these bugs for you. In node.js, either your unit tests or the customer finds your bugs. In this case, we found out the maintainer wrote shit unit tests.

      Talented people, such as yourself, can write great code with many tools. I work for a profitable company doing this professionally. We need to keep the business running with the team we can hire, not the team we need. This means a lot of mediocre professionals as the superstars get promoted or start their own company or just move away and do something weird like geniuses are known to do. Compiled languages go a long way towards ensuring basic bugs are quickly found and the Java best practices culture really ensures that code is very consistent and generally high quality...it may not be beautiful, but it performs much better than our node or python code and tends to be extremely reliable. It's consistent, stable, and easy for new teams to maintain. It's easy for mediocre professionals to write effective code. It's very depersonalized...doesn't have the nuances and idiosyncrasies of the original author and tends to be very uniform in structure...because there is a culture that has documented nearly every imaginable best practice...which often takes the fun out of coding, but also the fear and drama.

      Java is the dominant business language and nearly everyone who starts a company in another language, such as Ruby, PHP, node, finds themselves rewriting more of their backend code in Java as they get profitable and need to scale. This is not because no one knows any better. All of the major languages, are 1

      • Re: (Score:1)

        by Anonymous Coward

        Read his comment over again, it's quite enlightening. He says the reason he doesn't like OO in languages that implement it properly is because they properly implement data hiding. The reason he likes Javascript is because data hiding is poorly implemented and you can inspect anything from anywhere.

        Long story short, this guy likes Javascript because you can put global variables everywhere and hates large existing OO codebases because you can't just access data you shouldn't.

        By his own indirect admission, thi

      • We mostly agree.

        However, I would submit that everything that makes Java a good back-end language (portability, consistency, type- and memory-safety, ease of learning, strong ecosystem, etc.) argues at least as strongly in favor of C# on .NET Core, and with the added bonus of never having to deal directly with Oracle.

        • We mostly agree.

          However, I would submit that everything that makes Java a good back-end language (portability, consistency, type- and memory-safety, ease of learning, strong ecosystem, etc.) argues at least as strongly in favor of C# on .NET Core, and with the added bonus of never having to deal directly with Oracle.

          We've been on OpenJDK for a few years now for all mission critical releases. Haven't dealt with Oracle at all for Java (we still pay for RDBMS). .NET is a perfectly fine platform, but given that a business system can be in place for 20-40 years (my current one was started about 20 years ago), you're really splitting hairs between Oracle and Microsoft as far as which is less evil.

          Today's Microsoft is really awesome, but 20 years ago, Balmer and Gates did all they could to lock you into the MS ecosystem.

    • Re: (Score:2)

      by renzhi ( 2216300 )

      Typeless languages offer huge advantages in terms of the speed of development and maintenance.

      Oh, my god, where to start?

      If by speed of development, you mean working on a small project (e.g. prototype) that you write by yourself, or a small team of no more than three developers (who have similar level of mastery of the language and whatever frameworks you use). I can crank out 30K lines of Ruby/Lua codes quickly by myself and feel like speed of development is great too, because I know every line of code and what to expect of every parameter in every function and what to expect in return, etc. Tr

    • Re: (Score:1)

      by jay age ( 757446 )

      I can relate to trouble you were experiencing with object-oriented programming in C++.
      Fortunately, C++ being many languages rolled into one, there are other ways.

      After first having used it between 1990-1999, I came back to it in 2017, and lo and behold - what a change! Before looking at all the new things, the first idea was to use OO programming with a pattern fitting problem on hand. Soon afterwards, after looking at C++11 and later standards this was promptly abandoned. These days, I use it as a kind of

    • Typeless languages offer huge advantages in terms of the speed of development and maintenance. The common argument against is that it can introduce hard to find bugs but, in practice, that just isn't the case.

      First of all, languages like Javascript are not "typeless", they are dynamically typed. So you have simple types such as String and Number, and compound types such Array and Object. Javascript is loosely typed, in that it will allow all sorts of implicit conversions between types, e,g. a number can be converted to a string, where a string is wanted. Python is strictly typed, in that such conversions have to be made explicit. However, Python is still dynamically typed, which means types are decided and check

    • Agree with you completely.
      (Also started hammering on the C64 during the 80s ;) )

      Though might be considered flame bait, I would even go so far as to say that hard typed and / or forced structured languages (i.e Python), and languages with excessive syntax and forced gigasize declarations, tries to solve the problem of bad programmers writing bad code by forcing them to use some coding paradigm (to catch errors during a compile phase), which might seem all good, but instead fosters the idea of them _not_ havi

    • Re: (Score:1)

      by McLoud ( 92118 )

      Typeless languages offer huge advantages in terms of the speed of development and maintenance.

      Wake me up when javascript or ruby can properly do code completion in the level of the java IDE's. Right now it simply doesn't work at all unless it's simple prototypes in the same file

  • This guy does not even know C is not C++ ??? (Score:3)

    by gweihir ( 88907 ) on Sunday February 21, 2021 @03:02PM (#61086964)

    At least his answer seems to imply that.

    C is a completely different beast than C++. C++ is a bloated monster with tons of special case and a bad type and run-time system. C is a minimalist "extreme performance" language that runs basically everywhere and lets you do anything as it assumes you know what you are doing. Because of that, C does not have broken OO either. (It does not have compiler-level OO at all, it does have coder-level OO.)

  • As the creator of Node.js (Score:3)

    by Rosco P. Coltrane ( 209368 ) on Sunday February 21, 2021 @03:38PM (#61087088)

    please kindly die. What a dreadful thing to inflict on the world.

  • Ryan: Everyone I work with uses vscode and they love it. Probably most people should use that.

    Everyone I work with uses VSCode. I use it also for that reason. I think it's a trash Editor, barely better than Notepad.

    • Re:VSCode (Score:5, Funny)

      by MrKaos ( 858439 ) on Monday February 22, 2021 @05:25AM (#61089230) Journal

      Ryan: Everyone I work with uses vscode and they love it. Probably most people should use that.

      Everyone I work with uses VSCode. I use it also for that reason. I think it's a trash Editor, barely better than Notepad.

      It supports neovim, really well. Or maybe neovim supports vscode. I think that makes it visexual.

Slashdot Top Deals

The moon is a planet just like the Earth, only it is even deader.

Close