I recently ran into some problems with java development. One problem was neovim specific but the other was an issue with gradle. I wanted to document these in case any one else has similar problems as it took me a little bit of time to figure out.

Problem 1: jdtls exiting with status code 13

I use jdtls through Mason with the built in nvim LSP and was recently having an issue where jdtls would immediately crash when opening a file. The solution to this problem was just deleting the cache for jdtls:

In my current position I’ve had to swap to full time Rust development. After about 2 months of full time Rust development I think I’ll likely be developing projects in Rust in the future instead of C++ when performance is important. My reasons for this are primarily:

1. Just Works™ build system and crates.io makes drawing in libraries painless
2. Guaranteed memory safety is pretty nice
3. Syntax is much cleaner and succinct than C++, with lots of nice syntax sugar to sweeten the package
4. Easily integrable with C (and therefore C++ with some massaging)
5. Proc macros are pretty nice as well
6. Built-in test framework

I think that point 3 is potentially the biggest factor for me as the C++ modern syntax is not what I would consider clean, especially if you are trying to use a more functional programming style. A simple example highlighting the difference:

At my previous employment I was forced to use a windows system. Although not ideal, I was able to continue using my Linux terminal workflows by heavily utilizing Windows Subsystem for Linux. As part of this I had to get comfortable with integrating tmux into my workflow as I didn’t care to learn the Windows Terminal options for terminal multiplexing. I don’t need tmux quite as much anymore since my current employer allows me run Linux on my development machine, but I still use it when remoting into my work desktop via ssh. Hopefully this can be of use in improving the efficiency of others that depend on terminal based workflows.

I’m currently working on developing an implementation of the Concurrent Atomistic-Continuum method using C++ and CUDA to accelerate calculations. A need arose to use valgrind for debugging some memory issues. I currently run Artix Linux and it turns out that both Artix Linux and Arch Linux have fully removed all debug packages from their repositories and have swapped over to a debuginfod style system. On my system, said debuginfod was working with gdb but not with valgrind. In particular I was missing the debug symbols for glibc which prevented valgrind from working at all. I had to try a few things before I got it working so I want to share how I did. I also want to mention an issue I ran into if any guys from Artix Linux ever end up reading this post.

I recently had a situation where a library I was working on, originally as part of one project, was going to be needed for another project. The ideal way to handle this situation, is to have the library files as their own git repo which is then added to the projects as a submodule. This way any changes required to the submodule for the needs of each project can be shared easily. It took me much longer than I would’ve liked to, but I finally managed to find the solution and wanted to share it with anyone else who might need it.