HN user

weiming

1,099 karma

未名

Posts8
Comments154
View on HN

A good friend actually used June Advisors Group mentioned in the article a couple of years ago. The firm (really a sole attorney) sounded very helpful and got his business set up with a residence card pretty easily. IIRC it took a couple of months end-to-end.

The Fourth of July 6 years ago

What me and my family talked about today is that, as immigrants, we are so sad how much the "native born" people of the US hate their own country. They seem to never waste an opportunity to remind others of their disdain and it is more and more visible these days e.g. in big news media or on Twitter.

Makes me sad and I hope this can change.

Apple WWDC Keynote 6 years ago

Nitpick but I hope the overtly (about 10px) rounded corners of running app windows aren't there to stay. Looks heavy/dated.

Curious question as I am not a compiler expert.

I have to do front-end iOS work from time to time and it's surprising how bad auto-complete can be in Xcode with Swift even after all these years: still randomly sluggish, randomly stops working inside closures including completely losing syntax highlighting inside the closure, and even Cmd+clicking to see the definition is a hit-or-miss as it sometimes opens up a blank editor and just spins. I would have thought that Swift having a strict type system would have made the IDE experience better, not worse. Don't know if the grammar is too complex or if it is the bridging with ObjC stuff or something else that made it difficult to build a robust solution. Can anyone shed light on this?

My points of reference are rust-analyzer, or just VSCode with Typescript, both very snappy although of course the languages are very different. If anything I'd expect Swift to be closer to Rust experience-wise since they both have pretty strict grammars.

And so I use create-react-app anytime I need to start a front-end JS/TS project, even if I am not using React at all. Basically avoiding dealing with troubleshooting the soup of build time dependencies and mismatching package versions, which unfortunately comes with the modern JS (or node) ecosystem.

HSV always seemed particularly poorly understood in the society to me, e.g. with many people getting it as children due to careless parents/extended family, and the benign branding of "cold sore" as if it is related to a cold. Given that the vaccine for 1 or 2 has proved to be extremely challenging, always wondered if the public simply being more well-informed on this topic could help reduce the incidence in the population.

Asymptomatic shedding of HSV has to be considered, too. "Transmission commonly occurs from contact with an infected partner who does not have visible lesions and who may not know that he or she is infected. In persons with asymptomatic HSV-2 infections, genital HSV shedding occurs on 10.2% of days, compared to 20.1% of days among those with symptomatic infections." (https://www.cdc.gov/std/herpes/stdfact-herpes-detailed.htm)

Now I'd like some native Rust bindings for Cocoa/UIKit, perhaps as an "official"/higher-level alternative to https://crates.io/crates/objc. There are some crates already attempting to replicate all of Apple frameworks, but they are community-supported/require a bit of `unsafe`.

I also had trouble getting VSCode workspaces to work (i.e. multiple project roots.)

Also at times, when adding a new crate dependency to Cargo.toml or installing a rust-analyzer update, it seems necessary to reopen the VSCode project (not restart VSCode itself) to get it to work again.

This said RA has been indispensable over the last few months, thank you to the authors!

Oh, I'm totally fine with Ok(123). The current syntax with Result is explicit and flexible even if slightly verbose. It's especially nice that Result is an enum like any other.

There is already precedent of somewhat magical syntax changing the return type, namely 'async' making the function return a future<your stated return type>. While this approach adds one more non-obvious thing for a newcomer to learn, it shouldn't make it much more difficult to reason about your code once you know what to expect.

My gripe with Swift (and I've written a lot of it) for purposes requiring a lot of number crunching is the performance issues associated with default use of copy-on-write types/ease of accidentally writing O(N^2) code. In Objective C the behavior was more obvious with NSMutable* types being front and center.

DefaultApp 6 years ago

Tangential: we've been using xcodegen (https://github.com/yonaskolb/XcodeGen) to generate our projects from a simple yaml file. Don't need to muck around with Xcode toggles, easily repeatable, and .xcodeproj literally stays in .gitignore. Never know why Apple consistently shyes away from more programmatic generation of stuff.

If you can share, how usable is your approach boilerplate/types wise? Would love to go all into Rust but the AppKit/etc. bindings get clunky very easily.

It's very easy to cross-compile and use Rust as a library, leaving the Swift portion for display/views only. We are looking at doing this for our next app (OS X, but would work just as fine for iOS).