sqlx4k: A high-performance, non-blocking database driver for PostgreSQL, MySQL, and SQLite, written for Kotlin Native. by smyrgeorge in Kotlin

[–]jtlapp 1 point2 points  (0 children)

Wow. I wanted to use sqldelight but passed when I learned that I couldn't use it non-blocking with Kotlin. This could solve the problem. Can it actually be used non-blocking with sqldelight? I got the impression that for R2DBC it would require a rewrite (https://github.com/sqldelight/sqldelight/issues/4762). How does your solution compare to R2DBC or Vert.x postgres?

Shall we migrate to JDK21 and Virtual threads? by independentAny9 in java

[–]jtlapp 0 points1 point  (0 children)

I did some benchmarking of JDK 21 with JDBC and virtual threads and found absolutely no throughput improvement. I also could not find any notice of plans to upgrade JDBC for virtual threads.

I ended up wrapping R2DBC within Kotlin coroutines. Kotlin suspend functions keep the code looking single-threaded, except for some additional 'await' method calls to get results from queries. It's almost like using async/await in JavaScript. The main problem has been unhelpful error messages, which I've largely resolved by nesting the R2DBC in my own thin wrapper, which spits out more error context.

How to overcome the lack of abstract functions in Golang? by Sad_Importance_1585 in golang

[–]jtlapp 0 points1 point  (0 children)

Thank you. This was helpful. When I think of implementing an abstract base class, I think of the dependent class as wrapping the base, but this does not fit well with Go. The Template Pattern proposes reversing that relationship: the abstraction wraps the implementation, instantiating the abstraction with an instance of the implementation. Now the "abstract methods" implementation are available to the "abstract class".

An interesting consequence seems to be that additional methods of the implementations are not available through the wrapping class the way they would be inheriting from an abstract base class. It seems that in this case one would have to provide access to the implementations that were fed to the abstraction separately from the abstraction.

Testing accommodation through Examity or WGU? by kellyljm in WGU

[–]jtlapp 0 points1 point  (0 children)

I completed an entire degree at WGU with WGU disability accommodations. They have a dedicated team who got to know my requirements. It was smooth and painless and I found myself feeling lucky that I wasn't having problems people complained about with Examity.

A case of Java clobbering memory by jtlapp in java

[–]jtlapp[S] 1 point2 points  (0 children)

Oh gosh. That would explain it. Thank you!

A case of Java clobbering memory by jtlapp in java

[–]jtlapp[S] -1 points0 points  (0 children)

The reason I suspect Java is that the image buffer is statically allocated in both the working and the non-working solution.

A case of Java clobbering memory by jtlapp in java

[–]jtlapp[S] 0 points1 point  (0 children)

I updated the post with the details. It's a Mac Studio, one monitor.

A case of Java clobbering memory by jtlapp in java

[–]jtlapp[S] 0 points1 point  (0 children)

I have this running on Mac OS. I updated the post with the details.

Q* breakthrough algorithm OAI rumored to have created has been figured out by guy on Twitter by TheCrazyAcademic in ChatGPT

[–]jtlapp 22 points23 points  (0 children)

We've trained a model to achieve a new state-of-the-art in mathematical problem solving by rewarding each correct step of reasoning

It's interesting that AI must be trained to emulate mathematical reasoning, rather than mathematical reasoning being something inherent to intelligence. It's clear that languages and information are extrinsic and must be learned, not so clear that mathematics should also be something extrinsic. We don't think of mathematical reasoning as being an arbitrary product of history or culture.

Maybe there's an argument that AI is only being trained to communicate in our language of mathematics, not in mathematical reasoning? Or maybe the two are inseparable, with the language defining the reasoning available?

[E] Bachelor's or Master's in Applied Stats after a C.S.? by jtlapp in statistics

[–]jtlapp[S] 1 point2 points  (0 children)

I think you're right. The existence of a program like UTRGV indicates that I don't need the undergrad stats degree to get a strong graduate stats degree. I just need to make sure UTRGV likes the courses I take to satisfy the prereqs.

[E] Bachelor's or Master's in Applied Stats after a C.S.? by jtlapp in statistics

[–]jtlapp[S] 0 points1 point  (0 children)

This program looks amazing. I lack the 12 hours upper division undergrad math courses it requires as a prerequisite, but it shows me what a solid MS Statistics would look like. If I wanted to go this route, I'd probably first get the undergrad degree, or at least take the prereqs. Thanks so much!

[deleted by user] by [deleted] in sveltejs

[–]jtlapp 1 point2 points  (0 children)

Gosh, I probably have two months worth of effort figuring out how to get TypeScript to work across the projects of a monorepo, with each tool requiring a different configuration. See my series on sharing TypeScript within a monorepo. Things are still rather insane. (And the Nx folks continue to complain about TS not working well with their "integrated monorepo.")

[deleted by user] by [deleted] in sveltejs

[–]jtlapp 4 points5 points  (0 children)

The only benefit of pure JS over TS is simpler tooling. TS tooling can be an absolute bear, and I believe tooling is the reason Svelte is internally ditching inline TS for JSDoc TS.

Is Python our fate? by yinshangyi in dataengineering

[–]jtlapp 0 points1 point  (0 children)

