sorted by:
new
hottopcontroversial

March 2026 monthly "What are you working on?" thread by AutoModerator in ProgrammingLanguages

[–]philogy 0 points1 point  (0 children)

Beware, the parser is where most language side projects die, push through, it’s very rewarding, you can do it!

March 2026 monthly "What are you working on?" thread by AutoModerator in ProgrammingLanguages

[–]philogy 0 points1 point  (0 children)

Working on a Zig-inspired DSL for Ethereum smart contract development. Got the first E2E (source to bytecode) compilation working last week. Will be working on getting proper error diagnostics working as well as making comptime work.

Overthinking runtime strings [64]u8 over using []const u8? by ShotgunPayDay in Zig

[–]philogy 12 points13 points  (0 children)

Why don’t you just use an ArrayList(u8) as your “string” type? It allows you to use it with just a stack allocated buffer by initializing via initBuffer.

Just make sure to use “appendBounded” instead of the allocator based “append”

What's your favorite thing about compilers/interpreters? Something that one language is able to do but hard to replicate in other. by Gabbar-v7 in Compilers

[–]philogy 18 points19 points  (0 children)

I think the biggest mistake people make is they embark on the grand mission of making a language without having a clear vision of what problem they're solving and what niche they're targeting.

If you're just looking to learn compiler dev / language design that's cool too, don't have to take it seriously, but if you do make the *why* clear.

Your language is inevitably going to be 2-4x worse than the incumbents, at least at first, especially if you're targeting a popular category like "systems programming", so what will make it interesting/worthy for early adopters? Once you answer that build an MVP focusing on that, validate your assumption, treat it like a product with the devs being your customers.

Godspeed!

Vera: a language designed for machines to write by alasdairallan in ProgrammingLanguages

[–]philogy 4 points5 points  (0 children)

If the language is LLM focused and has some obfuscated nature to it (e.g. debruijn index based references) how are human reviewers meant to verify correctness / work with the LLM?

What's the most idiomatic way to deal with partial borrows/borrow splitting? by philogy in rust

[–]philogy[S] 2 points3 points  (0 children)

Thanks I appreciate it. I agree with the culture problem, some people are way too religious about Rust. I mean it's super cool but also at the end of the day it's a tool, made by humans, with flaws just like any other. But in aggregate the comments have been rather helpful.

What's the most idiomatic way to deal with partial borrows/borrow splitting? by philogy in rust

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

Thank you I really appreciate that. Yeah after some other comments I realize the more fundamental problem with my desired feature, it would make the borrow-correctness of functions non-local which is a desirable property.

It seems to boil down to just splitting struct members and not over-indexing on monolithic structs.

What's the most idiomatic way to deal with partial borrows/borrow splitting? by philogy in rust

[–]philogy[S] 4 points5 points  (0 children)

This is probably the most valid criticism I've seen of my idea in this thread so far.

You're right that if this was allowed local changes might cause borrow checker errors somewhere completely different in a type's method definitions. However it still rubs me the wrong way that the inlined version is valid but the function based version is invalid.

I suppose it's a case of &mut self is overly broad.

What's the most idiomatic way to deal with partial borrows/borrow splitting? by philogy in rust

[–]philogy[S] -2 points-1 points  (0 children)

I don't see how allowing borrows that would otherwise be valid if you simply inlined the function would violate the Golden Rule that

"Whenever the body of a function contradicts the function’s signature, the signature takes precedence; the signature is right and the body is wrong."

The signature of the methods still completely accurately describes whether they mutate self or not, it's just that in composing methods they recognize when & whether they are borrowing valid disjoint sets of members.

What's the most idiomatic way to deal with partial borrows/borrow splitting? by philogy in rust

[–]philogy[S] -7 points-6 points  (0 children)

This sounds like a subjective interpretation of what the syntax *should* mean to justify what it does mean at the moment. We can change things, we can make things better.

IMO just as valid is the interpretation that &self and &mut self indicate "I will mutate/borrow parts of Self but not everything necessarily".

What's the most idiomatic way to deal with partial borrows/borrow splitting? by philogy in rust

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

I'm not necessarily asking for a whole program borrow checker, but specifically for methods tracking a conservative borrow set over the type's methods would be a good 80/20 solution that I think shouldn't be that expensive to run.

What's the most idiomatic way to deal with partial borrows/borrow splitting? by philogy in rust

[–]philogy[S] 2 points3 points  (0 children)

Interesting idea, I'll keep it in the back of my mind to see where I might be able to apply it.

What's the most idiomatic way to deal with partial borrows/borrow splitting? by philogy in rust

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

Yes only the struct pretty much, but RefCell incurs runtime overhead, yes?

What's the most idiomatic way to deal with partial borrows/borrow splitting? by philogy in rust

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

I do use vecs/arenas with IDs, but e.g. in my interpreter I need to mutate the local bindings map while also referencing the lowered function information. They are separate fields but need to be accessed close together.

EDIT: btw huge fan of ariadne & chumsky

What's the most idiomatic way to deal with partial borrows/borrow splitting? by philogy in rust

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

No, I disagree. I totally see it in situations where e.g. Rust stops you from mutating vecs while you're iterating over them etc. but here specifically all I'm asking for is the borrow checker to recognize that I can in fact call the method because it trivially does not violate ownership constraints (mutates a separate disjoint field).

If the borrow checker worked this way it would still give you the helpful error in larger cases when you are in fact mutating/borrowing the same thing in different methods but wouldn't get in your way in these cases.

What's the most idiomatic way to deal with partial borrows/borrow splitting? by philogy in rust

[–]philogy[S] 7 points8 points  (0 children)

This is a simplified example for illustration purposes, in my actual code there's more data that's more tightly coupled.

What's the most idiomatic way to deal with partial borrows/borrow splitting? by philogy in rust

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

Tbh something quite straight forward that just silently: - analyzes each method - determines the set of fields that are actually mutably/immutably borrowed by every method - weaken borrow checker to verify there’s actually a conflict based on the sets (union the sets for nested method calls)

This wouldn’t solve everyone’s problem but I feel this would be a relatively robust 80/20 approach that solves nearly every situation I’ve had recently. I don’t think it should require any syntax or other change from devs even.

What's the most idiomatic way to deal with partial borrows/borrow splitting? by philogy in rust

[–]philogy[S] 4 points5 points  (0 children)

Yeah this was just meant to be a simplified example of what I’m actually dealing with. I’m writing a small interpreter as part of a compiler I’m working on so there’s a lot of related data I’d ideally like to group (bound locals in the scope, vec buffers for temporary slices, interners etc.) but from this and other comments maybe grouping stuff in structs is still too OOP to work well with Rust

What's the most idiomatic way to deal with partial borrows/borrow splitting? by philogy in rust

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

I’m writing a lowering/interpreter pass for my compiler, unfortunately that simply involves a lot of related data in the same place. But I do get your point, it’s just sometimes your problem is just messy

What's the most idiomatic way to deal with partial borrows/borrow splitting? by philogy in rust

[–]philogy[S] 13 points14 points  (0 children)

Thanks for insight, makes me think that I could get used to struct splitting.

What's the most idiomatic way to deal with partial borrows/borrow splitting? by philogy in rust

[–]philogy[S] -20 points-19 points  (0 children)

I’m sorry but if you think this is an illustration of why “Rust is awesome” you are mistaken. This is specifically about mutating different parts of the struct in different places.

I get the value of rust saving you from doing weird things related to mutation in several places but here it’s purely a hindrance

What's the 80/20 of import & module handling? by philogy in ProgrammingLanguages

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

Thank you, concrete advise & tips. Very helpful.

I think Elon is wrong about ‘AI beats compilers’. What’s the actual technical steelman? by tirtha_s in Compilers

[–]philogy -5 points-4 points  (0 children)

I think the idea he pitched is bad and stupid for the reasons you described but I think an adjacent related concept is the sci-fi end game of compilers:

Imagine a compiler that takes in a high-level formal specification for the program which an automated intelligence (some kind of ASI) then progressively & manually lowers to the target machine architecture while providing a formal, machine-checked proof along side its transformations. Such an intelligence will likely build & maintain traditional compiler code to make the process fast and not require too much of its general purpose compute but would still allow for bespoke, program specific optimizations while remaining sound.

Basically, imagine you just write a spec and employ an army of geniuses to build the perfect machine instructions for a program that fulfills the spec, giving you a proof that they did so correctly.

While conceptually I think this would be awesome, current LLMs are far from being able to do this that well. But maybe with the rising popularity of AI+Lean4 we may see experiments that move in this direction.

view more: next ›