kernelbandwidth

Counterpoint: k8s is a bad orchestration system with bad scaling properties compared to the state machine versions (Borg, Tupperware/Twine, and presumably others). I say this as someone who has both managed k8s at scale and was a core engineer of one of the proprietary schedulers.

Assertions don't actually have to kill the program. They send an abort signal, which means you can catch them with a signal handler.

I similarly wrote a simple C testing framework for a little project I was working on, based on assertions. The framework uses signal handlers for aborts and segfaults, and then setjmp/longjmp to handle resuming the test suite at the next test case. This has the particularly nice effect of turning segfaults into (marked as such) test failures, instead of just terminating everything. It probably wouldn't be too hard to fit custom messages in too, but I hadn't felt the need yet.

Missing Stephenson's The Diamond Age was a bit of an oversight as well, considering that Snow Crash is one of the canonical Cyberpunk novels, while The Diamond Age is (IMO) a defining Post-Cyberpunk novel. The Diamond Age opens with a Cyberpunk fake protagonist written with every Cyberpunk trope in mind, and then the fake protagonist is killed off before the end of the Prologue and the real protagonist, the slain punk's baby daughter, is revealed. Stephenson's intent is clear: "This is not a cyberpunk novel."

I'd also argue that Cyberpunk does not mean "everything is terrible", nor does Post-Cyberpunk have a softer and lighter view where "not everything is terrible." Rather, the difference is whether social control is rooted in 1984 or Brave New World.

From this point of view, Ghost in the Shell and Minority Report are still Cyberpunk (edit: settings); the viewer is just seeing things from a point of view other than the completely marginalized. Shadowrun is a Cyberpunk setting whether you work for a corporate power or in the streets.

It's funny to consider that one of the canonically great philosophers in history is known essentially by the equivalent of his WWE wrestling name. It's like if in the future there were classes taught on the philosophical ideas of "The Rock".

As an adventure game lover, I think this is a great little game! I love dark, macabre adventure games and I'm really digging the art style here. The mood is very consistent and the creepiness really comes across. Your daughter has done a great job!

This is supposedly a feature and not a bug of CAPTCHA, at least according to the apocryphal story John Lafferty told me. IIRC, this was at CMU so he must have been referring to the 2003 CAPTCHA claim by von Ahn et al. The idea was primarily to stop spammers, but also secondarily to make them more useful. The argument was that if spammers managed to "break" CAPTCHA, then whatever technology was used to break it would necessarily be a useful (compared to 2003 knowledge) advance in AI, so it was a win-win whether it stopped spammers or just made them do free out-of-band research.

I'm not saying it was all bad, just, you know, mistakes were made.

This is pretty funny.

"Did Millennials kill fashion?" one of those headlines reads.

No, I've seen what y'all did in the 80's and 90's. If Millennials killed fashion, it was a merciful death after that.

Would you call Erlang/Elixir actor-based or just having actor-like features?

Actors in Erlang seem more emergent to me than fundamental. To first order, Go and Erlang use similar concurrency strategies with cheap green threads and channels for communication. The main difference being that Go has channels as separates objects that can be passed around (leaving the goroutine anonymous), while Erlang fuses the channels into the process. In this respect, they both have similar levels of "actor-ness" in my mind. The biggest upside that I can see to channels being separate is that a goroutine can have multiple channels, they can be sent around (though so can PIDs), etc. This matters a lot because the channels in Go are statically typed, while Erlang/Elixir's dynamic typing makes this less meaningful since you can send anything on the same channel.

Of course, I supposed if one defines an actor as a sequential threaded process with a built in (dynamically-typed) channel, then Erlang is actor-based, so maybe I contradicted myself. In Erlang/OTP, the actor part is important to the supervision tree error handling strategy, which I think is the biggest upside, but it's not obvious to me that you need the channel and the process totally fused together to handle that.

Specifically in response to your "cheap concurrency good, actors bad" thought, my hypothesis is that actors are at least the more natural strategy in a dynamically typed language, which is why they seem to work well in Erlange/Elixir, but don't see much use in languages like Haskell (or Scala, it seems, where I at least though the Akka actors were kind of awful). Meanwhile, channels seem to fit better with static typing, though I can't quite put my finger on why.

The request for use cases in Go seems a bit like begging the question to me. Since Go doesn't have generics, anything designed in Go will necessarily take this into account and design around this lack. So it's relatively easy to show that Go doesn't have a compelling use case for generics, since the designs implemented in Go wouldn't (usually) benefit from generics!

