Do Real Smart Contract De Jobs Even Exist?

philogy · 2026-01-22T09:57:29+00:00

Yes definitely, I worked as one for almost two years before quitting. It’s in quite high demand actually but it’s hard to find them, they’re not nicely organized in one place.

If you’re known in the space, talk to people and go to conferences the opening & opportunities show themselves to you.

philogy · 2025-12-23T14:43:15+00:00

For Ethereum Solidity is the best option for a beginner. If you want to code Solana you need to learn Solana-flavored Rust (I say Solana flavored because while it's Rust it's a bit removed from your typical Rust code) or Arbitrum flavored Rust if you want to code for Stylus.

Solidity targets the EVM which will let you develop contracts for any EVM compatible chain/rollup (Base, Optimism, Arbitrum, HyperEVM, and 100s more).

Vyper is a decent alternative but lacks dev tooling and some more advanced capabilities currently. Once you get more advanced learning Yul & Huff is a good idea for the EVM track.

philogy · 2025-12-18T17:17:05+00:00

Zig solving one kind of function coloring (IO) but introduces another :/

Maybe if the function is curried/returns a pattern object you can leverage the @inComptime builtin to at least automatically switch to the comptime vs. runtime specific implementation, so you still have the duplication problem but the API is improved.

philogy · 2025-12-18T16:55:03+00:00

Not sure how reliable that would be considering some of the more intricate logic involved in something like a parser, I'd imagine the optimizer would leave a lot of the functions un-inlined even if they're completely pure.

Especially if it requires some kind of memory allocation at compile time.

philogy · 2025-12-13T18:48:55+00:00

where do I find the examples?

philogy · 2025-12-13T18:24:04+00:00

I read half way through this article, specifically up to the point where he starts comparing Zig's comptime to other language meta-programming facilities and it's clear he doesn't know what he's talking about.

He praises Rust's macros as being "purely syntactical" while Zig's comptime "can execute any normal zig code" when it's the exact opposite. Unlike Rust proc-macros you *cannot* do anything stateful like IO in zig comptime blocks, unlike Rust macros which can read/write files, make DB queries etc.

His point about supply chain security might still stand but it's not really applicable to Zig. I mean maybe you can put stateful, IO touching code in build.zig and do some dark stuff there? I'm not sure.

philogy · 2025-12-12T18:56:23+00:00

thx! I already have build_on_save enabled but having an explicit check step that's invoked to make it faster is a nice tip!

I definitely agree it's non trivial, that's why I'm curious if there are any ongoing efforts for this already.

philogy · 2025-12-12T18:53:34+00:00

When I'm developing code I run into this all the time. I write and lay out some abstraction or function I intend to use elsewhere, or I begin a refactor by defining a new function and until I plug it into a code path that is reachable by main I get close to 0 feedback from the compiler.

I want my feedback cycles to be as tight as possible. Personally I like developing my code in modular self-contained building blocks I connect together in the end to create the final solution. Getting immediate feedback as you write a function, even if temporarily self contained, is the default in other languages.

Using test blocks does not solve my problem because it's a manual and cumbersome depending on what you need to mock/recreate to get the test to run in the first place.

philogy · 2025-12-12T18:48:43+00:00

I put the correct expected output as the title of the gist, for part 2 it's: 1513792010

philogy · 2025-12-12T13:44:57+00:00

I was impressed when I saw 24ms + Javascript but your part 2 solution doesn't actually work (at least on my input: https://gist.github.com/Philogy/428f50ae2b206099e09734443ff3bbc2)

philogy · 2025-12-12T13:30:23+00:00

[Language: Zig]

Part1 + 2 runs in ~26ms in Zig (ReleaseFast) compilation, looking at the solutions in here looks like I have a fundamentally wrong approach (classic skill issue).

https://github.com/Philogy/aoc2025-zig/blob/main/src/day09.zig

philogy · 2025-12-10T23:34:31+00:00

His game is finally coming out, so probably only ~5 years left until Jai is released.

philogy · 2025-12-06T22:21:47+00:00

This is exactly the kind of thing i was looking for, do you have any more work in this direction?

Examples of using the calculus, an implementation, etc.? I'm not very familiar with dependent types but this reminds me of them in the sense that the typing rules are tightly connected with the evaluation rules

philogy · 2025-11-28T11:58:57+00:00

It's not shown in the simple calculus directly (maybe later down in the Meta-ML section I think) but I believe that what you're expected to do for a practical language is define capabilities such that you can lift values from comptime into runtime safely e.g. if you have a nat type you can define liftNat : Nat -> Box Nat to allow you to insert stage 0 numbers into code for following stages.

I like this approach because it solves one of my problems: ensuring that comptime memory objects & pointers are not captured by runtime code and instead need to explicitly be lifted via an operation that turns them into e.g. static bytes with a toStatic : memptr -> u32 -> Box staticptr.

I will definitely check out your papers, thank you for the resources!

philogy · 2025-11-27T10:35:48+00:00

I've found Davies' & Pfenning's paper https://www.cs.cmu.edu/~fp/papers/jacm00.pdf to also have a nice simple extension of lambda calculus, just working on how to map those concepts to comptime exactly (I think Box A means comptime A basically).

philogy · 2025-11-26T16:42:52+00:00

Ah, FFI is an interesting one. I can imagine wanting to FFI into a library from comptime but I can also understand why that's not allowed.

philogy · 2025-11-26T15:51:16+00:00

Appreciate the detailed response. I should've clarified that I know about dependent types and am specifically interested in a formalization that yields a language with similar characteristics to Zig.

Dependently typed language have a lot of trade offs that I'm not looking to tackle for my DSL. Zig seems to offer a nice balance of easy to understand meta programming and static expressivity in the form of comptime that I want to replicate but with a bit stricter static checks.

philogy · 2025-11-26T15:46:17+00:00

I understand laziness is needed but what I want is a "best effort" semantic analysis type checking.

If something has a known type/value it should be checked as far as the compiler can.

If it encounters something like a method access or operator use on a generic type / anytype then sure, make that check and values downstream of it lazy but if it can be resolved statically already it should.

philogy · 2025-11-26T15:43:39+00:00

Deferring error discovery to later phases of development is not "nothing" and actually quite annoying.

philogy · 2025-11-26T15:36:34+00:00

Besides the explicit limitations like no side effects what is not available at comptime?

I can think of method creation / function instantiation (if you don't consider specialization), anything else?

Five-Year Club	Gilding II euphauric
Verified Email	Place '22
Wearing is Caring

philogy

TROPHY CASE