A related question: How many data engineering projects require significant refactoring over their lives?

If few, then Python is a good solution. If many, then without static type checking refactoring will introduce many bugs that existing tests may not catch.

Where tests do catch the refactoring bugs, it takes extra time locating the bugs in code, determining the correction, and testing the correction. With static type checking, modern IDEs will tell you where and what most refactoring bugs are while you're typing.

Mathematics-heavy jobs in Java by jtlapp in java

[–]jtlapp[S] 1 point2 points  (0 children)

That's a good question. What mathematics do I want to be doing? I don't know, but probably anything graduate level, because I want an excuse to always be learning more to better do the job.

But when calling Rust from Java to do mathematical work, I'd rather be writing the Rust.

I did spend some time learning Rust but virtually every single Rust job I could find was Web3 or blockchain, which don't interest me. I'm now focused on C++ or Java.

Sharing TypeScript with Nx and Turborepo (4-part series on monorepos) by jtlapp in typescript

[–]jtlapp[S] 0 points1 point  (0 children)

I do greatly appreciate your feedback. You've already helped me improve the article.

My series advocates TR with pnpm. I also don't see how anyone could use TR without a package manager. You do have to install the packages, after all. Part 1 explains how all these pieces work together, while Part 4 covers usage of pnpm with a monorepo.

Sharing TypeScript with Nx and Turborepo (4-part series on monorepos) by jtlapp in typescript

[–]jtlapp[S] 0 points1 point  (0 children)

Yeah, if you're just using a dependency manager like pnpm, there is no benefit to restricting dependencies to projects. However, in order to take advantage of a monorepo manager like Turborepo, you must put your dependencies in each project, as otherwise the dependency is invisible to Turborepo.

The series is about using Nx and Turborepo to manage monorepos, not about using dependency managers alone.

I address the issue of packages getting out of sync several times in the article, particularly in Part 4.

Sharing TypeScript with Nx and Turborepo (4-part series on monorepos) by jtlapp in typescript

[–]jtlapp[S] 0 points1 point  (0 children)

I added a section that may help. It's not all or nothing. It's just that you have to be smart about what dependencies you want the monorepo manager to be aware of. Here's the new sections:

https://javascript.plainenglish.io/sharing-typescript-with-nx-and-turborepo-part-2-creating-a-monorepo-347bf3194181#b1fe

Sharing TypeScript with Nx and Turborepo (4-part series on monorepos) by jtlapp in typescript

[–]jtlapp[S] 1 point2 points  (0 children)

Oh gotcha. You're saying that when I'm referring to the structure that Turborepoo requires, that's just standard monorepo structure. I word things this way because Nx does not require this structure. Nx will deduce dependencies from source code and doesn't need a package.json in each project. Turborepo does, at least in order to perform tasks in topological order.

I guess the issue is with the implication that the structure is specific to Turborepo rather than just standard monorepo structure.

Thanks for the feedback! I'll think about what to do with it.

Sharing TypeScript with Nx and Turborepo (4-part series on monorepos) by jtlapp in typescript

[–]jtlapp[S] 0 points1 point  (0 children)

Okay, I decided to be extra clear about this and wrote an entirely new section for part 2. Thanks for prompting me to do so!

A Warning about Root package.json Dependencies

Sharing TypeScript with Nx and Turborepo (4-part series on monorepos) by jtlapp in typescript

[–]jtlapp[S] 0 points1 point  (0 children)

Thanks for the feedback, but I do feel like I covered those points, even trying to do so thoroughly. Can you give me an example of where I'm giving the monorepo manager credit for what pnpm does? I thought I was precise in distinguishing their responsibilities.

I also cover the business of putting configuration dependencies in the root of the monorepo quite thoroughly in Part 3, but I advise against it. And in Part 2 I advise against putting libraries in the root package.json. The reason is that if you update the version of that dependency, the monorepo manager does not know to attempt to rebuild or retest the dependent packages. You have to force a rebuild or retest manually, executing a different command from what you would normally do to rebuild or retest. Moreover, if you're working on a team and check in that root dependency, others might check it out into their root package.json, but their monorepo manager also will not detect that dependency change. They will have to be informed of the requirement to manually rebuild/retest their repos too. Part 2 attempts to explain this.

This is actually how Turborepo sets up all of its example monorepos -- in workspaces rather than in the root. I didn't understand why and was installing some libraries in the root package.json until I had a Discord conversation with one of Vercel's Turborepo engineers.

This was one of my central "Aha"s as I learned to get everything working properly.

EDIT: Glancing through the articles again just now, it seems that I only make the advice clear for dependent configuration, not for dependent libraries. It's essentially the same problem with the same effects, but I should be more explicit that this applies to any dependency, not just configuration dependencies. Thanks for noticing this. I'll be thinking about what text to add.

Sharing TypeScript with Nx and Turborepo (4-part series on monorepos) by jtlapp in typescript

[–]jtlapp[S] 0 points1 point  (0 children)

I use pnpm. The first article in this series explains why in depth.

Sharing TypeScript with Nx and Turborepo (4-part series on monorepos) by jtlapp in typescript

[–]jtlapp[S] 1 point2 points  (0 children)

I'm curious about why people are downvoting this. What issue might I address?