_______               __                   _______
       |   |   |.---.-..----.|  |--..-----..----. |    |  |.-----..--.--.--..-----.
       |       ||  _  ||  __||    < |  -__||   _| |       ||  -__||  |  |  ||__ --|
       |___|___||___._||____||__|__||_____||__|   |__|____||_____||________||_____|
                                                             on Gopher (inofficial)
   URI Visit Hacker News on the Web
       
       
       COMMENT PAGE FOR:
   URI   Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin
       
       
        jgsteven wrote 2 hours 6 min ago:
        I wonder if cross-compiled Java to JavaScript or WASM would work here.
       
        diegof79 wrote 2 hours 39 min ago:
        This part:
        
        > What surprised me was that Java supported processing ZIP files and
        XML from its standard runtime.
        
        Makes me feel old.
        
        Java was developed at a time when most people connected to the Internet
        via dial-up.
        That meant two things: the runtime is something you download once and
        has to work offline, and it has to support compressed packages. JAR
        files are essentially ZIP files with additional metadata stored as
        files. So yes, that’s why Java has built-in libraries for ZIP files.
        
        The XML came with the “XML fever” of the 2000s. Java was one of the
        first languages to include XML support, and many of the XML DOM APIs
        are very Java-oriented. And, of course, it was included in the standard
        lib because nobody wanted extra module downloads over a slow
        connection. (and because XML was evolving at that time, it also meant
        that you had some issues between the SDK libs and user-provided libs)
       
          NuclearPM wrote 1 hour 7 min ago:
          I just had to look through XML at work. What an ugly format!
       
            chasd00 wrote 7 min ago:
            There use to be a saying, "XML is like violence, if it's not
            working just add more!".
       
          hedgehog wrote 1 hour 53 min ago:
          You know that, and I know that, but for someone who started working
          more recently the difference between CORBA and punch cards might be a
          little blurry because they're both so far back they've never seen
          either. It's like kids asking how the dinosaurs in LEGO Jurassic
          world were animated, because they don't move like real toys, and
          noting how much easier the 1993 live action Jurassic Park filming was
          because back then they could just film real dinosaurs. Feels weird,
          but makes sense from their perspective.
       
            auvi wrote 1 hour 1 min ago:
            Jurassic Park 1993 introduced UNIX to the mainstream world. Movies
            of that era  showed SGI Sun, Cray or CM computers. All gone. I miss
            those days.
       
              clan wrote 43 min ago:
              Too many secrets, indeed!
       
        tracker1 wrote 2 hours 55 min ago:
        I'm a bit surprised that Go and Rust weren't at least considered.  I'd
        probably have looked into Deno in addition to Bun for the combined
        TS/JS assembly.
        
        On the JS/TS side, you also have a few interesting tools to make
        interacting with XML a bit easier in practice (cheerio, for example). 
        I'm not sure if the purpose in interacting with DOCX and to what extent
        manipulation is wanted/needed... it's a complex format to say the
        least, especially with references/embedding.
        
        I've never been a Java fan, having preferred C# along the way, but I
        don't think I'd use either for something like this just because of the
        runtime size, if nothing else.
       
        Bengalilol wrote 3 hours 55 min ago:
        I think this project could be a perfect (I may be biased and didn't
        dig) candidate for Haxe to JS dev : no framework (except a small node
        server?), strict typing, minimal dependencies (jszip and maybe
        fast-xml-parser). What could go wrong?
       
        exabrial wrote 4 hours 5 min ago:
        Reality has types and identity. Static types just make sense.
        
        That all being said, the JVM has never broken into local apps, even
        with JavaFx. I think the thought of installing a JVM, plus then
        installing an app is no longer a workflow most users will tolerate.
        Electron has proved though people don't mind downloading a multi-gig
        app anymore however, so maybe this is no longer an issue.
       
          leapingdog wrote 53 min ago:
          I have unknowingly bought commercial desktop software that turned out
          to be Java + SQLite under the hood. Don't know what they were using
          for UI.
       
          winrid wrote 2 hours 53 min ago:
          jpackage/jlink lets you distribute an exe, dmg, etc, with the JVM
          packaged inside. I have java desktop apps which are like 50mb.
       
          chromanoid wrote 3 hours 47 min ago:
          MCPs and complex CLI tools running locally/native via graalvm 
          might be a great usecase for Java.
          
   URI    [1]: https://quarkus.io/blog/mcp-server/
       
          smrtinsert wrote 4 hours 3 min ago:
          Bitwig and Intellij stand out to me
       
            exabrial wrote 3 hours 23 min ago:
            Yeah Intellij is incredible, and I believe it's Swing. And Eclipse
            is ambulatory, but the SWT/OSGI frameworks are fighting yesterday's
            battles. All of this aside, I yet to find this level of
            IDE/Debugger in any other language.
            
            I'll check out Bitwig.
       
        mring33621 wrote 4 hours 22 min ago:
        Maybe it's because I don't know anything about how claude plugins work,
        but I find it odd that there's no actual TS code in the mentioned repo:
        [1] There is a zip file of code in the releases though. I wonder if the
        LPGL 3.0 license covers that?
        
        UPDATE: the zip file is just the repo itself. So everything interesting
        is in the legalrabbit-docx-mcp.exe, contained in the GitHub releases.
        
        What a tease.
        
   URI  [1]: https://github.com/LegalRabbit-AI/legalrabbit-docx-claude-plug...
       
        shevy-java wrote 5 hours 1 min ago:
        > I wrote a lot of Ruby back in 2010s. I felt Ruby was a beautiful
        language. Unfortunately, I don't feel that anymore.
        
        Perhaps because he sucks.
        
        It's easy to write ugly code in any language. You need to think, in
        order to write good code, in any language. Even then some languages are
        uglier than others. All my PHP code looks awful in comparison to my
        ruby code. Even with the same expertise level, the issue remains that
        PHP is just an uglier language. Similar comparisons can be made for
        many other languages.
        
        > The biggest issue is no typing.
        
        Well ... it's not. But it is pointless to try to explain this people
        whose brain is too addicted to "mama told me types must go into
        everything I touch".
        
        > I worked at Stripe for 4.5 years, so I looked into integrating Sorbet
        
        There you go! This already tainted his ability to THINK.
        
        > Forgot .each in node.children.each do |x|. The error showed up as
        "unexpected nil" at a random place.
        
        Erm ... how can you forget this while claiming you write a lot of code
        in ruby?
        
        By the way, I almost never use the do/end synax. It helps me visually
        to use {}.
        
        A side effect is that:
        
            def foobar(
            i = node.children
              )
              i.each {|element|
            check_for_cats_in_this_container(element)
              }
            end
        
        will also be easier to visually notice missing things
        such as ".each" or ".map" or anything. Keep the structure
        simple at all times. And no, forgetting .each a lot - that
        is a bogus complaint. People using ruby for a little while
        don't really do such an error. But let's assume it is that
        way:
        
            def foobar(
            i = node.children
              )
              i {|element|
            check_for_cats_in_this_container(element)
              }
            end
        
        Well, that visually already looks wrong. What method
        did you want to run on the variable i here?
        
        > Forgot .children in node.children[i]. The error showed up as
        > "unexpected nil" at a random place.
        
        Mate - use methods. The guy seems to have written only spaghetti
        code in ruby. Definitely not "4.5 years of writing ruby". Nah.
        
        Also, "unexpected nil" - first, such an error does not exist, he
        probably means a nil. Second, why do you not check for nils
        properly? You don't need types for that. So the issue is you were
        lazy when writing the code. Understandable, but not a reason to 
        "I need types" as compensation for your own laziness here.
        
        > Using assert_raises in the test obscured a compilation error.
        
        What compilation actually? Then again someone who forgets .each,
        already disqualified here.
        
        >I used ruby_llm-mcp where the doc mentioned tool.input_schema but the
        latest version has renamed it to tool.params_schema (issue). It took me
        a while to figure out since there was no typing hint to help me with
        it.
        
        Sounds like a project with awful documentation. This is a problem with
        many ruby projects. For some reason ruby projects hate documentation,
        with a few exceptions. I never understood this. To me it seems writing
        ruby is fun, then nobody wants to write documentation. That's really
        stupid of those people who do. Please look at rack. This thing has no
        real documentation that is useful. Same with opal and ruby-wasm. Ruby
        hates documentation. It's my number #1 complaint too.
        
        I am fine with those admitting to this problem. Who I can not stand are
        the "the code is self-explanatory". This always leads me to assume the
        code is utter garbage. And this indeed is almost always the case so.
        
        > rubyzip: it has an obscure bug where it produced a corrupted DOCX
        file. I've encountered this bug with a DOCX file from our customers. I
        can't share the confidential file to the rubyzip author.
        
        Or it is a fake story. Is this AI generated text? The guy makes up
        things on the
        fly.
        
        People, please - stop using AI. It will slop zombify your brain.
       
          wiseowise wrote 3 hours 7 min ago:
          How do you manage to write completely sane messages in some threads
          and then come up with the most unhinged shit like this?
       
        mark_l_watson wrote 5 hours 15 min ago:
        Sometimes I see things that make me reevaluate assumptions I make. I am
        all in on flexibility using LLMs and agentic coding harnesses: I hate
        feeling locked down to one platform.
        
        Then I saw this in the article:
        
        >> I've discovered that Claude Desktop supports MCPB. The MCPB provides
        a Node runtime. Therefore, our application would only contain our code.
        This means the size of the application would be ~1MB.
        
        I don't know why this is so appealing to me but it is. I currently use
        Claude Code with a DeepSeek v4 Pro API backend. I will check out if
        Claude Code itself has MCPB support.
       
          jondwillis wrote 4 hours 41 min ago:
          > I will check out if Claude Code itself has MCPB support.
          
          It doesn’t.
       
        martinald wrote 6 hours 7 min ago:
        How is it surprising to people that zip and XML are in stdlibs for a
        programming language?
        
        Btw, you should have looked at dotnet for this as well. There is a very
        good library ( DocumentFormat.OpenXml) that can handle all
        docx/xlsx/pptx files. And dotnet can ship standalone binaries (though
        AOT probably won't work).
       
          rjrjrjrj wrote 3 hours 58 min ago:
          Difficult to square the author's surprise with the later comment "I
          have my fair share of building a Java desktop application and know
          jpackage and alike very well"
          
          You can't get very far in Java development without working with .jar
          files (which are zip archives).
       
          CharlieDigital wrote 4 hours 39 min ago:
           [1] First party from Microsoft; feels like it would be the way to
          go.
          
   URI    [1]: https://github.com/dotnet/Open-XML-SDK
       
            xnorswap wrote 3 hours 20 min ago:
            That is the source of DocumentFormat.OpenXml, you're talking about
            the same package, [1] Microsoft are incapable of:
            
                1. naming things well
                2. keeping those names stable
            
   URI      [1]: https://github.com/dotnet/Open-XML-SDK#packages
       
          pier25 wrote 4 hours 46 min ago:
          Many runtimes/languages rely on third party deps for that. Also
          plenty of devs think the stdlib should be as lean as possible.
          
          Personally, I think there should be a balance. The direct consequence
          of a barebones stdlib is NPM and having to download hundreds of
          dependencies for a hello world.
       
            wky wrote 3 hours 24 min ago:
            Golang has the golang.org/x packages, which avoids too much stdlib
            bloat while still providing the niceties of “pre-vetted”
            packages that don’t pull in a massive dependency tree.
       
              pier25 wrote 2 hours 20 min ago:
              yeah I wish Node had something like that
       
                slopinthebag wrote 22 min ago:
                It does! (well Deno does but you can use them in Node)
                
   URI          [1]: https://jsr.io/@std
       
        flossly wrote 6 hours 25 min ago:
        Nice to see Ruby vs Java. Must say that in this context Kotlin deserves
        a mention: my Kotlin code basically looks+feels like Ruby-with-types.
        Both Ruby and Kotlin are essentially OO, but with "lots of FP features
        where it makes sense".
        
        On the side of the jpackage: I'm currently using GraalVM compile to
        native for a Kotlin CLI tool. I do the build in a build container so I
        use an older glib to ensure compatibility on a wide variety of Linuxes,
        AND because this way no-one needs to install all the GraalVM
        requirements by hand. The result is a 57MB binary, that start in a
        blink of the eye. The downside is long compile times (2 minutes for a
        simple CLI tool that uses AWS SDK). I think I prefer this of jpackage;
        but I'm not building a GUI tool.
       
          pjmlp wrote 4 hours 52 min ago:
          Many of those "lots of FP features where it makes sense". were
          already present in Smalltalk.
          
          Especially anything related to lambdas, map, filter and co.
          
          Something that was lost in most OOP languages that followed suit,
          until like a decade later.
       
            flossly wrote 4 hours 44 min ago:
            > Many of those "lots of FP features where it makes sense". were
            already present in Smalltalk.
            
            Good point. And both Java and Ruby borrowed from Smalltalk
            (according to Wikipedia Kotlin does not, but that is: not directly.
            
            Sadly Java did not take Smalltalk's FP inspiration (I guess they
            were strayed by C++'s lead in that regard), and we needed streams
            and now Kotlin to fix that :)
            
            Smalltalk's syntax never go really popular though. One could say
            that was its biggest drawback.
       
              leapingdog wrote 1 hour 2 min ago:
              > Sadly Java did not take Smalltalk's FP inspiration (I guess
              they were strayed by C++'s lead in that regard)
              
              You guess correctly. Java was easy for C++ developers to learn
              which was beneficial for adoption at the time.
       
              giobox wrote 3 hours 7 min ago:
              > Smalltalk's syntax never go really popular though. One could
              say that was its biggest drawback.
              
              A lot of Smalltalk-style syntax was absolutely massive for a
              decade or so you could argue, at least under the guise of the
              gazillions of iPhone apps that were written in Objective-C. This
              random blog post probably does a better job than me:
              
              >
              
   URI        [1]: https://richardeng.medium.com/apple-has-been-using-small...
       
              lukan wrote 3 hours 17 min ago:
              "Smalltalk's syntax never go really popular though. One could say
              that was its biggest drawback."
              
              This would be my guess, I always heard nice things about it and
              liked many concepts, but the syntax was just plain ugly to me, so
              I never felt the urge to try it out. I imagine others felt
              similar.
       
        mike_hearn wrote 6 hours 50 min ago:
        There's Apache POI which is intended for working with Office documents,
        so directly using XML parsers might not be necessary.
        
        The MCPB format seems to be able to run external processes, even if
        there's a Node in the middle. So you could also compile the Java
        version to a native binary with GraalVM and ship that as an MCPB.
       
        vintagedave wrote 7 hours 14 min ago:
        > MCPB
        
        It's annoying when acronyms are used without explanation. It's [1] ,
        which looks a kind of installation bundle for MCP servers.
        
   URI  [1]: https://github.com/modelcontextprotocol/mcpb
       
          srcreigh wrote 4 hours 7 min ago:
          Some more info from the link:
          
          > MCP Bundles (.mcpb) are zip archives containing a local MCP server
          and a manifest.json that describes the server and its capabilities.
          The format is spiritually similar to Chrome extensions (.crx) or VS
          Code extensions (.vsix), enabling end users to install local MCP
          servers with a single click.
       
          wiseowise wrote 7 hours 5 min ago:
          Just scroll down a little bit. They link what MCPB is.
          
          > Later, I've discovered that Claude Desktop supports MCPB.
       
       
   DIR <- back to front page