4 ms·

I like this guys spirit. Once I had to pick up old code from a guy with this spirit and it was f-ing horrible.

• mtillman 2y ago
  I love this project (from 2014?) and perhaps my favorite part other than the f-u of the whole thing is the commit message "complete refactoring".
• shrimp_emoji 2y ago
  Beats using Java Think of it as exercise: it sucks up front but you won't end up an obese diabetic on the WALL-E ship later.
  • SpaghettiCthulu 2y ago
    Java is only a nightmare when you have to follow corporate decade-old "best" practices
    • bheadmaster 2y ago
      In my experience, Java is a nightmare the moment you try to do anything beyond what C++ can (easily) do.
      • augusto-moura 2y ago
        Which would be?
        • bheadmaster 2y ago
          Ok, here are two examples on the top of my head, of fairly trivial programs that are a pain to do right in Java. 1) A program that copies all data from standard input to the standard output. Try to write this without Googling. Simple enough, eh? 2) A program that serves as a middleware between servers and clients, both of which are behind NATs so they connect to your middleware, using gRPC methods. Servers use gRPC streams to maintain a connection, send their ID as the first message, receive request messages, and send reply messages. Clients send ID and request in a message, and receive reply message. I hope you're willing to show me how wrong I am by writing the code :)
          • netvl 2y ago
            1 is really trivial and took me like 5 seconds to write: public class Test { public static void main(String[] args) { System.in.transferTo(System.out); } } 2 is anything but trivial in any language, unless it is some kind of a language specifically designed to build gRPC programs. Never versions of Java are quite pleasant to work with. There are a lots of quality-of-life improvements (switch expression, multi-line string literals, string templates (currently in preview), lots of useful stdlib APIs), as well as quite fundamental additions like Loom. edit: formatting, explanations
            • bheadmaster 2y ago
              > System.in.transferTo(System.out); Ok, that's really convenient :) I suppose it would be much harder to do it without the transferTo function, but that would be beyond the point. I'll instead focus on the example 2. > 2 is anything but trivial in any language, unless it is some kind of a language specifically designed to build gRPC programs. The gRPC protocol here is only an example. Feel free to use any protocol you like. As a counter-example, here's a TCP version in <200 lines of Go: https://gist.github.com/paskozdilar/6871fef7b0b245a0846bd27e386a798a https://gist.github.com/paskozdilar/6871fef7b0b245a0846bd27e... > Never versions of Java are quite pleasant to work with I know this is a typo, but you accidentally wrote something completely true :')
              • netvl 2y ago
                Typo, yeah :( I don’t agree that it is true) I can try doing it later today, but I’m 100% sure that TCP example will look pretty much the same in Java, in terms of complexity. > The gRPC protocol here is only an example. Feel free to use any protocol you like. FWIW, this is a pretty huge change. gRPC is quite complex, as it includes protobuf, http/2 and its own RPC mechanism. A simple TCP protocol is peanuts compared to that.
              • netvl 2y ago
                > I suppose it would be much harder to do it without the transferTo function, No, it would not: public class Test { public static void main(String[] args) throws Exception { byte[] buf = new byte[4096]; int read; while ((read = System.in.read(buf)) > 0) { System.out.write(buf, 0, read); } } } I imagine it will look pretty much the same in the majority of languages which have similar I/O abstractions.