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

A lot, but my favorites of the year:

- Children of Time

- Hyperion & The Fall of Hyperion

- Red Dragon & Silence of the Lambs

- Cat's Cradle

- The Book of the New Sun


Started playing fantasy football last year. Vastly improved my enjoyment of football, find myself following players and teams I wouldn’t care about before. I use my fantasy app for scores, news, etc.

I watch RedZone, and created a multireddit for nfl, teams, fantasy, etc. for the rest + YouTube for highlights


Gossip Glomers might be fun if you’re looking for some hands-on exercises :)

https://fly.io/dist-sys/


Almost done with Beej's Guide to Networking Concepts[1] and absolutely loving it, following along in Go. Gotta check this out and his other guides afterwards

[1]: https://beej.us/guide/bgnet0/html/split/index.html


One problem I’ve experienced doing something like this is you end up with both exceptions and error values since the standard library and 3rd party libraries are still primarily exception based. You either have to live with it or create wrappers that catch errors and return them as values.


> You either have to live with it or create wrappers that catch errors and return them as values.

Some of us used to wrap php "errors" to convert them into exceptions. Then I switched to Python and was pleased to see the pointless distinction between errors and exceptions gone... not gonna go backwards on this.


> Some of us used to wrap php "errors" to convert them into exceptions.

Did exactly that back in the day, this comparison is flawed: PHP errors (and warnings, notices) by default went completely outside the flow of the program, and converting them to exceptions was a means of forcing developers to deck with them right away, sometimes at all.


We write wrappers for standard and third-party libraries that throw errors. For example, we have our own dump_json function that catches-and-returns errors thrown by json.dumps.

We didn't need many wrappers given the nature of our SDK, but some programs will need many wrappers and that could get unwieldy


But people are going to import your SDK, so your customers will be stuck with a mix of thrown exceptions and errors-as-values in their code.

Based on your decision to write wrappers internally, presumably you'd argue that the sensible thing for them to do is to write wrappers either for your SDK or for every other library to get back to a consistent style and less mental overhead.


Author here!

We don't return errors in our public methods so our SDK still feels Pythonic. We're debating whether to add `_safe` suffix methods that return errors to give people the option, but for now our library only throws errors to consumers.

You might ask "well what's the point if you still throw errors to consumers?" We feel that forcing our engineers to deal with errors where they can happen is worthwhile. Our team writes a lot of Go and we love how it forces you to think about every spot that can error, so we wanted the same experience in Python


OK, in that case I think it's a very reasonable choice! Perhaps it's worth clarifying that in the article.

I might express a slight preference that your internal code is idiomatic if I'm going to be poking around in there at some point. But I wouldn't be bikeshedding about your C coding style if you'd provided a Python module written in C, so I don't feel I should have a strong opinion as a user here.


Although I liked the proposal (the `-> User | Exception` idiom is quite beautiful), that's a deal breaker.


I always thought it would be cool to build an entire toy “stack”. Maybe start with a language, DB, and web server. You could start out simple, for example building a language that transpiles to JS, and overtime replace parts with lower level implementations


It can go a lot deeper: take the Tokyo University CPU project as an inspiration:

You need to use FPGA board to build a machine that runs an OS ported to this architecture, which has a high level language with a proper tool chain, all built by yourself. Then you use the language to build DB, Webserver and such.


CSE 374, good times :)


+1, being able to write tests that access private fields and functions means you never need to expose behavior or data purely for testability


I’ve always felt that strings are a little abused, we say “string” when we actually mean 100 different things.


I got it to solve day 1 while playing with it yesterday, not shocked at all that this happened. Wonder if they'll try to prevent this somehow to preserve the competitive nature of AoC...


That's probably an impossible task. The best they can do is ask contestants nicely not to do this, but that opens the can of worms of whether tools like GitHub Copilot should not be allowed, either.


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

Search: