nitely

That would unblock all coroutines waiting for the promise, instead of just the first one. It's not that trivial, that's the point.

Since booleans can't be awaited until their state is negated/toggled, I'd say a lock that works like a lock is needed.

> This assumption is false. Either the flows are written in code, are you have to have them in your brain every time you are reading some code which can handle 10 flows.

No, it's not. Your interpretation of it is wrong, though. No code means no bugs, this is true. Now, write a new feature, unless the code is flawless, the code-base will certainly have more bugs than before, this is true. Now, write a linked-list, unless the code is flawless, the code-base will have more bugs than if using the one in the language std-lib. About language features, writing 5 implementations of a linked-list for each type instead of a generic one that it's type checked will certainly contain more bugs as it's more error prone to write the same things 5 times and keep it updated.

> Less code means less readable.

This is ridiculous. Otherwise, we'd all be using assembly. About Go, the lack of generics and simple error propagation is detrimental to being readable. Every function can fail, you don't say!. You're manually propagating the error instead of handling it here, you don't say!. That's what I think every time I go through some Go code-base.

Well, I'm amazed they allowed you to run the code at all. In an interview you are expected to test the code by going through it and write the state of the program as you go (i.e comments about the state of some variables in each iteration of some loop and stuff like that). The rest of the feedback is just how they justify themselves.

> the places I’ve been are less formal than that and they might be concerned about slowing down turnaround times during the day

I'd be more concerned about code being committed to master without code review.

I can see how this would work for software boutiques doing fairly similar projects each time, or projects with very similar parts, but not in complex products. Much less for software that does not use any kind of framework or follows any kind of recipe. Sometimes it's just step 1 in a loop.

Sure, but here it's a local mutation, it won't leak to the rest of the program. There is nothing wrong with mutating acc in reduce.

7 hours of meetings? did people show up the next few days for work?

You are not alone. Meetings just suck all the energy out of me.

This. There are plenty of backward incompatible changes in every minor version bump.

Well, maybe if someone record it and put it on social media. Otherwise, I doubt it. Actually, even then I doubt it, I've never seen it happen. From the article, it does not look like they got fired.

They were drunk, so probably not at work. Not saying it's right or wrong. But probably less wrong.

There are always unforeseen requirements or some requirements are very loose because there is really no way to know something will work until is tried.

If there were any protocol that requires discussion about every little thing you would never ship nor be productive.

So, companies relies on programmer's judgment on what to do when there is no clear resolution or something is not perfectly spelled out.

The article is a rant about bad code, not about bad teammates. Maybe they were hired because the manager liked them for having people skills instead of actually being good at their jobs. I agree communication is an important part as well, that does not has much to do with people skills, though. Being a good programmer should be more like 75% of a programmer's job to actually make their temmates life easier.

How many nights and weekends should be uselessly wasted on homework for every interview?

At least whiteboard requieres practicing for real once in a life time.

The pythonic way is to do duck typing, meaning don't check the params types at all. Assertions are ok to check things that should never happen. But if you're gonna put them everywhere then better use type hints. I'd use TypeError on public APIs, for private APIs is as bad/good as assert.

Make mypy type checking part of the CI pipeline. Done.

> Simplifies refactoring tools.

How? we would just have case insensitive refactoring tools.

> Encourages a consistent style in the ecosystem from the beginning.

Python, C, Java, etc are case sensitive langs, and it's possible to define function names in all upper-case and do all kind of inconsistent styling. Python has pep8 for a reason.

> Not needing specialized tooling to grep for an identifier in a codebase.

If all langs were case-insensitive, all those tools would be case-insensitive by default (or we would all know the right combination of flags to make them behave).

> Being able to Google a particular function name.

Is google case sensitive? In any case the lang would define a preferred style, like all case-sensitive lang do anyway.

> Consistency in identifier naming when looking at a stacktrace.

Same as above.

Parent said "if a language were to be designed today in a vacuum", I don't think any of your arguments hold.

I've aced every whiteboarding interview when the problem was the same or similar to some problem I solved before, and I failed pretty much every interview when the problem was new to me (except when the problem was trivial, ala fizzbuzz). I think that proves how whiteboarding just tests whiteboarding skills and nothing else.

0-9 is defined as a [ascii] range, so you are correct.

I think parent means that even if you "sign a contract assigning all IP to their employer", you can still write OSS code in your free time, since there is no way your employer will find out, and even if they do, they've no way to prove you wrote it, except if you "sign it", which no one does.

Some of the syntax is similar, but similarities end there. Nim was inspired by many languages: Modula 3, Delphi, Ada, C++, Python, Lisp, Oberon, C# and Pascal.

Sounds like a good way to filter out a certain kind of users.

Fixed. Thanks :D

It's important to handle many socket connections for once. Where "many" may be in the order of million. If you wonder who on earth need that many connections, there are many use-cases like pub/sub servers. Native threads and processes use an excessive amount of ram and context switching is way slower (more so for processes) in comparison. Not to mention asyncIO allows sharing memory (without copying), which processes will not (message passing through pipes or sockets is way slower) and since asyncIO is non-preemptive, it make it easier to deal with shared state than when using preemptive native-threads.

Doing asyncIO was a way to solved the c10k[0] issue back in the day.

[0] https://en.wikipedia.org/wiki/C10k_problem

Why would it be ok to suggest changes after a year then (which is fairly arbitrary btw), according to that logic?

TBH, I'd only suggest changes when they are really required (i.e scalability issues, maintenance issues, etc) but that has nothing to do with how long I've been working in a project. Requiring a year of knowledge about the domain is nonsense to me.

There is an AWS cron service, it actually runs on top of lambdas[0]. If your definition of "abuse" is triggering an event with cloudWatch, then every service must be "abused" (SNS, S3, dynamodb, etc) as well.

[0]: https://docs.aws.amazon.com/lambda/latest/dg/tutorial-schedu...

AWS KMS

Clicks have a 200ms (IIRC) delay on Android to give a chance to recognize other gestures. There are hacks to get ride of it, though. It may have to do with that.

Here[0]. Mutable objects as default values create a single instance of the object. For iterables (list, set, etc) the behaviour is particularly surprising coz it accumulates/memoize every item ever added (i.e a list that grows/leaks with every call to the function). If you use a good IDE (like pycharm), it will warn you about this stuff.

[0] http://docs.python-guide.org/en/latest/writing/gotchas/