d0m

IMHO, the framework vs library debate is similar to the inheritance vs composition.

Inheritance: You must predict how people will use your class. Make a mistake and they're screwed and need to resort to all kinds of hack. (Like frameworks)

Composition: People will use your class if it fits their needs. They can easily wrap the code, tweak or simply discard it. (Like libraries)

Quick suggestion: Sort game name A-Z

Another contrarian opinion, but as much as configuring and tweaking conf files are fun, it's still faster in the long run to be highly efficient on a new system as fast as possible. It's also convenient to use standard tools to be effective on someone's else computer. For instance, it's much better if you can be productive by changing 2-3 keys in macOS settings instead of being forced to use a fancy keyboard layout and customize shortcuts for everything.

Rather than using cmd-tab, using pre-defined shortcuts to jump to the right [workspace,window,tab]; make sure to disable any animations.

Contrarian opinion, but often doing things manually rather than automated will save you time. Writing/debugging a script is fun, but more often than not it would have been faster to do things the dumb way. If a task is risky or repetitive daily, then sure, but often developers confuse "writing a script because too lazy to manually do the work" vs "get the task done as fast as possible".

I'm a big fan of the default table with an url and some tags. Gets me 90% where I want most of the time

Yeah; A real "Hello world" quantum program is randomly printing 0 or 1 without any pseudo-random generator. At the most fundamental level, the quantum-bit can be in many states, but when measured will "jump" to either 0 or 1.

In that website's playground (https://quantumjavascript.app/playground.html), just write:

   H

And you'll get 50% 0 and 50% 1.

Now, /why/ does it jump when measured? We don't know, but physicists have many cool theories.

One of which is that it doesn't really jump, but just that there are many universes created and one shows a 0 and another one shows a 1 (Called the Many-worlds interpretation). As weird as it sounds, it seems like the most promising explanation. There are other theories but they all need to add hacks to make the maths work.

It's great to see new football strategies. But I agree, personally I'm most excited about proving/discovering new math theorems using ML.

On my side, here's how I configured my mac.

Workspace at the top level.

- cmd+f1..f9 --> Switch to workspace. - cmd+ctrl+1..9 --> Also switch to workspace (because fkeys are removed and the touchbar is terrible)

Inside each workspace, I use one app in full-screen.

Workspace 1 = IDE Workspace 2 = Terminals Workspace 3 = Browser Workspace 4-9 depends (Spotify, debugger, etc.)

For each app, I switch between tabs using cmd+1...9.

So intuitively, to jump somewhere, cmd+fX to go to the right workspace, then cmd+X to jump to the right tab. For instance, I know my database logs are always in the first tab of my terminal, so: cmd+f2, cmd+1. (On the mac with touchbar, capslock+cmd+2 then cmd+1 (as capslock is bound to ctrl)).

I try to keep this nomenclature everywhere as much as possible. For instance, in Chrome, cmd+1..N jump to the right tab. I configured vscode to do the same. I also disable any transition animations.

For me, this is so intuitive and fast that I have a hard time using 2 monitors as it's faster to jump to the right place than moving my head around or to find the app using cmd+tab.

Finally, where it makes sense, I sub-divide some tabs in tiles. For instance, my "web server tab" is often divided in 4 tiles. Or my IDE is split in various tiles with the files I'm working on.

I used a similar approach back then when I was using stumpwm on linux and tried to bring it back to my mac with as little configuration change as possible. (I only have to map caps lock to ctrl and tweak a few hotkeys to switch workspaces).

It's funny, I had this similar idea just last week. It's been hard for me to read books with a baby but I can afford to read emails here and there.

Commure, Inc. | San Francisco, CA or Cambridge, MA | Rust Engineer | Fulltime | ONSITE

We are a stealth startup working to fix the software doctors use. If you have seen what physicians have to put up with, it's a bad version of the 90s, and makes medical care worse and more expensive for everyone. We are a group of previously successful engineers and entrepreneurs (MIT, Dartmouth, Brown, Stripe, Twitter, Google, Salesforce, Palantir, DataPower, etc) and senior doctors (Johns Hopkins, UCSF, etc) who are determined to finally fix this.

Compensation: market salary & equity -- we are well funded by top-tier VCs.

Stack: includes Rust, React and Kubernetes. In addition to building our back end in Rust, we are also solving some very interesting problems in the areas of security, data transformation, high-speed APIs, flexible UX frameworks and fine-grained authorization for healthcare data.

Please email jobs@commure.com and mention "[hn_rust]" in the subject line.

Other positions available: - Techops/Devops Engineer (Kubernetes, SRE) Senior Front End Engineer (React Native, React) (please use [hn_ops] or [hn_react] in subject line for the above)

Locations: San Francisco, Montreal or Boston; sorry, no distributed/remote option at the moment.

Hey Dalton, thanks for the answer, that's fair. I totally agree that in the long-term, moving and failing fast is a net positive for both founders and YC. I wonder how different the YC three-months experience is between founders who have product-market fit vs the ones who don't? It seems like there's a "cadence" to the program highly focused on growth culminating to demo day?

So, that's the dichotomy of YC.

YC is an accelerator, and as such, needs to accelerate /something/. If you join too early, then it's almost a distraction to getting the product out and talking to users. However, hit the sweet spot and YC is an invaluable resource to help you grow.

On the other hand, YC opens the door to so many opportunities and great people, that even if you're too early, the net result is still a pure positive for your career and startup.

Nowadays, in most system architectures, app servers are stateless and can be scaled horizontally. But something needs to hold the state, and that thing will be the bottleneck. Yes, you can horizontally scale some databases, but distributed state is very tricky to get right and will have performance trade-off.

