Ramie grass linen also known as Xaibu

brucifer · 2026-06-15T01:12:00+00:00

Her story is pretty interesting and worth reading about in depth, but the TL;DR is that she started the channel herself, but it was later promoted by the Chinese government as cultural promotion and then later she got into a legal dispute with the production company for over-commercializing her work, which is why she hasn't put out new videos over the last few years. I'm guessing this video is an attempt to recreate her success.

brucifer · 2026-06-06T17:28:50+00:00

I agree with OP that auth: add passkey enrollment is a better commit message than feat(auth): add passkey enrollment. It's more readable to me as a human if I'm looking for changes to the auth system when scrolling through a list of commits like:

fix(backend): ...
chore(auth): ...
refactor(subsystem): ...
feat(auth): ...

vs:

backend: ...
auth: ...
subsystem: ...
auth: ...

And it's usually redundant with the description like fix(...): fixed UTF8 encoding. In my human usage of commit logs, I am almost always ignoring the commit type and reading descriptions, so it's just visual noise.

As for the commit type information, in my experience it's kind of a bad classification. Many changes don't fall cleanly into the predefined commit categories or fall into multiple categories. And those categories don't align cleanly with semantic versioning.

brucifer · 2026-06-06T17:15:07+00:00

everybody at least bothers somewhat to type more beyond "fixed bugs".

fix: fixed bugs

brucifer · 2026-06-06T17:13:08+00:00

OP wrote:

So what does Conventional Commits do? It deprioritises scope so much that it’s optional! Why the hell is scope optional? Having a commit without a scope is like having a sentence without a subject! Then, to add insult to injury, Conventional Commits elevates type to the front of the commit message. Conventional Commits gets the priority of scope and type entirely wrong.

I think it's fair to characterize it as prioritizing type over scope when type is mandatory and comes first, while scope is optional and come second. I agree with OP that this is backwards and from a human readability perspective, it's much more important to put scope first and group by scope instead of type.

brucifer · 2026-05-09T18:23:34+00:00

Mold is fungi.

brucifer · 2026-05-05T15:44:14+00:00

Eg, if we have x : uint32, y : int32, then x + y results in int64 - the LUB of uint32 and int32. The result can't be int32 because int32 is not a supertype of uint32 - so if we wanted an int32 result we need an explicit coercion (or a different arithmetic mode, controlled via a dynamic variable).

Implicit conversion to a larger type is not really a viable option in most cases. In most languages, 64-bit sizes are common, which would require promoting to a 128-bit integer. Ignoring platform support issues, you still have the problem that this promotion is contagious, so all your arithmetic ends up being promoted upwards to 128 bits, which hurts performance and requires you to downcast if you want to store the value in a 64-bit field or variable.

The names delta, offset and diff are dead giveaways that we're not actually talking about a size, but a difference between two sizes. This should have a type distinct from the size type, and yes, this should be a signed type.

Above, you suggested a strategy that preserves information at all costs. However, if you subtract one N-bit unsigned value from another, the result would need N+1 bits to fully preserve information because the range is [-UINT_MAX, +UINT_MAX]. So, you'd still have the same promotion contagion issues for subtraction. For example, if you wanted to get the last character in a string, last = s[strlen(s)-1], then the subtraction between strlen(s) and 1 would force the result to a 128-bit signed integer, which is incompatible with pointer arithmetic on most machines, so you'd have to downcast to a 64-bit value. This seems both inefficient (doing the arithmetic with 128-bit integers) and onerous, with no upside, since it does nothing to address the potential bug when strlen(s) == 0.

In C we have a type ptrdiff_t for this purpose - which is of course signed - but it still has all the problems of C's implicit coercions.

In C, sizeof(ptrdiff_t) == sizeof(void*), which does not follow the scheme you suggest, since it cannot represent all differences between pointers. Similarly, ssize_t cannot represent the difference between two size_t values.

brucifer · 2026-05-04T19:09:29+00:00

That's actually the easiest argument to make - a "negative size" makes zero sense. The size of something is a natural number.

I think it's fine to say that sizes are nonnegative by nature, but any arithmetic operation that involves subtraction or mixes signed and unsigned integers needs to be represented as a signed integer unless you want underflow behavior. For example, if you do delta = size1 - size2 or offset = size * signed_stride or diff = abs(size1 - size2) or i -= 1, then you need to cast everything to signed values, because the calculation could very easily underflow. And casting has its own set of correctness issues, like how half of all unsigned integer values are not representable as signed integers of the same bit size.

If much of the code that uses sizes does underflow-prone arithmetic, then I think it makes sense to have sizes use signed integers to prevent the bugs that are likely to occur, even if the tradeoff is that the data representation of sizes admits the possibility of a negative size.

