HN user

mic47

481 karma
Posts2
Comments161
View on HN

I've used python typing heavily at work and was really useful to detect bugs and helped with developement.

as evidenced by only 15% of repos passing mypy

That is no evidence. Of course, if you don't have mypy in CI (or pre-commit hooks or whatever), your repo will not pass mypy. But if you have it in CI, then you can rely on them being correct.

tools like pytype or mypy will never capture all the complicated hacks possible

But they can either enforce everything being correctly typed (if you go to really strict settings), or yes, you will have some code untyped, so you will be careful around that part. It's not like all or nothing.

But for wast majority of pull request branches, people are not checking them out. And if so, they are not modifying it, so dropping local branch and checking fresh one is 20s additional work.

Additionally, technically speaking --force does not overwrite history, it just moves the branch pointer. Old commits are there.

First, never use --force, but use --force-with-lease -- this will fail to push in case someone make remote changes. Useful if you are collaborating on branches (or develop from more than 1 computers).

It can't pause when a conflict occurs, so you have to fix the conflict and (somehow) re-run it from the point it stopped at, which is fiddly at best.

There is better way: 1. I use `git rebase -i` from the top of the stack -- it opens a vim with list of changes it's going to do. 2. I have script (https://github.com/mic47/git-tools/blob/master/GitStackTodo.... ) that process this and inserts commands to backup branch and move branch to new location to TODO list. At this point, I can even modify the TODO list to rip out commits I don't want, or squash commits i want. Or you can reorder commits (I usually do code review fix at top of the stack and then reorder commits -- at least if I am reasonably sure there won't be conflicts for this fixes). 3. At this point, you can insert more things, like run tests after each branch, or commit (and pause rebase in case of failure, so you can fix it). 4. When I close this file, rebase starts. In case of conflict, rebase pauses, let you fix it, and when you continue rebase, it will finish the TODO file. 5. After, I have script that removes backup branches. 6. I have script that runs command on each branch, so at the end, I do this to push my changes `git stack-foreach master git push --force-with-lease `

What if you can't resolve conflict and you are in the middle of the rebase? You can run `git rebase --abort` and it will restore top of your commit. Only drawback is that branches that were rebased are not restored, but hence my script also create backup branches so I can fix that manually and move branches back.

Depends on how her/his skills apply to such company / role.

I.e. at FB, you could be E7 by just technical work, but you had to be really good and be able to pick important problems and solve them (say that you are able to design and implement core systems for example). But it's easier to get above E5 by going TL way.

I worked for FB (left in 2018), and you are right. He started as E4, which means that he was not new grad (new grads starts as E3). So he was either phd, or had industry experience before.

His first year: "Because of the 3 launches and building a 4 people team, I was promoted to E5" -- looks like he should have been E5 when started (given that he was able to build team in the first year), and they quickly corrected for that.

Depends on how you provide feedback. If you get it back from the recruiter, there will be information loss. If it's written by engineers, or given you by engineer (or eng manager, who understand the feedback) personally, it end up much better -- because it's easier to mitigate any misunderstanding.

They will not cut ads off. They will try to consolidate ads and use ad budget more efficiently. Most likely, google, facebook ads are more likely more effective than non-targeted ads like TV, so while total ads budget goes down, targeted ads budget don't.

Or there could be other effect...

Yes. I imagine, we would have hashtags, and algorithmic hashtags (in case your uncle stops using #rightWingConsiracy hashtab because everybody is filtering it?) and ability to filter by hashtags (with ability to selectively pick whether you block algorithmic hashtags, or normal hashtags). The problem I see is that your uncle might get offended that FB is marking his posts #rightWingConspiracy).

I'd like to point out that this is a 180 from Zuckerberg's "arbiter of truth" position from before the advertiser boycotts

Not necessarily. You can hold both views and be consistent. Lot of people accuse Facebook that it's keeping Trump's content for money (i.e. it increases engagement). In that context, sentence "There is no incentive for us to do anything but remove it." is trying to refute. And that would be consistent with FB not wanting to be "arbiter of truth", and keeping "newsworthy" content.

Git is so pervasive in software development that I think you will be at a disadvantage if you give up on it.

I would call BS on this. Yes, git is pervarsive, but if you learn alternative tool (mercurial, perforce, even svn), you will find that learning git (at least for being productive on team that uses git) is straightforward.

Also, haven't seen a company that actually tried during interviews ti figure out if you know how to use git or not.

Statically-typed languages can guarantee to get this right 100% of the time.

No they don't. They usually provide escape hatches for things typesystem does not cover, so there are cases where typechecker will just trust that you know what you are doing (even if you don't).

But more importantly, you don't need 100% to be useful. For aid in IDE, high precision (with somewhat lacking recall) is good enough. Of course, for refactoring, higher recall, the better (but you could substitute lacking recall with tests, which is suboptimal, but viable).

But it's interesting question on what python/mypy (python typechecker) can actually do. The answer here is it depends on configuration. Mypy with default configuration typechecks only typed code (i.e. functions which have type annotations) so you get guarantees only there. But you can configure it to be more and more strict (checking untyped defs, not allowing untyped code, and more), which increases guarantees you get (and it also increases the number of valid programs that it rejects). You can get in python into really strictly typed code, but you can also hit the wall if you need libraries that does not provide proper type hints (unless you write type hints by yourself).

Functions allow shared state, they don't isolate errors.

So why not use Haskell (or other pure language)? It's pure, so functions don't share state. And you don't have to replace function call with network call.

I have similar setup (infinite history, remember directory, shell session, ...), and then ctrl-r runs fzf that find the command first in this session, then in the same directory, then in the rest. I already hinted about that setup here:

https://news.ycombinator.com/item?id=22504950

Note, that just logging your directory, time and command in text file is great help, since if you don't remember something, you can just open the file and find what you need.

Bug bounty programs are not supposed to replace you other security activities, but it's a way for you to have additional source of vulnerabilities. Advantages of these programs is that security researcher will get rewarded when they find a bug, and that there is clear process for disclosing bugs.

You still should hire pentesters, you still should have trusted employees to find bugs and fix them, and more... If you are relying just on bug bounties, your security will suck.

That being said, NDA's sound sketchy, if you disclose bug, than after it is fixed, you should be able to blog about it (or when they do not fix it for looong time).