Hacker Newsnew | past | comments | ask | show | jobs | submit | slowcache's commentslogin

The reviews must be heavily AI assisted in order to get that sort of volume in.

Either way, it doesn't surprise me that this number is so high. Productivity chasing is the name of the game for AI, regardless of how sustainable or helpful this extra work done actually is


Even with heavy AI assistance, how well-reviewed can this code be? 600 commits in a day is one commit every 2 minutes for 18 hours.

This post is like 6 months late. I share the same concerns that others in the thread do, but the talking point is pretty tired by now


Really blown away at how well this works on mobile. Awesome stuff


I was also wondering this. I don't want my codebase to be a shared word document, how will it ever be in a compilable state?


Odin has been really growing on me lately as a language that checks all of those boxes. String types, first class allocators, built in tests, a batteries included philosophy, and ease of use are some of the things that really drew me towards it.

I really wanted to like rust and I wrote a few different small toy projects in it. At some point knowledge of the language becomes a blocker rather than knowledge the problem space, but this is a skill issue that I'm sure would lessen the more I used it.

What really set me off was how every project turned into a grocery list of crates that you need to pull in in order to do anything. It started to feel embarrassing to say that I was doing systems programming when any topic I would google in rust would lead me to a stack overflow saying to install a crate and use that. There seemed to be an anti-DIY approach in the community that finally drew me away.


> String types

It's a byte string.

> rune is the set of all Unicode code points.

We copied the awful name from Go … and the docs are wrong.

Five different boolean types?

Zero values. (Every value has some default value, like in Go.)

Odin also includes the Billion Dollar Mistake.

> There seemed to be an anti-DIY approach in the community that finally drew me away.

It's a "let a thousand flowers bloom" approach, at least until the community knows which design stands a good chance of not being a regretted addition to the standard library.


What's the difference between anti-DIY and "batteries included"?


If Ginger Bill thinks some niche feature might be useful then baking it into Odin is "batteries included" if not, having it would be anti-DIY. This is very much Bill's language. If what you're looking for is that auteur stamp you won't find it in C or Rust or Typescript but you will find it in languages like Jai, Odin, Hare, maybe Zig.

If that creator's vibe happens to match yours this could be beautiful, at least for personal projects. It's hard to imagine this scaling. A triple A studio hiring panel: "You've applied for a job but we write only Jai here. We notice you haven't submitted any obsessive fan art about Jonathan Blow. Maybe talk us through the moment you realised he was right about everything?"


Batteries included is a fat, opinionated standard library.

I think for some devs, if you import from the standard library, that somehow counts as DIY, whereas if you import from libraries that aren't distributed with the compiler, it's anti-DIY.


I really want to love rust, and I understand the niches it fills. My temporary allegiance with it comes down to performance, but I'm drawn by the crate ecosystem and support provided by cargo.

What's so damning to me is how debilitatingly unopinionated it is during situations like error handling. I've used it enough to at least approximate its advantages, but strongly hinting towards including a crate (though not required) to help with error processing seems to mirror the inconvenience of having to include an exception type in another language. I don't think it would be the end of the world if it came with some creature comforts here and there.



I didn't think that this was much of a thing that needed to be investigated. Adding additional processing into your code will make it slow down.

On a related note, I had a consultant come into my work one time to the teach us some pragmatic things in C++. One of the lessons was that that gcc will not attempt to reorder the code within a try block to optimize it. This could be leading to some very minute slowdown in a C++ app in addition to the overhead associated with try/catch as a whole


Such information can quickly become obsolete as compilers improve.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: