482 karma · joined December 25, 2016
Literally this. You can pretty much do all of the interviews required for FANG without talking to a human being, which from the FANG perspective, is absolutely GREAT, because it takes all of the existing social biases (e.g preferring a certain race, preferring a certain gender, etc.) out of the window and focuses ONLY on the algorithmic knowledge of the applicant.
Of course, there might be some interview here and there about soft questions, but for the most part, they don't really give a shit about that, and it's unlikely that you'd be rejected based on that, unless you _really_ suck at bull-shitting success/failure stories (which I am - can't stand doing it).
I think the last time I applied to Amazon (over a year ago at this point) I didn't even get phone screened. It was just a link to 2 graph algorithm problems that were the equivalent of a medium difficultly on Leetcode, and I was immediately graded. It's so fricking easy for FANG nowadays.
ETH 2.0 is theoretically capable of 100K transactions per second, but I'll believe it when I see it under real world load. That said, it's good to see ETH finally moving to PoS.
A lot of the "scientific" Python packages (NumPy, SciPy, etc.) actually just call out to C libraries for the majority of their computation. I imagine Julia can do that already, or it can call out to something similar in the stdlib, so it doesn't really need integration with these Python packages other than just API familiarity. But is that worth the cost in performance?
Professor(Professor&&) = delete;Not saying you're wrong, but this feels like every subreddit dedicated to a crypto.
However, I don't think GP's parallel lines up, as another commenter pointed out.
In any case, a single satoshi, which is the smallest denomination of Bitcoin (10^-8 of a Bitcoin), is worth about 0.05 cents as of writing this comment. If Bitcoin didn't have such large transaction costs, slow transactions, and price stability, it's scarcity would be way less of an issue due to this really large level of division of a single coin.
In ye olden days, when Bitcoin was a few cents worth, transaction costs were tiny. I really doubt Satoshi et al predicted Bitcoin to be so unstable, so as to make transaction costs pretty much out of reach for 99% of normal everyday transactions.
Another thing to note here is that these firms can shill any coin they like without any market manipulation accusations from the SEC, were they to do this for any other asset.
Can someone explain what this does? Is this some Perl or Tcl thing? Unfortunately I've never used either :)
It looks like Tauri uses system webviews, which use a lot less memory, but the burden is then on the developer to make sure that they build essentially 3 (maybe more) UI's on platforms that might change under their feet. That's why the Electron approach is simpler - it trades of performance for uniformity of experience across the major platforms.
But I'm wondering if it really has to be this way. Do modern browsers really need 2G of RAM in order to send and receive messages in a chat box (looking at you, Slack).
One thing I like about Rust is that you can implement traits on standard library types. You can imagine implementing a "Where" trait on e.g Vec<T> (btw, you don't have to, since "filter" is already there) that would return an iterator that can be used by the next method in the call chain.
Unfortunately you can't "extend" standard library or built-in Python types like this.
In Rust your example would be:
strings.filter(|s| s.starts_with("a")).map(|s| s.len()).sum::<u32>()Why don't they fit your brain? I wonder if the author ever tried statically typed languages.
> I would like for Python 4 to get inspired by Racket and introduce "dialects".
> Having repeat as a keyword as is available in TygerJython and Reeborg's World for the construct repeat nb_steps:. It might perhaps be also useful to have repeat forever: as equivalent to Python's while True: . [Other possible uses of this keyword are described here.]
I don't see how this would be beneficial. You're basically proposing that beginners learn something that is literally not Python - then when they switch to the "main" dialect, they have to re-learn basic things all over again.
Lisps have this neat functionality where you get to basically define your own syntax, and that's really useful in a small set of cases (i.e macros in Racket, super duper useful, would wish C macros were as clean as Racket macros). But Python simply does not fit this mold. It wouldn't do Python any good to have a macro system - and it definitely wouldn't do it good if it has 4 different sub-languages, each of which have it's own syntax and warts.
Stroustrup said "Within C++, there is a much smaller and clearer language struggling to get out." The Python the author is describing is to me, even worse than C++ in terms of complexity.
Since switching to asyncpg [0] these problems have vanished. It commands a deeper knowledge of actual SQL, but I would argue this knowledge is absolutely necessary and one of the disadvantages of an ORM is that it makes the SQL that is eventually run opaque.
Not sure if there are equivalents to asyncpg for other RDBMS's.
* Camp 1: generics will always be horrible, Go is right not to include it, it's too complex, Go is meant to be simple, etc.
* Camp 2: I will never use Go because it doesn't have generics, serious languages have generics, etc.
When in reality, both camps are pretty much wrong. Yes, generics are useful in a lot of places. But they also add no value in a lot of places. It's really on you to pick the tool you want to use. If you really want generics, pick C++ or Java instead. If you couldn't care less, Go is an option. It's much more fluid than this binarization of the topic has made it out to be.
I'm not sure how the generics implementation in Swift has any bearing on how generics will work in Go.
Researchers want to get their work done. They don't want to fight against their tools.