Rust has generics and traits/typeclasses, and the result is my Rust code uses those features extensively and the presence of those features greatly influences the designs. Similarly, when I write Java, I design with inheritance in mind. I would have trouble showing real world use cases for inheritance in my Rust code, because Rust doesn't have inheritance and so the designs don't use inheritance-based patterns.

Essentially, how does one provide real world evidence for the utility of something that's only hypothetical? You can't write working programs in hypothetical Go 2-with-generics, so examples are always going to be hypothetical or drawn from other languages where those tools do exist.

This is so very true. I find Scala tends toward the classic "read-only" joke. You can write very powerful code, but it's often hard to debug and it tends to be quite difficult to read down the line. We have a Scala application that is being slowly replaced, but which I maintain in the meantime, and it is by far my least favorite job duty, despite that I theoretically like Scala more than, say, Java.

Probably my biggest disappointment with Scala is really the type system. It's incredibly powerful, but it's unwieldy to use, and it's still full of footguns. "object" is great and useful until someone accidentally turns it into a giant race condition (true story). Traits can easily turn into a maintenance nightmare (ever seen an 8-way multiple inheritance scheme that fans out into 23 separate ancestor classes? I have!) Exceptions end up in a strange territory. There's ways to handle all of this (much of it involves "don't do that!"), but the point is that for all the type system's powers, it's not actually buying you that much except in comparison to Java 6/7. If I want powerful type magic, I can use Rust or Haskell or similar and get stronger guarantees from my compiler. If you're writing "better Java", which is traditionally one of the more common Scala uses, it's harder to justify over Java 8 or Kotlin these days.

All of which is to say, Scala is a really cool language, but I wouldn't write new projects in it if I didn't have to.

Bonus round: We had a Scala iOS app via RoboVM before RoboVM support was yanked. It still gives me nightmares.

This is my neo-Luddite response to a lot of "there should be an app for that" kind of comments: "Have you tried using a pencil?"

There's lot of reasons to use computers, but there's also a large problem space where it's really hard to beat pencil and paper. They even usually come pre-installed in most offices and homes.

Strictly technical? Determining the existence of metastable states for the T-cell receptor protein in solution (PhD Dissertation topic). Sort of difficult science, though it seems quite easy in retrospect now; the project wasn't so much hard, as it just cut across a lot of disciplines. Poor developer interview answer though, as it didn't involve a lot of software development (lots of TCL scripting for data extraction and ML with Python instead).

The answer I used to use was a problem I had working as an R&D intern: determine when the speed limits posted on a street have changed from measurements of driver behavior. Interesting and fairly tricky ML problem (weather is a big confounder). Ended up writing a lot of C to get high enough performance to make the solution reasonable which was educational (I didn't know a lot of C at the time), but almost certainly not the right approach to the performance problem. Still more science than development, so it depends on who's asking.

Probably the hardest business-type technical problem I've encountered is database restructuring. We moved (a subset of our data) from a NoSQL database to SQL as part of larger architectural changes, and mapping, migrating, and maintaining compatibility has been non-trivial.

The hardest problem I've encountered has been helping to rescue a project with a severely dysfunctional development history. Much more project management and people than technical (it was just a CRUD app) but I came into a project that had been in development for a year or so and stalled out. The development was outsourced and I fell into a position as a liaison between the internal folks at the university that wanted the product and the dev team that had been hired to build it. Sort of a classic issue where the dev team and the stakeholders would talk right past one another. It drove me crazy at the time, but an excellent experience in retrospect. And it has a happy ending; the project went on to be successful after that, at least when I last heard.

Well, one major advantage for the Rust compiler is that it compiles Rust code, which I happen to have a decent bit of.

Joking aside, I'm not arguing that the Rust compiler is "better" than any other compiler. The Rust team seems to have done a great job with it, but I'm neither a PLT guy nor a compiler writer so I can't profess an informed opinion there. What I am interested in though is the Rust language semantics (which the compiler enforces, just as every correct compiler enforces the semantics of the language it compiles). Rust-the-language provides benefits that we (my company's engineering team) finds to be valuable for writing our software -- a strong, flexible, static type system; Option/Result types; the ownership model that promotes good practices and prevents a lot of concurrency bugs that a GC would not help with; drop semantics which allow interesting and powerful techniques with smart pointers. As a bonus, Rust-the-ecosystem includes some excellent and ever growing tooling that lets us focus more on solving development and business problems.

As for Rust-the-compiler, others have already done a better job than I think I can, so I'll let those comments speak to the issue.

Other people accomplish great things with other tools. Rust works really well for us though, and I like to share that.