Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin

tanin.nanakorn.com

Post reply on HN
Print view View original

21–30 of 51 posts

Re: Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin

#21

Post by chromanoid »

exabrial wrote: post #17

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.

MCPs and complex CLI tools running locally/native via graalvm might be a great usecase for Java. https://quarkus.io/blog/mcp-server/

Re: Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin

#22

Post by wky »

pier25 wrote: post #11
martinald wrote: post #6

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).

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.

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.

Re: Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin

#23

Post by exabrial »

smrtinsert wrote: post #18
exabrial wrote: post #17

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.

Bitwig and Intellij stand out to me

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.

Re: Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin

#24

Post by [deleted] »

CharlieDigital wrote: post #14
martinald wrote: post #6

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).

https://github.com/dotnet/Open-XML-SDK First party from Microsoft; feels like it would be the way to go.

[deleted]

Re: Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin

#25

Post by xnorswap »

CharlieDigital wrote: post #14
martinald wrote: post #6

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).

https://github.com/dotnet/Open-XML-SDK First party from Microsoft; feels like it would be the way to go.

That is the source of DocumentFormat.OpenXml, you're talking about the same package, https://github.com/dotnet/Open-XML-SDK#packages

Microsoft are incapable of:

    1. naming things well
    2. keeping those names stable

Re: Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin

#26

Post by lukan »

flossly wrote: post #12
pjmlp wrote: post #10

Earlier quoted context omitted.

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.

> 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 po…

"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.

Re: Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin

#28

Post by wiseowise »

shevy-java wrote: post #9

> 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 th…

How do you manage to write completely sane messages in some threads and then come up with the most unhinged shit like this?

Re: Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin

#29

Post by giobox »

flossly wrote: post #12
pjmlp wrote: post #10

Earlier quoted context omitted.

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.

> 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 po…

> 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:

> https://richardeng.medium.com/apple-has-been-using-smalltalk...

Post reply on HN