1. 7
  1.  

  2. 10

    I like how this article pushes people to put themselves out there. Doing that is a muscle that gets stronger the more you do it.

    I dislike how much it emphasis it puts on how your work is received. You need to be building the things that are important to you. You don’t need to be building the things that you’re told are ‘relevant’ or ‘important.’ Now, if you can get people to rally behind what you are making…great!

    Just don’t sell your art to Internet Points.

    1. [Comment removed by author]

      1. 10

        Because in some (most?) people’s minds javascript is the correct choice for everything.

        1. 6

          I’d be extremely skeptical if it were most people’s minds. Javascript is slow as balls even at its fastest with insanely intelligent people optimizing it. It’s like a slipstream wind tunnel optimized horse with spoilers .

          1. 2

            It doesn’t matter that it’s slow.

            Most people (myself included) have forgotten or often forget just how fucking fast a modern computer can be when it isn’t being pulled in a bajillion different directions.

            The problems we’re solving in the mainstream aren’t getting any harder either, so the lack of dramatic speed increases basically isn’t noticed.

            1. 1

              That’s true in your domain, it’s not universally true. I can think of tons of problems were speed is still definitely a limiting factor, and I’m sure you can too. If speed is not a limiting factor for you, and you don’t mind testing for types, sure write your behemoth in javascript. I’d rather work in a language that works faster, and takes less effort to write well for large applications. The idea that languages have a sweet spot isn’t new, feel free to use your mallet for all hammering.

        2. 3

          Writing back end javascript is like writing front end C++. Sure you could, and I guess if you only knew C++ you would, but you might not want to if you want it to be the best it could be. If it’s a small program, I see no harm in having it be in javascript, but for large projects you are going to miss having more strict and static typing, and you’re going to miss the speed.

        3. 2

          Regarding JS slowness and not being backend worthy:

          https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/

          “A few details stood out after we ran the test cases and both applications passed the same functional tests. The node.js app was:

          Built almost twice as fast with fewer people. Written in 33% fewer lines of code. Constructed with 40% fewer files."

          1. 2

            I don’t take issue with using JS in the backend, particularly not on performance grounds (I work on a bunch of Rails apps, it’s not fast, but it’s fine for a lot of problems).

            Not a big fan of that article though. I wouldn’t draw anything from it other than “2013 Paypal had issues” (curious how things look there now). Charles Nutter summed it up well.

            1. 1

              I just don’t know how much I trust that one datapoint. So the java app was the “backup”. Something tells me their best and brightest weren’t working on the “backup plan”. Also wrt to “Built almost twice as fast with fewer people.” my old CTO used to have a great saying. He said: “I think 10 people can get almost twice as much done as 1”.