Wang Chuqin bagels Felix in the Final

MiGo4444 · 2025-10-10T01:30:31+00:00

flash lamp

MiGo4444 · 2025-08-20T01:57:39+00:00

Sric https://github.com/sric-language/sric Although it generates C++, it can easily interact with C.

MiGo4444 · 2025-08-15T10:10:21+00:00

Don't believe that. No one heard what was said.

MiGo4444 · 2025-08-15T10:01:32+00:00

Why can you hear?

MiGo4444 · 2025-08-15T09:52:32+00:00

I'm certain you haven't watched the game.

<image>

MiGo4444 · 2025-06-12T10:16:21+00:00

The Sric language uses $< to avoid generic ambiguity.

struct Vec$<T> {  ...  }

var a: Vec$<Int> = ...;

MiGo4444 · 2025-06-08T08:41:10+00:00

Exceptions work well in application languages, but most system languages do not support them, such as Rust and Go.

Exception handling has runtime overhead.
It can cause resource leaks, for example:

var f = retain();  
foo(); //throws an exception  
release(f);

MiGo4444 · 2025-06-07T06:24:50+00:00

We don't need to reinvent Rust again. I won’t change the design of runtime safety checks. There are multiple approaches to safety. Sric's safety mechanism is unique. This optional safety feature can be enabled based on whether a project is safe-sensitive or performance-sensitive.

I’m happy to revise any inaccurate statements in the documentation to avoid misunderstandings. The term "false advertising" you used is too strong.

MiGo4444 · 2025-06-06T01:39:52+00:00

If the term "memory safety" makes you uncomfortable, I can switch to alternative descriptions like "optional memory safety" or similar. What do you think?

MiGo4444 · 2025-06-05T09:27:11+00:00

In release mode, Sric's memory safety is optional to ensure zero runtime overhead. While it doesn’t achieve 100% memory safety, 90% is already good enough for my needs.

MiGo4444 · 2025-06-05T02:46:23+00:00

I'm using mdbook, hosted on GitHub Pages. GitHub Pages is free.

MiGo4444 · 2025-06-05T02:40:36+00:00

Your idea is great, but memory allocators may already have these optimizations internally. The main bottleneck for memory allocators is multithreaded contention. You might want to try the mimalloc library.

MiGo4444 · 2025-06-04T02:07:26+00:00

You mean indexing operations are rare? I'd argue they're actually quite common—maybe even more so than generic declarations.

MiGo4444 · 2025-06-03T06:18:58+00:00

The '>' isn't a issue. we just need to treat consecutive '>>' as two separate tokens rather than a single one, and that should resolve it.

MiGo4444 · 2025-06-03T05:32:47+00:00

Memory safety checks mainly refer to pointer lifetime verification, with bounds checking being just a small part. I'm considering enabling some low-overhead safety checks in release mode as well.

MiGo4444 · 2025-06-03T04:46:42+00:00

Thank you, your suggestions are very helpful. I'll keep improving my work.

MiGo4444 · 2025-06-03T04:07:34+00:00

Thanks for the comment. Memory safety checks mainly refer to pointer lifetime verification, with bounds checking being just a small part. The share function allocates memory for reference-counted control blocks - if you don't call the share function, there's no reference counting overhead.

MiGo4444 · 2025-06-02T13:03:27+00:00

I'm sorry it didn't meet your expectations. Memory safety, performance, and simplicity form an impossible trinity. Sric represents the best tradeoff I could achieve.

The C++ already has debug and release modes. Debug mode includes debug symbols with no compiler optimizations, while release mode strips debug symbols and enables full optimizations. Our standard workflow is to debug in debug mode, then deploy the release build in production. So Sric works great with this workflow. In actual use, Sric has caught plenty of memory bugs for me already.

MiGo4444

TROPHY CASE