tiddles

This x1000. I started implementing a JVM for shits and giggles a while ago, and once I had laid out ~220 panics for each opcode, it was incredibly satisfying to implement them one at a time to work towards bootstrapping the standard library.

Granted, most opcodes are implemented incorrectly as minor things like method and field resolution aren’t quite there yet.. as soon as I’ve implemented enough opcodes to actually run something and return/exit/throw, the correctness will be a bugger to fix :^)

I've written some pretty low-level OpenGL bindings in Rust, because the existing solutions are either too high level or over the top complexity wise.

At the time I only had experience with the OpenGL C api and didn't want to learn a totally different Rust abstraction or mix C/C++ libraries into a pure Rust project.

https://github.com/DomWilliams0/name-needed/tree/develop/ren...

I’ve come across junior colleagues who latch on to some "best practice" that they read/heard about, then preach it to anyone who will listen and aggressively debate it to death, instead of actually getting any work done.

The solution is to ignore these "my thing is objectively better than yours in 100% of cases" debates - choose the pattern/design/paradigm/thing with the least compromises and do something productive :-)

Totally off topic, but I'm often tripped up by these multiple uses of quotes like this. Why do we use the same symbols out of a huge space for both quoting and sarcasm ?

Maybe this is why Zig might end up being a better choice for embedded and very low level programming, as an explicit competitor to C.

The official CLion plugin for Rust is phenomenal, and almost feels like a first class IDE nowadays.

I appreciate Rust is more complex than other languages and much less easier to pick up and learn on the job though. It definitely takes a lot of practice to get to the point where traits/lifetimes/ownership etc feel like brilliant tools rather than needless complexity.

I've been alternating between two long term Rust projects, which seems to work in keeping the motivation up for both!

A Dwarf Fortress-like game (and engine): https://github.com/DomWilliams0/name-needed

A x64 operating system: https://github.com/DomWilliams0/DomeOS

Thank you for doing the research and not just mindlessly adding features other languages have :)

Thank you for doing this!

I've listened to this and a few other episodes with Andrew and Ginger Bill, and they're very interesting, I highly recommend them.

A Dwarf Fortress-like game (and engine) in Rust: https://github.com/DomWilliams0/name-needed

Ambitious to be sure, but after a year and a half I'm still consistently working on it, and still enjoying it!

I only browse sites with an average ROI of at least 1 wife per week.

I happened to watch a talk by Chandler yesterday that might be the one the author was referring to?

https://youtube.com/watch?v=2EWejmkKlxs

I'd guess it's just using the value of the instruction pointer at each point it samples, and the way to resolve the function from that is to look backwards to find the symbol of the function it's in. As he has no symbols Luke has no (easy) way of knowing where functions start so it can't do this lookup.

I've migrated a few big projects through several iterations of different error handling crates, which was always painful. For now I've settled on thiserror, but only until backtraces are stable - then it's back to the churn :)

The most common time this comes up for me is trying to use continue/break if a value is None/Err :

  loop {
    let thing = match foo() {
      Some(bar) => bar,
      None => continue,
    }
  }

Yet I still always first try to put the continue in an unwrap_or_else first..

That sounds really interesting! I'll definitely keep an eye on this.

As others have said, practice! Everyone has a (few) million lines of awful code in them initially.

Some recent revelations I've had in the last few years that I've been applying with great effect:

- Write code that's clear, not clever. Other people who will have to read and understand it (including your future self) won't be impressed by "clever" code, it just makes it way harder to understand.

- Write code to be disposable. I know for a fact that in a few months time I'll have to revisit my code to refactor or add new functionality, and writing it with mindset that it should solve only the current problem and nothing else prevents code creep/YAGNI.

I mostly enjoy the act of programming, without the need of producing something useful or profitable in the end. Particularly when it's a hobby project in whatever domain interests me at the moment, e.g. currently it's low-level optimization hacks and ridiculous concurrency in Rust.

I'm a developer proffesionally but find I only spend about half my time writing code, so I still have plenty of energy for my own projects at home.

It's both that and the circle that I can't get past now :) Extending the circle's height to what should be correct screws up the whole diff and paints a load of stripes across it...

Thanks, those lines in the corners threw me off.

Would you have any hints for puzzle 3? The power of CSS has far overtaken me in the last few years.