HackerTrans
トップ新着トレンドコメント過去質問紹介求人

revetkn

316 カルマ登録 17 年前
software from the philly burbs

投稿

Show HN: Soklet, a zero-dependency Java HTTP/1.1 and SSE virtual-threaded server

soklet.com
2 ポイント·投稿者 revetkn·6 か月前·0 コメント

コメント

revetkn
·7 日前·議論
Yes - the JdbcClient API has a similar feel for sure. If you are using Spring, it is a better choice than Pyranid because it integrates well with the Spring txn plumbing. Outside of Spring, I think Pyranid has a lot of advantages.
revetkn
·21 日前·議論
I did not really understand CORS until I sat down and wrote a server implementation of it and had to think hard about "what hooks should be exposed to developers for controlling it?"

Most of us I think just "expose a set of whitelisted origins and be done with it".

Here is where I landed for how to specify your server's CORS policy:

https://soklet.com/docs/cors#custom-workflow
revetkn
·22 日前·議論
There is no public-facing continuations API afaik.

Structure concurrency/virtual threads seem like a good fit for Swing; just have your event handler fire off virtual thread[s] and do your work and call SwingUtilities.invokeLater to schedule the result to be applied on the event loop thread when you're done. Structured concurrency simplifies managing groups of concurrent tasks, cancelation, etc.
revetkn
·23 日前·議論
Regarding "What's wrong with what .NET did with threads?", see https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html (relevant part below):

  An alternative solution to that of fibers to concurrency's simplicity vs. performance issue is known as async/await, and has been adopted by C# and Node.js, and will likely be adopted by standard JavaScript. Continuations and fibers dominate async/await in the sense that async/await is easily implemented with continuations (in fact, it can be implemented with a weak form of delimited continuations known as stackless continuations, that don't capture an entire call-stack but only the local context of a single subroutine), but not vice-versa.

  While implementing async/await is easier than full-blown continuations and fibers, that solution falls far too short of addressing the problem. While async/await makes code simpler and gives it the appearance of normal, sequential code, like asynchronous code it still requires significant changes to existing code, explicit support in libraries, and does not interoperate well with synchronous code. In other words, it does not solve what's known as the "colored function" problem.
Regarding Swing, virtual threads are "just" threads so no reason they (and structured concurrency) can't be used.
revetkn
·2 か月前·議論
I find papers like this strange for the same reason. Maybe I'm missing something...
revetkn
·5 か月前·議論
My project Lokalized attempts to solve many of these complex plural/gender/ordinal/etc. rules with a tiny expression language:

https://lokalized.com
revetkn
·6 か月前·議論
https://revetkn.com
revetkn
·7 か月前·議論
I like the fluent API - this looks like a much better way to work with ResourceBundle types than Java's out-of-the-box support. Thanks for sharing.
revetkn
·7 か月前·議論
In my experience, LLMs are terrific for most translation tasks, but you still need a way to encode the data (rules for genders, cardinalities, ordinalities, ...) for storage on disk/database/etc. for 1. performance and 2. consistency/durability. So LLMs are a big part of the solution, but not the whole picture.
revetkn
·7 か月前·議論
My project, Lokalized (from 2017, in Java), has the same goal but took a different approach to the "little language" design. I'm guessing I had the same inspiration as the Fluent authors - existing solutions were just not expressive enough for the real world. Mentioning here because I'm always super interested in seeing how others approach the problem of effective i18n (it's a bit complex). Making Fluent more of a spec was the right call imo; I did not do that with my work.

https://lokalized.com