> If your first contact with rails is version 7+ and you’re only comfortable with JS/TS, then you’re not going to get it and might actually strongly dislike it
This is the primary issue with Rails in my experience. It takes intentional effort to internalize the idioms before it clicks and you unlock the magic that makes it so insanely productive. JS devs will keep trying to force backend business logic into Franken-React Stimulus components and complaining it's not very good.
Yes, I've seen that, too. The rails way of doing things can feel like a terrible limitation to some developers, while others enthusiastically embrace it
> Accelerate your agents with convention over configuration. Ruby on Rails scales from PROMPT to IPO. Token-efficient code that's easy for agents to write and beautiful for humans to review
This is so painful... I can't help but wonder who they're trying to target with such inane slogans.
Rails is amazing, but "token-efficiency" is not on the list of reasons why.
Having grown up playing with LEGOs, I can still distinctly remember the feeling of sore fingers pulling tiny pieces apart after a long session. It wasn't until a few years ago I learned there's an official brick separator tool [1]. Would've changed my life as a kid.
> But I prefer Rust over Zig. The main difference is Rust chooses a "closed world" model while Zig chooses an "open world" model: in Rust, you must explicitly implement a trait while in Zig as long as the shape fits, or the `.` on a structure member exists (for whichever type you pass in), it will work (I don't use Zig so pardon hand wavy description).
Do you happen to have a more specific example by any chance? I’d be interested in what this looks like in practice, because what you described sounds a bit like Go interfaces and from my understanding of Zig, there’s no direct equivalent to it, other than variations of fieldParentPtr.
They are referring to `anytype`, which is a comptime construct telling the compiler that the parameter can be of any type and as long as the code compiles with the given value, it's good.
It's an extremely useful thing, but unconstrained, it's essentially duck typing during compile time. People has been wanting some kind of trait/interface support to constrain it, but it's unlikely to happen.
Conceptually it's quite similar to how C++ templates work (not including C++20 concepts, which is the kind of constraining you're talking about).
I quite like it when writing C++ code. Makes it dead easy to write code like `min` that works for any type in a generic way. It is, however, arguably the main culprit behind C++s terrible compiler-errors, because you'll have standard library functions which have like a stack of fifteen generic calls, and it fails really deeply on some obscure inner thing which has some kind of type requirement, and it's really hard to trace back what you actually did wrong.
In my (quite limited) experience, Zig largely avoids this by having a MUCH simpler type system than C++, and the standard library written by a sane person. Zig seems "best of both worlds" in this regard.
Did exactly that a while ago to salvage the nano texture panel from my 5k iMac. It takes a bit of research to figure out the correct driver board for the specific panel / peripheral combo, but the build process itself was pretty straightforward and it works like a charm.
Can you share any experiences with the driver boards? From what I've seen it looks a bit janky with wires sticking out of the old iMacs chassis and a very old school on screen display. Is the driver board stable? No overheating or signal issues?
I went with the T18 board since it’s passively cooled. IIRC it could also do PD through USB-c, but that would require additional cooling and I just don’t trust noname Chinese manufacturers to do that correctly anyway, so I typically have it hooked up via HDMI. So far it’s been perfectly stable, without any issues. I think there might have been a small addon board to be able to use full brightness as well. There’s a built-in retro display monitoring menu, but I haven’t had a need to use it really, most configurations work from Mac OS, including color profiles and brightness control.
For cables, my iMac had an opening in the back for RAM sticks, which I popped out and wired all cables through. I mounted the driver board on a piece of plexiglass so that most of the ports are accessible directly to the RAM opening. For power, I use a regular third party power brick I had laying around, though some people have reused the iMac’s original power cable with an internal power supply.
Honestly, the hardest parts were identifying the correct driver board and gluing the front glass back on after assembly.
reply