miningape

Don't have a comparison, but I've written toy languages in a few of them.

I only really feel confident to talk about Rust, Rust stands out when it comes to parsing (functional bros unite), but does suffer when interpreting because of unsafe memory access - although for a compiler that shouldn't be an issue.

Odin is great, but I feel like it doesn't have enough syntax sugar to make languages easy to work on - that being said you can achieve most of what you want in a mostly comparable way if you're willing to write more ugly code. In this way it's very similar to C.

As another commenter wrote "how do you allocate memory without an allocator?"

Even `malloc` has overhead.

> Wouldn't dynamic scope be better?

Dynamic scope would likely be heavier than what Odin has, since it'd require the language itself to keep track of this - and to an extent Odin does do this already with `context.allocator`, it just provides an escape hatch when you need something allocated in a specific way.

Then again, Odin is not a high level scripting language like Python or JavaScript - even the most bloated abstractions in Odin will run like smooth butter compared to those languages. When comparing to C/Rust/Zig, yeah fair, we'll need to bring out the benchmarks.

Do we work at the same company?

Exactly, if these tools are going to be so revolutionary and different within the next 6 months and even more so beyond that - there's no advantage to being an early adopter since your progress becomes invalid, may as well wait until it is good enough.

> if it’s as easy as everyone says surely someone would try.

Yeah, 18 months ago we were apparently going to have personal SaaSes and all sorts of new software - I don't see anything but an even more unstable web than ever before

> invalidate my argument that they are alike in the specific ways that I outlined

Basketballs and apples are both round, so they're the same thing right? I could eat a basketball and I can make a layup with an apple, so what's the difference?

> programmers who treat the compiler as a black box (ie. 99% of them) see probabilistic outputs

In reality this is at best the bottom 20% of programmers.

No programmer I've ever talked to has described compilers as probabilistic black boxes - and I'm sorry if your circle does. Unfortunately there's no use of probability and all modern compilers definitionally white boxes (open source).

> Unless you wrote the compiler, you are 100% full of it. Even then you'd be wrong sometimes

You can check the source code? What's hard to understand? If you find it compiled something wrong, you can walk backwards through the code, if you want to find out what it'll do walk forwards. LLMs have no such capability.

Sure maybe you're limited by your personal knowledge on the compiler chain, but again complexity =/= randomness.

For the same source code, and compiler version (+ flags) you get the exact same output every time. The same cannot be said of LLMs, because they use randomness (temperature).

> LLMs are also deterministically complex, not random

What exactly is the temperature setting in your LLM doing then? If you'd like to argue pseudorandom generators our computers are using aren't random - fine, I agree. But for all practical purposes they're random, especially when you don't control the seed.

> Are you able to predict with 100% accuracy when a loop will successfully unroll, or various interprocedural or intraprocedural analyses will succeed?

Yes, because:

> They are applied deterministically inside a compiler

Sorry, but an LLM randomly generating the next token isn't even comparable.

Deterministic complexity =/= randomness.

What? Do you even know how compilers work?

Honestly, I'd gladly pay for and read a version of pride and prejudice rewritten in gen Z slang

I don't recall saying everybody?

You missed my point, the original comment is stating that the market for such a device doesn't exist because developers are too finicky and customisation focussed.

As a counter example - look at macbooks which are about as un-customisable as they come, but a large portion of developers use them. Meaning the market exists even if it's currently dominated by Apple (which as you/the post points out is slipping)

Apple / macbooks seem to be doing fine

You're misunderstanding - the issue isn't with mascots.

The issue is with the furry community who take their fetishes way too far. For example the Tony the Tiger accounts had to be shut down after facing years-long constant sexual harassment from furries.

Yeah people don't realise this, but shame and guilt (and fear) are our 2 society building emotions. Each society has it's own mix of these, and there are also "themes" depending on which is the dominant one.

Shame has practically been thrown out the window in certain places and we can see the effects of that - people scamming each other, lying in the streets, etc. Guilt is also being eroded across the west, leading to things like rampant criminality and punishments that are less than a slap on the wrist.

Fundamentally these emotions are designed to keep us in check with the rest of the group - does this negatively affect some: yes. But at the benefit of creating high trust societies. Every time I encounter this topic I can't help but think: Don't throw the baby out with the bathwater.

For me they're both about equally shitty, but with Github you get a nice commit calendar to show off to recruiters - so Github wins IMO.

Luckily it's harder to enshittify something you don't own

+1 - I also see a huge opportunity for forgejo to become a new stackoverflow if they add federation

The primary issue with SO was that it was disconnected from the actual communities maintaining the project. A federated solution would be able to have the same network effects while handing ownership to the original community (rather than a separate SO branch of the community)

Mom, please come pick me up. These kids are scaring me.

Loving this series! I'm currently implementing a z80 emulator (gameboy) and it's my first real introduction to CISC, and is really pushing my assembly / machine code skills - so having these blog posts coming from the "other direction" are really interesting and give me some good context.

I've implemented toy languages and bytecode compilers/vms before but seeing it from a professional perspective is just fascinating.

That being said it was totally unexpected to find out we can use "addresses" for addition on x86.

The author's name is Sasha Putilin - might be the author's real name, but it's a lucky coincidence in that case

> Oh, no... not Frosted flakes... that kinky tiger is scary.

Oh my sweet summer child

You really don't want to know what they did to our boy Tony

Gotta love how none of the replies to your comment deny that it's a fetish

Claude, summarise this for me

It may - but it doesn't weaken your ability to think computationally

I'm currently coding a Gameboy (which kinda has a Z80) emulator and it's so much fun! (I'm in my mid-20s for context)

I've never really worked on such a low level, the closest I've gotten before is bytecode - which while satisfying - just isn't as satisfying as having to imagine the binary moving around the CPU and registers (and busses too).

I'm even finding myself looking at computers in a totally different way, it's a similar feeling to learning a declarative, or functional language (coming from a procedural language) - except with this amazing hardware component too.

Hats off to you though, I'm not sure I'd have had the patience to code under those conditions!

Fuck it - let them reap the consequences. Ideally wait until there's something particularly destructive, then do the post-mortem as publicly as possible - call out the structures and practises that enabled that commit to get into production.

You'd be surprised how creative the military can be when there's demand

I think you're more reading what you want to read out of that - but that's the problem, it's too ambiguous to be useful

Strange, who would've thought paying people not to work would result in people... not working.