Hi. Author of the article/gist here. It was actually written in Spring of last year, I think. I've just updated it because, as people have said, many of the issues have been addressed one way or the other:
* The KafkaREST proxy makes life a little easier
* librdkafka makes life a lot easier, especially when you can just download a thin wrapper around it for your chosen language
* I am no longer working at the place that chose Kafka 0.8 following no testing at all for their use case, and refused to back down through months of hell both writing code and trying to keep clusters available
* The people at Confluent have done a lot of good work since then, both on Kafka itself and on various auxiliary tools/products.
So yeah, I would probably look at Kafka again today if I needed that kind of functionality. Screw ZooKeeper though.
React is not "eating Angular's lunch". The only reason it seems that way is that it is impossible to have a conversation about Angular on the internet without a horde of React zealots turning up and banging on about it.
Recommending React to somebody who's considering Angular is like recommending tyres to somebody who's shopping for a car.
React is eating Angulars lunch when you look at the amount of large enterprises that choose react over Angular.
Part of the problem with Angular that no one seems to care about is that Angular 2 was such a big change from Angular 1 it forced companies that depended on Angular 1 to do a complete re-write.
I was an Angular 1 dev and Angular 2 caused me to abandon Angular altogether.
Angular also adds more abstractions on top of JS which is unnecessary and can cause unexpected behavior when transpiled.
Angular is still a lot more prevalent than React in most of the world. A lot of the big companies using React also use Angular - it's not so simple.
Most companies are doing the responsible thing and holding off on worrying about migration until Angular 2 stabilizes more. Even if one wanted to do a complete rewrite due to poor Angular 1 app code, one can then evaluate all options from scratch and choose the best option for their app.
Every library adds abstractions on top of JS - React is no different with your complaint of unexpected behavior.
This reads as an overly emotional post without applying engineering - "this sounds too hard so I'll just run away to another solution" is the vibe I get.
My advice would be to compile your CoffeeScript to JS, then start from there. That's assuming that CoffeeScript still produces readable, idiomatic JavaScript...?
As of TypeScript 1.8(?) you can set an "allowJs: true" flag in tsconfig.json, which tells TypeScript to include JS files in your build.
Then you can just manually add type annotations and ES2015/2016 goodness to your code and change the suffix to '.ts' on a file-by-file approach.
I'm doing this at the moment with a fairly large AngularJS 1.5 project, using Webpack with awesome-typescript-loader as the build system, and it's working perfectly so far.
No, they don't plan to integrate Roslyn and they tend to get a bit cross when people ask. They've been working on their C# code intelligence engine for 10 years in ReSharper, and it does stuff way beyond what Roslyn provides at present. I love Roslyn, and I'm using it for code analysis stuff, but it's not a contender for R# yet.
Finally, a proper C# IDE on not-Windows. I've been working with ASP.NET 5 on Linux for the last year and Sublime, Atom, VSCode, etc. are all painful. Sublime is surely dead, and anything based on Electron kills my 2-core CPU and my battery. I was in the talk here at NDC London where they demo'd Rider, and I can confirm that it is very fast and he showed the Mac process view and it was barely hitting the CPU, even with a JVM and a Mono VM running. And when it's all running on .NET Core it should be even faster.
As I said in the comment you were commenting on, there is a JVM and a Mono VM. The IDE is running as two processes, one on the JVM (running the IntelliJ shell) and one on, currently, a Mono VM (running the ReSharper engine). They use IPC with a custom protocol to send UI events and ViewModel updates between the processes.
Frontend is in Java (and Kotlin), indeed, as it's a part of the IntelliJ platform. However, the backend that actually provides IDE features for C# is written in .NET. The backend is actually the same ReSharper logic that runs in Visual Studio but in headless mode.
Not a valid comparison. Torvalds still actively rules Linux in every sense. If he'd just created it then buggered off leaving it half-finished, then complained when other people tried to finish it, then yes, he'd be a prima-donna/prick.
* The KafkaREST proxy makes life a little easier * librdkafka makes life a lot easier, especially when you can just download a thin wrapper around it for your chosen language * I am no longer working at the place that chose Kafka 0.8 following no testing at all for their use case, and refused to back down through months of hell both writing code and trying to keep clusters available * The people at Confluent have done a lot of good work since then, both on Kafka itself and on various auxiliary tools/products.
So yeah, I would probably look at Kafka again today if I needed that kind of functionality. Screw ZooKeeper though.