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

I was working on a zig project recently that uses some complex comptime type construction. I had bumped to the latest dev version from 0.13, and I couldn't believe how much improvement there has been in this area. I am very appreciative of really fast iteration cycles.


Ahh this has a name! I started doing this years ago and figured this must be used frequently because it’s so simple, elegant and can be done lock free. Thanks for calling it the name!


Yep, 100%


100% period.


This. Pure facts. Literally.

Here I am, discovering in practice that each generation has their own favorite words.


Zombo.com really had everything, way ahead of its time. It's been a while... maybe since the last time I lost the game.


Ooh very cool! I really like the logo :)


I've been using the Sabrent one for a year or so. It's worked quite reliably once I got the cables sorted. I was unintentionally using one TB3 cable in the mix, and that made it pretty flakey. It has been pretty solid since swapping that for a TB4 cable.


Eh, this one seems a reasonable trade-off to me at this point. If you try to handle every potential issue upfront, you'll never release, and this seems entirely fixable down the road. Persistent coroutines is a pretty challenging area to explore (tried this with Lua in a previous venture), and this seems a pretty minor point in that overall complexity. I'm curious, what else have you come across that justifies the "really brittle" conclusion?


You do what you have to do, but as a user, I like to know how things will break and what my options will be. I was curious how it worked, and took a peek at the first file that seemed it might reveal something interesting.


They just seem pretty pointless as a tool in language that already have super-light green threads and good concurrency primitives.


https://research.swtch.com/coro might be an interesting read.


Doesn't answer question "why?"

In other languages they were used coz they were far lighter than native threads but that's not the case in Go


I lived in Tennessee for a bit as a kid until about 7. The principal had this paddle hanging in his office, just menacingly looming there all the time. Every once in a while he'd hold these school-wide assemblies where the "worst" 2 or 3 kids would get paddled in front of everyone, adding this awful public humiliation. He had this fully bald head, and I have this distinct memory of his sweaty fucking face in that hot gym... I shave my head now due to some prior health issues. Every once in a while when I'm shaving, that image comes to mind and just that thought makes me boil a bit. I don't have kids, but I can't imagine how I'd react were someone doing this to them now.


> What singer sang in the most stadiums?

    SELECT singer.Name FROM singer JOIN singer_in_concert ON singer.Singer_ID = singer_in_concert.Singer_ID GROUP BY singer.Singer_ID ORDER BY COUNT(*) DESC LIMIT 1
It is close... sort of? It figured out it needed to join, group, and order, but it only drew the relation to the concert, not the venue. Correctness seems a huge challenge here. Even knowing SQL, I feel I'm double checking my results at times. But I can see how this might be incredibly useful someday for Salesforce if there's confidence in the results.


Basically, measure the time difference in the memory comparison. Typically, comparisons will short-circuit. That is, stop as soon as a difference is detected. But this is a problem for security situations like key comparisons. If 10 out of 20 bytes match, it will take a little bit longer to compare then if 5 out of 20 bytes match. With enough iterations, the key can be recovered due to these differences in time. The correct solution is to use a constant time comparison that always runs through the entire sequence of bytes.


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

Search: