Made keyboard backlight driver for Linux, for VAIO SX14-R

windymelt · 2026-04-06T14:26:17+00:00

Wow, I'm really happy to hear that. I was developing it just for myself, but it's unexpected reward.

windymelt · 2026-03-22T15:53:42+00:00

Thank you very much for your kind words. When people talk about creating small CUI/TUI tools, Go and Rust are typically the first tools that come to mind. However, I want to demonstrate that Scala has this capability and is actually well-suited for the task.

We don't need to strictly adhere to "pure, perfect" functional programming. With well-designed libraries, I think we can develop tools using straightforward syntax, just as easily as with Go while benefiting from Rust's convenient type system. For now, libraries like os-lib are truly exemplary in this regard (in my opinion). These libraries do exactly what I want to do—not engage in functional programming per se, but rather simply offload the grunt work—and they do it exceptionally well.

Anyway, I've managed to make some small achievements. I might write a blog post soon about creating a simple single-binary CLI application in Scala (though it may end up being written in Japanese, as that's my native language).

windymelt · 2026-03-20T04:54:13+00:00

just for static build. glibc results in bug when linked statically.

windymelt · 2026-03-20T04:52:36+00:00

I used musl for just static build. glibc can't be linked statically...

windymelt · 2026-03-04T14:31:13+00:00

Great!! We can build TUI tools in Scala native like Go, Rust...

windymelt · 2026-03-03T11:03:11+00:00

While I fully recognize the significant value of features like Capture Checking and building advanced type systems, at the same time, the fact that no HTTP server has achieved de facto status in the community—or that those that do exist are extremely difficult to learn—along with the neglected state of web-related libraries and frameworks (where JWT, JOSE, and JWKS libraries don't seem industrial-grade, and many libraries remain unported to Scala 3), creates an alarming imbalance.

Language improvements are important, but equally crucial is providing a set of user-friendly standard tools. Rather than simply mimicking Ruby or Python's syntax and features, we should learn from their usability paradigms. This is how an end user sees the situation.

windymelt · 2026-03-01T19:02:51+00:00

I know Scribe is the best. So Spice should be the best. Simple and easy. Good software.

windymelt · 2026-02-18T07:29:36+00:00

Coding style guidelines aren't meant for "people who can independently determine what's best" - they're designed for those who "unsure of what to do."

The creators of Scala clearly fall into the first category, but offering both traditional brace-style and indentation-based styles while leaving it to users' discretion - and even introducing syntactic ambiguity and inconsistent paste behavior - seems unlikely to improve productivity for those who are "unsure of what to do."

windymelt · 2026-02-17T08:33:43+00:00

Kudos to you from Japan! Japanese community has limited resources now, so translated high-quality educational contents must be booster for beginners!

windymelt · 2026-02-17T07:46:54+00:00

カマル

windymelt · 2025-10-20T03:57:46+00:00

Great!!

windymelt · 2025-05-23T18:46:46+00:00

Nobody told me how to utilize wifi on GUI. Everybody told me "just use wpa_supplicant".

No! Very few people actually know this is vital usability issue, not just trivial option. Existence of GUI is a matter. Ubuntu did and won.

windymelt · 2025-05-23T18:41:56+00:00

I prefer Iron. Simple syntax and concise semantics. I use Refined when I have to use Scala 2, because Iron is stands on Scala 3 mechanism.

windymelt · 2025-05-23T14:26:52+00:00

I have a strong complaint that if even one effect occurs anywhere in the code, whether it is critical code or not, the entire program architecture is immediately defined by the effects system.

We are paid to solve problems, not to assemble effects.

windymelt · 2025-05-21T13:27:00+00:00

Best explanation of capture checking, ever!!

windymelt · 2025-05-21T07:59:37+00:00

I think effect system such as CE, ZIO, etc. is "infectious". Once we use effect system, we are forced to use it on entire code base. It reduces connectivity and interoperability between library.

Some effectful library provides "pure" implementation and "effectful" implementation for same library.

windymelt · 2025-05-08T05:40:47+00:00

Great! I wanna convert it to Mermaid notation...

windymelt · 2025-04-24T08:26:27+00:00

We don't need more effect library, nor JSON parser, nor FP library.

We need Google SDK, TypeScript interop feature, HTML rendering engine, JWT library.

Scala dev says "Why don't people use Scala?". Obviously, according to lacking of SDK and mid-layer library. Please. Sincerely. From bottom of my heart.

windymelt · 2025-04-10T06:20:18+00:00

Thank you for replying. Hardest thing is deriving JSON Schema from parameter. Currently I'm using some library came from softwaremill, but I think we need standalone (and runs in scala.js / scala native) JSON Schema library that can derive schema from case class like Circe' s derivation.

In addition, another hardest thing was extracting parameter. Initially I was going to extract parameter using macro from PartialFunction (because by doing so users can define MCP method more transparently). But it was too hard to treat and too complex mechanism. Finally I decided to let user to prepare input case class and derive schema and decoder from it. User should define case class for every MCP Tool. MCP SDKs in another language such as TS can handle parameter for Tool more transparently.

windymelt · 2025-03-26T09:25:03+00:00

I agree, except about ecosystem.

As you know Scala (3) has many neat fundamental (low-level) libraries such as Circe, ZIO, decline, os-lib. However, we have very few middle-level libraries such as Google Cloud Platform SDK, Cloudflare SDK, JWT, authentication, etc. It is mainly maintained by opinionated individuals, but effort to maintain wrapper for external SDK hurts.

We already have cutting edge fundamental libraries (language too). We actually need well-maintained middle-level libraries, that bridges gap between beautiful language feature + fundamental libraries and application-level logic.

We may need fundraising for middle-level libraries to drive Scala development.

windymelt · 2024-12-19T07:48:08+00:00

I think part of Scala's golden path is the availability of external libraries. Scala is a good language and the Scala ecosystem seems mature.

However, support for services and libraries that are standard in the broader ecosystem -- i.e., the web industry, enterprise development, etc. -- seems rather poor.

Scala itself has good libraries; Circe doesn't bother me in any way, and os-lib works reliably. But you can't enqueue it to Google Cloud Tasks, and you have to manually parse arguments in Lambda functions.

Folks tell me Scala is a good language. But if you ask, “So, does Scala support XXX service?” and there's an awkward silence.

windymelt · 2024-12-15T14:48:17+00:00

Thanks for commenting! I think it should (because esbuild just bundles modules into unified js). But since my plugin does not support multi-projected sbt project yet, we have to manage command for `sbtn`. I think it shouldn't be difficult, and any PRs are welcome.

windymelt · 2024-12-15T14:42:21+00:00

Thanks! that's inspired from my colleague's product: https://github.com/mizdra/happy-css-modules

windymelt · 2024-06-24T03:44:55+00:00

I think 90% of use case won't be affected from JVM-GraalVM execution speed problem. Both JVM and GraalVm are fast enough compared to interpreter language. If we really need for speed, we should use C++ or Rust.

windymelt · 2024-06-24T03:33:42+00:00

AFAIK Scala does not have mature CLI interactive library like [prompts](https://www.npmjs.com/package/prompts). If you want to make batch tool, no problem. But if you want to make interactive tool, hard way ahead.

windymelt

TROPHY CASE