- slices become a total non-issue since a pair of (start, end) already is a slice and you can just move start and end.
- comparing against an end pointer is generally easier than adding up a length value first, particularly if you're slicing at the same time.
- the end pointer value is independent of the array element type, so if you e.g. cast to uint8_t * (which arguably you shouldn't in most cases) it stays exactly the same. If you store a count you need to adjust a multiplier. If you store a byte length, you need to do a lot of divides or casts to deal with pointer arithmetics.
Also, this is a huge red flag to me:
https://github.com/orangeduck/Cello/blob/master/include/Cell...
#define is ==
#define isnt !=
#define not !
#define and &&
#define or ||
#define in ,
P.S.: This also is a "try to invent a new programming language without inventing a new programming language" thing. Have your cake and eat it... either it's C or it isn't, and this library is leaving the space of "normal" C.I know he's doing a little hackiness by placing the size before the start of the object, but they also take that approach here (https://www.piumarta.com/software/cola/objmodel2.pdf) so maybe it's not that uncommon. How would you do the dual pointer setup? Is there any overhead from that, or is it small enough to not worry about?
You have to worry about them in any non-garbage collected language. There's just no compiler that checks that you're doing it correctly and is the primary source of security bugs for most software.
The only positive, if there is one, is the ability to really consider how our societies operate, how dangerous apathy and incompetence are and for tech workers more specifically, to realize how much of an impact our work has.
The next time someone wants to act like they know what the future looks like, remind them to have some humility. Be safe yall. This too shall pass.
Don't let the Nim folks fool you. Nim isn't targeting the same space as Rust. It's garbage collected.
Nim could see success in challenging Python or Golang, but Rust is rather uniquely positioned to go after bare metal (C, C++), yet have the ergonomics one would expect from Java, Python, Go, etc.
Rust is going to eat everything.
Have you done a lot of Rust? I spent considerable time in Rust, and at the end of the day, after stepping away from it, I've found multiple options with the kind of ergonomics that make development a lot more productive for me.
Rust is not going to eat everything. I'd bet money on it. Rust will likely un quietly behind the scenes powering lots of great projects, but its audience is limited. I think HN really has a weak spot for understanding how few people even know what it is. I was surprised to ask a CS grad student that's done lots of machine learning about Rust, and he simply didn't know it existed. I like Rust and all that it taught me, but we need to be realistic about its ceiling and what it is appropriate for.
Nim's performance is also ridiculously fast and low memory.
Unfortunately this is one of those things where hype has kind of won out and I think a lot of people are dismissing an option like Nim simply because we're not talking about it on places like HN. Though, to be fair to Rust, the community is doing a lot of bleeding edge stuff that Nim's community just isn't big enough to.
Deleted Comment
https://en.wikipedia.org/wiki/History_and_culture_of_substit...
https://www.amazon.com/Blitzed-Drugs-Germany-Norman-Ohler/dp...
The prices are a lot cheaper in a lot of US metros than the tech centers.