HN user

scudd

149 karma
Posts0
Comments49
View on HN
No posts found.

Sand Hill Road is a road in the SF bay area where a lot of VC firms have headquarters. People use "Sand Hill Road" to refer to the SF VC industry the same way people use "Wall Street" to refer to NYC based finance.

I'm not really what the official definition of blitzscale is (or if there is one). I assume it means scale (specifically grow head count) really fast.

I always thought names like "180 nosegrind" made no sense. Why not "180 switch 5-0"? That seems so much more intuitive.

It made so much more sense when I learned a lot of these tricks were first invented in the 1980's, when most boards had an obvious nose versus tail difference. Like this one:

https://i.etsystatic.com/6865693/r/il/f51835/361296329/il_15...

So even though you we're grinding in a switch 5-0 looking position, you would be clearly grinding on the nose, hence "180 nosegrind".

In general I find I'm productive in Rust; however, I do agree that there are some features that produce more confusion and debugging than others. For me it seems to be async and dynamic dispatch that are tricky.

I could not agree more.

Additionally, if you are going to use a QR code and web page as opposed to a physical menu, there's no shame in just statically hosting a PDF of your menu.

It's so frustrating that some bars/restaurants use some third party App that wants me to store my email address and credit card. Also janky UI that's totally unnecessary, considering a static page totally suffices.

I think Beej's Guide to Network Programming is IMO hands down the best resource I've come across: https://beej.us/guide/bgnet/

It also doubles as a very great introduction to C, if that something you're interested in. It's funny because both C and socket level programming are often a barrier, or at least they were for me. It's an attestant to the quality of Beej's guide that he introduces both simultaneously, and makes it very approachable.

This is one of those sources that helped me disproportionately grow as a programmer in a short period of time.

What I'm seeing is a lean (at least in large companies) to offering more associate choice towards WFH/office going forward. If there are natural skews in terms of which populations will gravitate towards each option, what are the social consequences of that?

For example, if we're thinking about age, what does a team look like after a year when only the junior level staff have been coming in to the office? It seems like that could have significant effects on team-building, and leadership relationships.

(I'm admittedly biased towards in office work. I personally feel both more productive, and happier when I have segmented spaces for work and home life.)

I've absolutely loathed working from my makeshift bedroom office for over a year. I rent a townhouse with multiple roommates, and there simply isn't communal space to accommodate everyone setting up their own personal office.

My perspective is many of my older (and more financially established) peers have spare bedrooms converted to offices, which I imagine makes long term WFH more digestible.

I wonder if WFH/office skews around age, or other criterion. If so, what are the long term social implications of a dual WFH/Office option.

Is there any thought to including a default executor in the standard library? I think it's kind of an obstacle for beginners when the language/stdlib provide all the tools to write async code, but not to run it.

I saw discussed in this talk the intent in allowing developers to provide their own executor based on the specifics of their use case: https://youtu.be/NNwK5ZPAJCk?t=1107

This makes sense to me; however, I feel like the defacto at this point is that most people are using tokio. Is there a possibility that a default executor could be provided, and allow developers to override it with a custom library should they chose?

I think that consideration of libraries is a good point, I didn't initially consider, and especially relevant for Python.

I think the one connection I'd make back to my original point is that perhaps python becoming the defacto interface for certain libraries is still a reflection of its core values.

This is especially evident with libraries like Tensorflow, which have interfaces for a breadth of languages, and which the core is implemented in C++. The reason people tend to reach for python to call into Tensorflow is still the core platform values of ease of use, rapid prototyping (imo).

I can't help but feel like if you want static typing, you're better off recognizing that python is not the right tool for the job.

Admittedly I've never done serious work with mypy (or typescript), so I'm approaching the value proposition of dynamic typing at face value rather than experience. However, it seems like the primary benefit of these languages was ease and flexibility, ableit at the cost of structure. Or said differently, adding mypy feels like trying to get out of a trade-off decision.

This situation reminds me of a talk Bryan Cantrill gave on platform core values, and as examples he gave his interpretation of the platform core values of languages like C, Awk, and Scala: https://youtu.be/2wZ1pCpJUIM?t=349

For me, platform core values that stick out for python would be Approachability, Simplicity, and Velocity. I understand the posited value mypy brings to the table, but it feels in contention with the original core values that made python appealing to begin with.

I think the value of calming down is normally to not send impolite or passive aggressive communications.

I don't have so much experience interacting with recruiters/hiring managers. However, every time I've let some frustration show at work, in the moment I felt vindicated and righteous, only to feel like an ass about 24 hours later. Normally when I feel the need to vocalize a frustration, I try to write down or remember why I'm frustrated, but wait to actually action the communication until I'm calm. Goes a long way to focus on solving problems, without identifying people as the problem.

Hey just FYI, when you run the hackernews and explore examples without enabling the tokio feature flag, you get compilation errors about undeclared types for all the tokio stuff. I think these examples just need entires in the Cargo.toml requiring the tokio feature like the reddit example.

Once I add the tokio feature, they all run as expected.

Cool library, I might use this for a side project I have also parsing HTML data from HackerNews.

What are your impressions of scraper and html5ever? When I initially looked at HTML/XML parsing libraries for Rust, there didn't seem to be a standout library such as serde_json for JSON data. I was also considering using scraper + html5ever. However, I'm curious if scraper adds enough to warrant the additional dependency as opposed to directly using html5ever.

Hemingway Editor 6 years ago

For the simplest of communications, like an IM or short email, maybe using checklist rules does impart more good than bad.

But I think in larger writing pieces, including those technical in nature, these rules produce low quality writing. In my experience it produces extremely curt, choppy writing with overall bad flow. It almost feels like a bulleted list converted to a paragraph, with a sprinklings of "and"s, "so"s and "because"s. And while "flow" sounds like a wishy-washy concept, I think it is effectual and worthy of first level consideration. It shapes how well your ideas synthesize together, and ultimately how well you communicate your thoughts, ideas, and feelings.

Hemingway Editor 6 years ago

This reminds of the technical writing education I received in college. While I understand the goal of this guidance is to make technical communication as clear and concise as possible, I also feel like it leads to a world of boring writers. And (IMO) boring communication actually should be recognized as worse communication, in comparison to communication that combines technical detail with human deliverance.

The problem is all the more exacerbated when the guidance uses a checklist-like rubric such as:

-"this sentence exceeds X word count, consider splitting"

-"this sentence uses passive voice, use active voice".

I remember "revising" parts of my senior design to score higher against a similar rubric, despite being confident that the revision was overall worse.

Writing quality is inherently subjective, maybe to the chagrin of engineering types. Even though there are horrendous emails and documentation in the wild, I still think teaching people how to write with tools like this isn't the solution.