maxpert

Can't wait for 1.0, shameless plug https://gitlab.com/maxpert/crlocator is one of the project's I've been running on prod for over year now.

Congrats and Thanks Nim team. I’ve been tinkering with Nim to build a really efficient pubsub server. Something that can take heavy concurrent connections. Now I can actually build with confidence.

Fortunately I've used Go, Kotlin and C# in production building systems dealing millions of rpm. I can correlate my experience with different parts author has described. But I would disagree with few parts, specially simplicity part. You see the so called "simplicity" comes at a cost of extra verbosity and pain e.g. no generics; I have to add 3 extra lines of code, and repeatedly do casting and `ok` checks to just get value out of an in-memory LRU cache. Now some of folks might argue well this is the right way to do it. IMHO generics is one example of compiler slacking on me, and putting the burden on developer to maintain those extra lines of code. I do agree with C#'s breakable TPL model where you can choke threads; and I think that problem exists due to Tasks being slapped on to legacy down the road. If they were to reinvent another language I bet no-body with sane ideas will ignore the async programming model. Kotlin is one such example.

I can keep going on and on, but to cut it short; yes I would write a high performance router, reverse proxy, or a very simple micro-service in Go. But I would never recommend anyone to write a high business complexity service in Go. It's a matter of time before somebody writes a transpiler that would take these short comings of Go, and fixes them (Like Kotlin, Nim etc.).

What happened to first one?

Have been personally using it and I believe it’s a better alternative to ngrok.

You are facing same problems that I’ve experienced and I developed different techniques to get around these network latencies. In our case most of the payloads were large fragments of compiled JSON. So we benchmarked and found LZ4 to be lightweight compression cutting down on network payload and cache size at same time. Shameless plug https://youtu.be/QkUz2_kRV9g I discussed them at RedisConf.

Loved it then love it now. The fact that it was most loved library on Stackoverflow should say something about the relentless simplicity of jQuery.

Makes me wonder if it gives any additional performance benefits with AOT compile and TPL

Have used C# before for almost 5 years. Develeoped for backend and frontend both! Love the language, love TPL. Kotlin in my opinion brings a better coroutine implementation. I love they way I can intercept contexts and arrange them, letting me have go-ish selects, and the structured concurrency. I think Kotlin might take it a level higer.

Same question I always ask, who is using it in prod? How huge the database size is? I’ve used postgresql with almost 200+ GB size of single table and it works like breeze! What are caveats, traps I should be aware of?

Web has come a full circle. First we disgust and hate SOAP XML and friends. Then we go to REST and realize of it's too loose! Then we invent stuff like Swagger and JSONAPI in order to put some interfacing in place. And then we bring in cripples that give similar but water downed features of SOAP, GRPC, GraphQL and more friends.

Edit: I know I might get downvotes but think for a second we could have just taken some good parts from SOAP to begin with and have all the goodness.

We are using Kotlin with SpringBoot + Hibernate + Redisson. Have no complaints whatsoever on stack, the only drawback I am experiencing is backend people have never seen/used Kotlin before so the initial friction and dogma of it's too complicated. Our Android apps do use Kotlin but there is nothing common from codebase being shared what so ever. I would still choose Kotlin but probably different framework stack not because I didn't like SpringBoot but due to projects like Ktor getting mature.

I’ve used lz4 several times for compressing blobs and storing them for serving real-time traffic. In my opinion LZ4 and Snappy hits fine balance of CPU usage and network usage when you are sensitive to p99 latencies. ZSTD seems to pay more attention to compression size. I hope to do a real life test instead of sythetic benchmarks. Has someone already used it in prod?

People looking for an already working version here is the demo URL http://geo.sibte.ml

Have personally made contributions to the project once or twice. I think its a fairly young project so far being used part of bigger graph database. I went back to BoltDB for it’s stability and decent performance. I think everybody has his own scale for measuring fast vs stable. It was fast but not stable enough for my scale.

Gob's program!

Agree here with the comment nothing compares to the solid codebase of SQLite. This project in my opinion trys to win your trust with QLite in name and does not deliver same quality.

One thing I hate about GRPC with Kotlin is the crap of get set that it generates for Request/Response payloads. I've always wanted to used basic POJO objects and this might solve my problem. Although I've seen some unmaintained Kotlin generators for GRPC there is no battle tested solution and this post just might solve my problem. Jackson is performant enough for me.

Aaaah reminds me of my student age when I made a weather widget. It was back in 2009 and yeah being student I tried to monetize it. Needless to day I failed despite getting almost million hits in a day. The only thing I was loosing was pocket money and sanity from emails people will send for support.

Mind blown

I still don't get it; so you invented a language based on idea of not doing the "evil" things C++ or say other languages did and now you have to re-invent all those "evil" things because community wants it?

Spot on! I've seen org wide mono repos at Microsoft and they had their custom tooling and build systems built on top of SourceDepot.

Amazing I am planning to shift RaspChat on this. Would be nice if same engineering effort can be put into WebSocket. This will make it much more desirable everywhere to build pub/sub systems.

I’ve been following this case from the beginning. I think in a country like Pakistan it’s a huge accomplishment! Pakistan is known for its corrupt leaders because they control the system inside out this is probably the first time law is being upheld and people are backing it.

Taking a look at this article https://opensource.com/article/17/8/what-about-cobol for example.

I can vouch for the DNN results. I took data from Kaggle and tried training networks with different approaches. Was not able to get prediction any better than 54% (which I am pretty sure would be biased as well). Later on while inspecting data and looking at dips and rises turns out external events (govts banning crypto or a price crash due to other reasons) was causing price drops or surge, my conclusion was if you need to predict anything you need to be aware of these external factors.

Benchmarks please?

Have you considered opening up the source code for Sciter? You can easily get a significant amount of apps just due to the size and still maintain "paid and supported" version.

Anything that takes them away from curse of Yahoo! is a blessing for the users and Flickr.

So you knew that breach happened in 2015, they might have already handed off data to someone else, and you didn't bother telling people? Quoting:

"In 2015, we learned from journalists at The Guardian that Kogan had shared data from his app with Cambridge Analytica. It is against our policies for developers to share data without people's consent, so we immediately banned Kogan's app from our platform, and demanded that Kogan and Cambridge Analytica formally certify that they had deleted all improperly acquired data. They provided these certifications."

What does banning or disabling app means? If you were responsible enough and you cared about user data you should have made it public right there and then! This is no excuse!