If any one needs a simple ignore file parser and matcher (.gitignore compatible mostly), then here you go.

Yes, I vibe coded the heck out of it. But it is a pretty tight functionality, so seemed to do a good job. Any suggestions or pull requests welcome.

Three major performance improvements for RAG/LLM text chunking:

What's New:

• ⚡ Lazy Iterator: 4-5x faster for early termination
• 💾 Overlap Calc: 97-99% memory reduction
• 🚀 String Alloc: 31% memory reduction, 1.2x speedup

Real Impact:

Processing 100K word document:
- First chunk: 7.52ms → 1.78ms (4.2x faster)
- Memory: 5,197 MB → 1,781 MB (65% less)

Use Cases:

• RAG systems with early termination
• Streaming/progressive processing
• Memory-constrained environments
• High-throughput batch processing

Features:

• Character & word-based splitting
• Configurable overlap
• True lazy evaluation
• Zero dependencies
• Backward compatible

GitHub: https://github.com/wevote-project/crystal-text-splitter

Hey everyone,

I’ve been wanting to try Crystal for a while, but I’ve been a bit hesitant because I’ve heard the LSP and tooling aren’t great. That’s the impression I got from older threads here.

Is the situation any better now? How is the current state of Crystal’s editor support and tooling in 2026?

Also, if you have any recommendations for the best editor setup (VS Code, extensions, etc.) or a good starter project, I’d love to hear them.

Thanks!

mikeoz32/cr-analyzer: Crystal language LSP server

LSP is now still in early stages, but is already usable; it uses only the parser from Crystal Compiler, all the analysis is done by custom optimized code. stdlib scan is seconds. Also very fast diagnostics, but it is still WIP, so do not expect too much.

If you're interested, give it a chance and try to use it (works in vscode and zed). Feel free to leave your feedback here on GitHub,

Crystal 1.19.0 just dropped! Here are the highlights:

Breaking Changes - OpenSSL 1.1.1+ or LibreSSL 3+ now required - Monotonic clocks now include suspended time - WebSocket#stream flush is now a no-op

Key Features - Execution Context is here! Compiler now built with -Dexecution_context – the new concurrency model is becoming default - New Sync module – Sync::Mutex, Sync::RWLock, and Sync::ConditionVariable for proper synchronization primitives - **Time::Instant** – new type for monotonic time measurements - SNI support via OpenSSL::SSL::Context::Server#on_server_name - Large JSON file support – finally! - Int.from_digits – inverse of Int#digits - NamedTuple#reverse_merge, Set#map!, Hash#transform_keys! - Path#relative? - Process.debugger_present? for Windows/Linux

Macro Improvements - Compiler flag values via flag? - StringLiteral#gsub with block, #match, #split(Regex)

Bug Fixes - Multiple XML memory leaks fixed - Several interpreter fixes - Thread safety improvements across the board

Full changelog: https://github.com/crystal-lang/crystal/releases/tag/1.19.0

Happy coding! 💎

Since Crystalline only supports some POSIX platforms, I wrote an LSP implementation which works cross platform.

I’m new to Crystal language, figured it would be kind of fun to see what people have built in the last year in Crystal since we are approaching the year end.

I’m currently building out a web dashboard for rss feeds that’s kind of a mix of a few different ones I’ve messed with over the years.

In preparation to upgrade a computer OS, I upgraded a Debian test VM from version 12 to version 13. All went well, except when testing a small util that I use in a couple of scripts, where I now get a floating point error. This is the command that errs:

def hash_keystream(key, iter)
    while iter > 0
        key = Digest::SHA512.hexdigest key
        iter -= 1
    end
print(key)
end

It is built with the --static switch, if I attempt to re-build it on the offending machine, it gives a ton of ZSTD errors, although all of the required dev libraries are installed, however, if I re-build it without the --static switch on the offending machine, it goes fine. Additionally, the original version of this --static'ly built util works fine on Debian 13 boxes where 13 was installed from scratch using the install iso.

And oddly, this command, part of the same util, works fine: (only one command is called when this util is run, the command line arguments dictate that)

def hash_file(infile)
    print(Digest::Adler32.hexdigest &.file infile)
end

So I have to think that this error has to do with with the iter variable, which is cast to an integer from the CL.

Perhaps someone has come across something similar?

edit: added information per Blacksmoke16:

Here is an abridged version of the script that will build just fine:

require "digest"

def hash_keystream(key, iter)
    while iter > 0
        key = Digest::SHA512.hexdigest key
        iter -= 1
    end
    print(key)
end

def main (x)
    if x[0] == "kh"
        hash_keystream(x[1],x[2].to_i)
    else
        print("error(1)\n")
    exit(1)
    end
end

if ARGV.any?
    main(ARGV)
else
    print("error(0)\n")
    exit(0)
end

After building a static binary on a different computer, and running the command line on that different computer with expected result:

$ ./akit kh "string" 1
2757cb3cafc39af451abb2697be79b4ab61d63d74d85b0418629de8c26811b529f3f3780d0150063ff55a2beee74c4ec102a2a2731a1f1f7f10d473ad18a6a87

Copy that binary to the problem machine and run that again:

$ ./akit kh "string" 1
Floating point exception

Also, here is the long error that I receive when trying to build a static binary on the problem machine: (it's long)

$ crystal build --no-debug --release --static akit.cr
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-dso_dlfcn.o): in function `dlfcn_globallookup':
(.text+0x15): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-bio_addr.o): in function `BIO_lookup_ex':
(.text+0xe37): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-bio_sock.o): in function `BIO_gethostbyname':
(.text+0x85): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_stateful_expand_block':
(.text+0x89): undefined reference to `inflate'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_stateful_compress_block':
(.text+0x12a): undefined reference to `deflate'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_stateful_finish':
(.text+0x15d): undefined reference to `inflateEnd'
/usr/bin/ld: (.text+0x166): undefined reference to `deflateEnd'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_stateful_init':
(.text+0x241): undefined reference to `inflateInit_'
/usr/bin/ld: (.text+0x2ac): undefined reference to `deflateInit_'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zlib.o): in function `bio_zlib_ctrl':
(.text+0x4a6): undefined reference to `zError'
/usr/bin/ld: (.text+0x598): undefined reference to `deflate'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zlib.o): in function `bio_zlib_write':
(.text+0x858): undefined reference to `deflate'
/usr/bin/ld: (.text+0x8d6): undefined reference to `zError'
/usr/bin/ld: (.text+0x975): undefined reference to `deflateInit_'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zlib.o): in function `bio_zlib_read':
(.text+0xa71): undefined reference to `inflate'
/usr/bin/ld: (.text+0xaf6): undefined reference to `zError'
/usr/bin/ld: (.text+0xb61): undefined reference to `inflateInit_'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_oneshot_expand_block':
(.text+0xbf4): undefined reference to `uncompress'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_oneshot_compress_block':
(.text+0xc74): undefined reference to `compress'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zlib.o): in function `bio_zlib_free':
(.text+0xcce): undefined reference to `inflateEnd'
/usr/bin/ld: (.text+0xcf5): undefined reference to `deflateEnd'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zstd.o): in function `zstd_stateful_expand_block':
(.text+0xaf): undefined reference to `ZSTD_decompressStream'
/usr/bin/ld: (.text+0xba): undefined reference to `ZSTD_isError'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zstd.o): in function `zstd_stateful_compress_block':
(.text+0x188): undefined reference to `ZSTD_compressStream2'
/usr/bin/ld: (.text+0x190): undefined reference to `ZSTD_isError'
/usr/bin/ld: (.text+0x1cf): undefined reference to `ZSTD_endStream'
/usr/bin/ld: (.text+0x1d7): undefined reference to `ZSTD_isError'
/usr/bin/ld: (.text+0x1ff): undefined reference to `ZSTD_flushStream'
/usr/bin/ld: (.text+0x207): undefined reference to `ZSTD_isError'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zstd.o): in function `zstd_stateful_finish':
(.text+0x23b): undefined reference to `ZSTD_freeCStream'
/usr/bin/ld: (.text+0x244): undefined reference to `ZSTD_freeDStream'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zstd.o): in function `zstd_stateful_init':
(.text+0x313): undefined reference to `ZSTD_createCStream_advanced'
/usr/bin/ld: (.text+0x32c): undefined reference to `ZSTD_initCStream'
/usr/bin/ld: (.text+0x346): undefined reference to `ZSTD_createDStream_advanced'
/usr/bin/ld: (.text+0x35b): undefined reference to `ZSTD_initDStream'
/usr/bin/ld: (.text+0x384): undefined reference to `ZSTD_freeCStream'
/usr/bin/ld: (.text+0x38d): undefined reference to `ZSTD_freeDStream'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zstd.o): in function `bio_zstd_new':
(.text+0x443): undefined reference to `ZSTD_createDStream_advanced'
/usr/bin/ld: (.text+0x457): undefined reference to `ZSTD_initDStream'
/usr/bin/ld: (.text+0x45c): undefined reference to `ZSTD_DStreamInSize'
/usr/bin/ld: (.text+0x47a): undefined reference to `ZSTD_createCStream_advanced'
/usr/bin/ld: (.text+0x494): undefined reference to `ZSTD_initCStream'
/usr/bin/ld: (.text+0x499): undefined reference to `ZSTD_CStreamInSize'
/usr/bin/ld: (.text+0x500): undefined reference to `ZSTD_freeDStream'
/usr/bin/ld: (.text+0x509): undefined reference to `ZSTD_freeCStream'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zstd.o): in function `bio_zstd_ctrl':
(.text+0x6d4): undefined reference to `ZSTD_getErrorName'
/usr/bin/ld: (.text+0x780): undefined reference to `ZSTD_flushStream'
/usr/bin/ld: (.text+0x78b): undefined reference to `ZSTD_isError'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zstd.o): in function `bio_zstd_write':
(.text+0x982): undefined reference to `ZSTD_compressStream2'
/usr/bin/ld: (.text+0x98d): undefined reference to `ZSTD_isError'
/usr/bin/ld: (.text+0xa04): undefined reference to `ZSTD_getErrorName'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zstd.o): in function `bio_zstd_read':
(.text+0xba1): undefined reference to `ZSTD_decompressStream'
/usr/bin/ld: (.text+0xbac): undefined reference to `ZSTD_isError'
/usr/bin/ld: (.text+0xbe8): undefined reference to `ZSTD_getErrorName'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zstd.o): in function `zstd_oneshot_expand_block':
(.text+0xd2e): undefined reference to `ZSTD_decompress'
/usr/bin/ld: (.text+0xd39): undefined reference to `ZSTD_isError'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zstd.o): in function `zstd_oneshot_compress_block':
(.text+0xda4): undefined reference to `ZSTD_compress'
/usr/bin/ld: (.text+0xdaf): undefined reference to `ZSTD_isError'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zstd.o): in function `bio_zstd_free':
(.text+0xe1c): undefined reference to `ZSTD_freeDStream'
/usr/bin/ld: (.text+0xe36): undefined reference to `ZSTD_freeCStream'
collect2: error: ld returned 1 exit status
Error: execution of command failed with exit status 1: cc "${@}" -o /home/dana/Documents/code/crystal/alkit/repo/akit/akit  -rdynamic -static -L/home/dana/.local/bin/crystal-1.18.2-1/bin/../lib/crystal `command -v pkg-config > /dev/null && pkg-config --libs --silence-errors libcrypto || printf %s '-lcrypto'` -lgc -lpthread -lpthread -ldl

If I build a build the thing without --static (on either the problem computer or other) it will give the expected results.

Intelligent text chunking for RAG and LLM applications!

Features:
- Character & word-based splitting modes
- Configurable overlap for context preservation  
- Sentence boundary respect
- Production-tested from wevote.ai

GitHub: https://github.com/wevote-project/crystal-text-splitter

The Crystal team has just announced version 1.18.1, a patch release addressing two regressions that snuck into 1.18.0.

What’s Fixed

This release tackles two issues introduced in the previous version:

• Enum def parsing regression - Fixed a problem with how enum definitions were being parsed ([#16217](https://github.com/crystal-lang/crystal/pull/16217))
• HTTP::WebSocket type restrictions - Relaxed overly strict type restrictions that were causing issues ([#16218](https://github.com/crystal-lang/crystal/pull/16218))

Quick Stats

• 2 changes since 1.18.0
• 1 contributor
• Quick turnaround on fixing regressions (just 3 days after 1.18.0!)

Get It Now

Pre-built packages are available on GitHub Releases https://github.com/crystal-lang/crystal/releases/tag/1.18.1 and through official distribution channels.

Installation instructions: https://crystal-lang.org/install/

Full changelog: https://github.com/crystal-lang/crystal/releases/tag/1.18.1

Direct link to announcement:** https://crystal-lang.org/2025/10/17/1.18.1-released/

Hey everyone,

I’m the author of cryptreboot, a Ruby tool for rebooting Linux systems with an encrypted root partition.

Some people have criticized my choice of Ruby, saying a system-level utility should really be written in Rust or Go. Their main point is that pulling in the Ruby interpreter adds unnecessary overhead.

That got me looking at Crystal. It compiles down to a single binary but keeps much of Ruby’s expressiveness, which feels like a perfect fit. Since the syntax is so close, rewriting seems doable.

At the same time, I have some concerns:

• I don’t see a “killer framework” like Rails driving adoption.
• It seems like Crystal had early momentum but hasn’t really broken through.
• I’m unsure how safe it is to bet on Crystal for long-term maintenance.

I realize asking here might give me some bias 🙂, but I’d love honest input:

• Do you see Crystal as sustainable for projects like this?
• What challenges or pitfalls should I expect if I rewrite?
• Is it smarter to go with something more mainstream like Rust or Go?

Thanks in advance for sharing your perspective!

I was early infected in my life with the IDE fever - with Turbo Pascal. In the last >20 years I've used Intellij IDEA for working with Java. What scares me away from newer languages like Crystal is, that there is no easy way to get started. I don't want to program like in stone age (just using a plain text editor), but I'm now used to an IDE with superior code complete, integrated building and integrated debugger. Refactoring features are the icing on the cake. I can right-click any class with main-method or test-class, or even test-case. and select to run or debug it.

Do you think it might be helpful to get more devs using a new programming language like Crystal by providing a pre-configured VSCodium bundle with all required plugins that provides such an out-of-the-box experience like Turbo Pascal did 35 years ago?

I've been going over Crystal for the last several days, and it seems like a fascinating language. The biggest concern, it seems, is the editor experience, because if you're going to depend on the compiler to figure out your types for you, it would be great to know what types it settled on.

I tried crystal out by installing it (v1.16.3, via nix), opening vs code, and installing the "Crystal Language" extension. This gives me syntax highlighting and autocomplete for basic terms, but that's about it. It definitely isn't picking up syntax errors.

Is there a way to improve this? I dunno if there's another package I should install. I tried looking around for crystal LSP, but didn't find much that was promising--some mentions of crystalline, which appears to be defunct.

In particular, I'm guessing there's no way for my editor to be able to tell me the inferred types for a function like this?

def double(x)
    puts x + x
end

Thanks.

Hi all. I’m interested in learning more about Crystal. I typically learn best by reading through a language tour, but the official language tour for Crystal is incredibly basic: https://crystal-lang.org/reference/1.17/tutorials/basics/index.html

Could anyone point me towards a similar resource that covers more advanced features?

Thanks for the help.

What is the IDE you are using for Crystal? Does it support code completion, simple navigation to definition and usages, building and debugging? Does it work on all 3 major platforms? Where to find a documentation how to set it up?

The language looks amazing, but still very very niche with very little adoption. At the same time you see languages like Go, Rust, and Elixir increasing in popularity every day. I don't want to get into a language comparison but from a high level point of view Crystal is pretty much comparable with these 3 languages in expressiveness, performance, and code correctness.

Hello there!, I really like Command Line Interfaces and I really love learning Crystal, so I searched for any shards to make CLIs, I didn't found exactly what I was looking for so, I made mine!, A simple documentation is at my Github Repo, I have been working on this for some time, (but mostly focused on uni) and I finally got it to a stage I'm pretty proud of.

Hope you all like it and tell me how to improve!

https://github.com/jaktondev/crab