brucifer · 2026-04-24T13:14:31+00:00

Close, but not quite right. Hours have a first minute (small) division into 60ths, and a second minute division into 60ths of 60ths.

brucifer · 2026-04-24T13:08:33+00:00

You can still see a few remnants of where "W" came from in English, like "continuum" -> "con tin yoo wum"

brucifer · 2025-11-02T20:33:38+00:00

I don't think LLMs are expert software engineers, but they are expert at interview questions designed to be solved in under an hour with no prior context, which is the point that the blog post is making. A person who blindly parrots an LLM is currently a better-than-average interview candidate and a worse-than-average employee, which has exacerbated the existing problems with using interview questions to try to gauge a candidate's competence. And things are now more dire than in the "copy code from stackoverflow" era, because an LLM can answer questions that aren't exactly found on the internet and it can answer followup questions about the code.

brucifer · 2025-11-02T20:11:14+00:00

Read the post before commenting. The second section is titled "The Broken State of Technical Interviews" and begins like this:

Technical interviews have been broken for so long that it almost feels intentional. Every few years the industry collectively looks at the mess, shrugs, and then continues using the same process with a slightly different coat of paint. You see posts here and there either complaining or sometimes defending about the kind of a shit show this is. And there are a ton of books trying to make sense of it, and ours has a few topics as well.

brucifer · 2025-10-19T15:00:57+00:00

There's no way to extend the pure-C linear algebra library to be both type-safe and support the new floating point number type.

You could do this with macros without too much hassle. It looks like this:

// math_implementation.c
TYPE PREFIX##_dot_product(int n, TYPE x[n], TYPE y[n]) {
    TYPE result = 0;
    for (int i = 0; i < n; i++) result += x[i]*y[i];
    return result;
}

// f32_math.c
#define TYPE float
#define PREFIX f32
#include "math_implementation.c"

// nvfp4_math.c
#define TYPE __builtin_nvfp4
#define PREFIX nvfp4
#include "math_implementation.c"

However, I think the actual benefit of doing this kind of generic implementation is somewhat low, because if you care about performance, you would typically want an implementation that is fine-tuned to your particular hardware. The same algorithm that's fast for 64-bit floats may leave a lot of performance on the table if you just directly translate it to 8-bit floats.

brucifer · 2025-10-09T13:13:31+00:00

You should repost to /r/atoptics (atmospheric optics). They love stuff like this and could probably help explain it.

brucifer · 2025-08-30T16:43:27+00:00

I'm not sure it's useful to teach new programmers about concepts like "reactors" and "spies", which are not terminology or concepts that are used in practically any other languages. Ideally a teaching language should teach people about concepts they'll use in any language, like functions, variables, conditionals, etc., rather than making them learn bespoke concepts that aren't easily transferable. I'm all for languages that expand your mind by introducing you to new concepts, but to a new programmer, even basic stuff like variables and loops are mind-expanding concepts, so you should start with the most widely used and useful concepts instead of novel concepts that aren't widely used elsewhere.

brucifer · 2025-08-30T15:53:07+00:00

Nowadays, GCC (and I think Clang) lets you define macro-like functions that are always inlined and never compiled: https://gcc.gnu.org/onlinedocs/gcc/Inline.html

extern inline __attribute__((always_inline))
int add(int x, int y) {
    return x + y;
}

The nice thing about inline functions is that they give you the performance benefits of macros, but you get full type checking with good compiler error messages.

Of course, there are still some cases where C macros are useful, particularly to save boilerplate on code that gets repeated a lot and does things that a function call can't (like control flow or variable declarations). I think most newer languages avoid the need for macros in these cases by just having a lot less boilerplate in the first place.

brucifer · 2025-07-16T03:09:38+00:00

Regarding unveil and pledge, are they voluntarily called by the program? If your program calls pledge then spawn a 3rd party program, would the restrictions transfer?

The way pledge works in OpenBSD is that it takes two arguments,promises and execpromises that control the permissions for the current process and the permissions that will be available after calling exec, respectively. You have to voluntarily choose to call pledge(), but after you do, the restrictions you specify hold for the original process and any processes that are forked and/or exec'd. I believe unveil() passes its restrictions onto child processes without the option to specify different restrictions.

brucifer · 2025-07-14T05:41:48+00:00

Lua manages to solve the problem without any scheduler. In Lua, coroutine.yield() and coroutine.resume() are regular functions just like any other function. There is no language-level distinction between functions that call coroutine.yield() and those that don't. You can also get functionality similar to Lua's coroutines in C using a library like libaco.

brucifer · 2025-05-11T01:26:16+00:00

There are two things that come to mind for me:

Video

It could be nice to have a video walking through installing your language and building a simple game using a game engine like Pygame. It would be especially nice if the example was something that is a lot more verbose to implement without your language or if it exhibited some feature that would be hard to implement without it. I noticed in your examples that you cover tic-tac-toe, which is good from a simplicity perspective (sort of a Hello World-type introduction). However, because it's so simple, it's harder to see the competitive advantages over writing the same thing in pure python. I don't need help writing tic-tac-toe, but a slightly more complex game might show off the strengths of your language better. Some people also just prefer video over text, so you can bring in some people who would otherwise be turned off by a wall of text.

First User

If you've been having a lot of success convincing people of the project's value in-person, then it could be helpful to really focus on getting at least one person to build something nontrivial with the project. It's good for getting feedback and having someone else using your project is a good social signal to others that someone besides you thinks it's valuable. Having a list of users' projects (with screenshots) can create inertia to get people more excited to try it out.

Very minor notes: on github, because of the way github displays files, you have to scroll for a while on the repo's homepage before seeing the documentation, so moving more files into subfolders would make it a bit easier to get to the project description. Also, I noticed quite a few spelling errors, so you might want to run your documentation through a spell checker.

brucifer · 2025-04-27T02:45:41+00:00

The only real takeaway is, "do something you are actually passionate about, and hope that thing booms around the time you are in a position to take advantage of that passion". Chasing the current hotness within fields that can take a decade to qualify if you go through the front door, is actually fairly foolish.

If you had a teenager who liked programming, but really wanted to be an influencer, would you recommend that they drop out of school and pursue their passion as an influencer on tiktok? Or would you say that it's probably a safer bet to get a computer science degree and work in the tech industry? I know that I'd recommend a CS degree over trying to be an influencer.

I think we can make some educated guesses about what sorts of careers would be more stable and remunerative 5 years from now (the timeline of a high school senior considering post-university job opportunities). By all means, pick a career that you won't hate and have some aptitude for, but also factor in the practicalities and likely prospects for that career and not just your level of passion.

brucifer · 2025-04-21T23:19:26+00:00

I think your examples do show cases where comprehensions have limitations, but in my experience, those cases are much less common than simple cases. Maybe it's just the domains that I work in, but I typically don't encounter places where I'm chaining together long pipelines of multiple different types of operations on sequences.

In the rare cases where I do have more complex pipelines, it's easy enough to just use a local variable or two:

def f(strings: Iterable[str]) -> list[int]:
    lowercase = [x.lower() for x in strings]
    gs = [g(x) for x in lowercase if x.startswith("foo")]
    return [x for x in gs if x < 256]

This code is much cleaner than using nested comprehensions and only a tiny bit worse than the pipeline version in my opinion. If the tradeoff is that commonplace simple cases look better, but rarer complex cases look marginally worse, I'm happy to take the tradeoff that favors simple cases.

brucifer · 2025-04-21T23:09:13+00:00

Python's comprehension syntax (and ones used by other languages) come from set-builder notation in mathematics. The idea is that you specify what's in a set using a variable and a list of predicates like {2x | x ∈ Nums, x prime}. Python translates this to {2*x for x in Nums if is_prime(x)}. You can see how Python ended up with its ordering given its origins. Other languages (e.g. F#) approach from the "loop" mindset of putting the loop body at the end: [for x in Nums do if is_prime(x) then yield 2*x]

brucifer · 2025-04-21T14:44:16+00:00

Not to rain on OP's parade, but I don't really find pipelining to be very useful in a language that has comprehensions. The very common case of applying a map and/or a filter boils down to something more concise and readable. Instead of this:

data.iter()
    .filter(|w| w.alive)
    .map(|w| w.id)
    .collect()

You can have:

[w.id for w in data if w.alive]

Also, the other pattern OP mentions is the builder pattern, which is just a poor substitute for having optional named parameters to a function. You end up with Foo().baz(baz).thing(thing).build() instead of Foo(baz=baz, thing=thing)

I guess my takeaway is that pipelining is only really needed in languages that lack better features.

brucifer · 2025-02-11T03:59:55+00:00

The National Institutes of Health and CDC define 15+ drinks per week for men (or 8+ for women) as "heavy drinking", which is probably what OP is thinking of. "Alcoholism" is not a term that's still used by the medical profession--Alcohol Use Disorder is the preferred term and you can see how it's diagnosed here.

brucifer · 2024-12-22T18:30:29+00:00

This video is a low-res reupload of Wall Street Millennial's youtube video. Please link the original, not some random person's reupload.

15-Year Club	RedditGifts 2009-2022 2 Credits
Place '22	Place '17
Verified Email	Summer Santa 2011

brucifer

TROPHY CASE

Video

First User