Say we could break any physical rules of our current universe, is there a good theory that would explain how something might have been created out of nothing? i.e. imagine for a second that we're in a simulation and that the current laws of physic are just arbitrary created by a "host". This "host" could have very different physical laws. Could we think of any theory that would explain the creation of something out of nothing in this "host"?

I'm very puzzled as to why the universe even exist.. wouldn't it have been much simpler not to have anything at all? I can only think of one answer: It couldn't have been otherwise. I.e. physically speaking, it had to happen.

Maybe that's how we should approach the problem? Let's try to "create nothing"... maybe we'll realize that it's actually impossible to "have nothing" unless X happens, and maybe we'll figure out that X happening would explain how our universe was created?

Or said in a different way, maybe the universe is actually "nothing", like it always was and will always be. But "nothing" may just be physically impossible so you need "positive" and "negative" things to cancel each other out so that the end result is "0".

I'm not too sure where I'm going with this, but it reminds me of the quote "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth." So, whatever the theories about big bang, multi-verse, universe expanding/collapsing indefinitely or even God-based theories, all of it comes back to "how did the first thing come out out of nowhere?" People talk about "Singularity", but this is just "kicking the can down the road". Still, by kicking the can I guess we keep learning new things, and maybe someday we will have the technology to answer these questions. Unfortunately, it seems like answering the next frontier seems to be an order of magnitude harder (time-wise and cost-wise) than answering the previous question.

deploying the same javascript code on both web and old android devices (using RN) keeps you honest about performance :O

>> I do think that it will be interesting to see what happens if someone on the core Go team decides to leave Google and but wants to continue working on Go.

Or, what would happen if non-google employees on the core Go team were to take Go in a direction that Google's leadership didn't want to?

Usually, one manager/lead take care of 3-7 people. So rather than making everyone on the same page, I'd spend more time with these leads and making sure that you guys are on the same page, and it will percolate down to the rest of the team. On top of that, well written document with clear goals and high-level strategies help to re-inforce it amongst everyone, but imho it should still be the mid-level manager's job to communicate in 1:1 and in other ways to their team.

When buying on Amazon, I'm mostly interested in the 2-4 range reviews; I find this is where people discuss the pros/cons instead of just the pros (5 - best product ever!1!) and just the worst (1 - it had a defect because I threw it in the pool even though it said don't throw it in the pool and the company doesn't want to reimburse me, never buying from it again yadayada - kind of reviews).

Congrats on the launch and on the UX/UI of the editor. There are so many great features and yet it feels simple and not overwhelming at first.

Most enterprises need a very different suite of features that take a lot of time and $ to build. I don't think it's as cheesy as other people in this thread try to make it sound. Often, you need to deal with a lot more regulation, have data hosted on prem (potentially in a different country), scale in a very different way (I.e. think of how Slack starts breaking at a certain threshold). Risk mitigation is really different too, often startups are way more understanding if your service goes down or has bugs.

Funny thing is when enterprise customers start asking for so many features, you have to tell them "Sure, we can build it, but it'll cost $50k instead of $50", and surprisingly they write you a check, so you start building those features.

Adding on top of what others have said..

* Switch job to a place where you can be pushed and mentored

* Make a lot of mistakes, but be sure to learn from them

* There are so many amazing books where the authors shared their mistakes/experience and how they made things better

* It's often much better to slow down and get things right by researching, discussing and prototyping than rushing and having to rebuild it a few times or maintaining shitty code.

* Try to think of the 10X when working on something. Of course, optimize for the current spec, but what happens if you get 10X more loads/users? Is there a way you can make it work for that use-case with roughly the same time? Often, the answer is yes by using a well-tested library and better tools. Ironically, sometimes being forced to think at a bigger scale makes you realize that your solution wasn't that great after all.. and that this problem was already solved.

mIRC. I built so many things using mIRCScript back then; I learned "dialogs", sockets, many internet protocols, dealing with binary, etc. etc.

I think it's a great idea. So many people would like to learn CS but don't have the time bandwidth; paying them to learn is a win/win.

I hate css, but one of my colleague (who's really good at it) told me once that people have problems with css because they don't study and take it seriously. I.e. I spend so much time reading on new languages and design architectures, but besides some articles here and there I don't study css or take it seriously at all. So yeah, there you have it.

I also think it's getting better. One major problem with css was getting it to work across all browsers, but now if you're lucky enough to only have to support modern versions it's so much easier than it used to be!

Also, a few things

1) How much would it cost for Dropbox to build and acquire/steal those users?

2) Even if 1) is not that high, what is the opportunity cost for dropbox to do so? Yes, they could move a bunch of engineers and PMs to work on it, but then they wouldn't be working on other more important parts of Dropbox.

3) It's not always about how much you get by buying a competitor, it's sometimes about how much you will lose in the long-term if that competitor doesn't go away. Think Instagram and Facebook. $1B sounded crazy back then, but how much would have Facebook lost if instagram kept growing and growing?

Not clear to me why someone would want to invest in high risk startups for a low-mid return.. there are much safer options that would give similar returns.

Like someone else mentioned, early game sc2 is a bit like rock, paper, scissor - scout too early and you'll be behind in economy against someone who's super greedy, but scout early against cheese and you've got a free win. You can take the "conservative" approach which is relatively safe against early cheese while not falling "too far behind" against a greedy opponent, but you'll still be behind in most of the games. If you're the better player though I'd argue it's still better to play conservative, be slightly behind, but win in the late game, while not falling victim of early cheeses.

IMHO it's just that front-end is very complex and we haven't found the perfect solution yet.. so a lot of great people are trying many things

Once you find a real pain points, people will beg you to buy/use your product, even if all you have is a crappy version rushed out.

To be clear, some startups require to have a super polished version to be successful. But even then, there's often a way to have customers pilot an early version or cheaply test the market.