SMFloris's comments

So 400 writes per second is not exactly what I would think about when thinking about a "Production" environment.

I do hope they adopt one solution or the other. Rust for me seems incomplete because of this.

Another issue I have with it is perfectly described in this article: https://theta.eu.org/2021/03/08/async-rust-2.html

Shout out to the great people in the KDE Community.

I was in high-school and being enamored with the open-source concept ("You mean I can modify anything I want about it?" - hah) I wanted to make my mark in a simple little way. I remember fondly when lurking around in IRC and somehow decided I would change the login screen. Got pointed to the KDE greeter channel and that is how it all started for me. I kept annoying them, did not know how to build, compile, nothing. Thanks to d_ed for answering my annoying questions, that is how it all started for me.

Recently experimented a bit with Rust and I found the reverse to be true. You cannot compose types in Rust. You compose behaviors not types. Very important distinction as I found out the hard way.

Take the following example I have found on the net: https://play.rust-lang.org/?version=stable&mode=debug&editio...

In that example, both the bicycle and the car have the property `speed`. Imagine you have multiple types now that need to have the `speed` property. You would need to copy-paste the same code for each new type in order for you to be type safe.

Apparently it is called *Monomorphization*: https://cglab.ca/~abeinges/blah/rust-reuse-and-recycle/#mono...

From the article:

* But if I want a single queue to be able to handle different tasks, then it's not clear how that could be done with monomorphization alone. That's why it's called "mono"morphization. It's all about taking abstract implementations and creating instances that do one thing. *

Which was exactly what I was experimenting with: A single queue worker that can handle different cases. Honestly, it made Rust almost not worth it for me. Sadly, I was too deep to turn back so I wound up doing the whole thing in Rust. I have tons of copy-paste code. It is ugly and it is bothering me.

Seems so much work for something already implemented with messaging brokers, though.

In my opinion, clients themselves shouldn't worry about if the server is ready or not, only handle if the server does not respond in x seconds and then simply crash or error out. It is the same you would to with any other external service call.

I think the biggest change to gRPC is to the way I thought. Dumb clients was always something that I chose because it was an order of magnitude simpler to reason about. gRPC comes in and changes this by making the clients smart and the servers smarter, which brings allot of complexity to the table.

Also, indeed the configurations are so obscure.

Thank you very much for these articles. Really top-notch work and provided me with some great insights!

Never tried with MsgPack, but I did try Protobuf. The reason I dislike Protobuf is that there is an extra code generation step I need to do. When using a compiled language, I guess you don't really mind the extra code generation step since you also get some safety from the compiler so you don't wind up miss-using the generated code. It is not the same when you are using an interpreted language that doesn't have really good strong typing. You will have to run a static code analyser and be very careful every time you do a change to the interface.

Since in my experiments I was calling a method in Php through RabbitMq from a Rust worker, so it just proved allot simpler to just use json. Also, I measured the time it took to:

1. Make a request to the Php API

2. Php sends the rpc message on the queue

3. Rust processes that message

4. Php catches the response from the worker

5. Php returns the response to the http client

It was <10ms running the cluster locally regardless if I used Protobuf or simply json.

Recently I started delving into gRPC vs RPC over RabbitMq using json as the mesage format. I saw that for small to medium sized messages, gRPC is actually slower. Of course, this was just a small scale experiment so I don't think nothing of it.

Does anyone have a sort of infrastructure/architecture guide at a bigger scale for gRPC?

My biggest questions range from: How do you actually load balance the servers? What happens if you have a sudden influx of requests but don't want to auto-scale? Do you still need a sort of queue-ing system in front of the gRPC server?

In my research I wasn't able to find some noteworthy articles about this and thus triggered my curiosity.

Where Conan doesn't really shine is crossplatform dependencies. For example, when a dependency requires to have been built with a specific toolchain. Thus, if your goal is write once and run everywhere you'll still have to build dependencies yourself.

Loved it! It gets crazy with the pawns, I was so surprised. The visuals of the game are so and so, but they are really cool nonetheless. Two thumbs up from me!

I didn't see it back when I was doing Qt, but writing a Qt app for every platform is hard. In theory you can have Qt apps on Android, iOs, Linux, etfc but in all fairness, it is just too much of a hassle. Big headache with toolchains, dependencies, it is just not worth it nowadays.

"Write once, run everywhere" was a nice motto for Qt and I even bought it for a while but yet again does not work in practice. Flutter, on the other hand, actually works. Sure it doesn't have all the bells and whistles of OS integrations, but it is getting there. I hate the language itself, but I can't deny that it works beautifully.

If you think about it, the Qt way of doing things was quite novel back in the days and had allot of promise, but I feel that the main thing that held it back was C++ (still no official package manager and no cool CLI tools in 2021!!). I am sad that I left Qt behind since it was an amazingly modern platform when I used it, but I am glad I don't do C++ anymore.

A while back we explored the use of Cassandra. We wanted to keep some event related data there and for it to be relatively fast read-wise in order for us to do all sorts of reporting based on it. So we wrote allot and wanted to read fast. Seemed like a perfect store for our timestamped events, especially since we wanted to not even use deletes and has in-build record deduplication via its primary key. Turns out, it is not that perfect.

Other than what the article described, I can also add:

1. It has a steep learning curve, but you do get to see the advantages while you learn it. But then, everything comes crumbling down.

2. The setup is a pain locally. Then it is a pain to set it up in prod and manage it. The tooling itself feels very unfinished and basic.

3. No querying outside primary index on AWS Keyspace if you want it managed. Also, any managed variants are EXPENSIVE. I mean, every database is fast if you only query by the primary index so why pay extra?

It is just not worth it. For example, we winded up using MongoDb and it turned out to be fast, scalable, had mature tooling and we can keep tons of event related metadata in it and it is easy to manage and doesn't cost a fortune.

Hah! Brings back old memories. I actually did something similar for an RPG I was trying to create from scratch using Qt3D (back in the day when it first came out and was getting stable, QT 5.8 maybe).

Had the whole isometric world down and used qml to script monsters and abilities.

Great and fun experience, thanks for sharing!

I think software takes longer to build now than it did before even with all our software advancements. Abstracting the market requirements completely, the new technologies are very slow to create an mvp out of.

For example, a week ago I started a Symfony (php framework) project and let it on default server side rendered setup. I bought a $20 css+html template. I created some entities and then just inserted a form for that entity into an html file using one line of code. It took me less than 1h to do this, with containerization and db setup and figuring out how things work in Symfony.

It blew my mind. I totally forgot how easy it was and I could focus on the things that mattered. To do the same thing in React/Angular would have taken me much longer since I simply had to build 2 things (a frontend and a backend). I think this is why today software takes longer to build: You simply have to build more behind the scenes so that the end customer sees a form/page/button.

Oh wow! That is great news! Great job, will dig out my leap motion once I get back and try it out!

I actually reverse engineered most of the code for the drivers for LeapMotion for my undergraduate project. Turns out it was illegal as per their TOS so my professor had me quit that project and take it offline.

The biggest problem I had encountered back then is that there was a packet transmitted with a certain signature in order to turn on the cameras that I could not reverse for the life of me (had something to do with the app version).

Other than that: basically two IR cameras that stream in an interleaved pixel format (2 x 640) x 480 iirc. It was a fun device to use and hack, but the first time I had ran into the brick-wall that is an enclosed format.

You can come up with a better reply of course. But can you really beat the "are we aligned in the same direction" from the CEO and the other executives? Especially on the 2nd day.

You can spin it however you want, come up with some great arguments, but if the CEO decided to fire people, I don't think he takes that decision lightly so when he/she presents that decision you can count that it really is the last option he has.

It all comes down to trust. Trust your CEO that he has no other choice, maybe explore alternatives. But if he is a really good CEO, even if you fight it and argue for it, you'll wind up at the same conclusion he did. In fact, 9/10 you'll wind up at the same conclusion he did. Remember, it's his job to convince and lead people so he's probably better than you at that.

It is pretty interesting how this conversation goes.

CTO: I can't do that on my 2nd day.

CEO: I thought your interests align with the company. It is your job to align everyone under you to our direction.

CTO: Yes, of course. Right away.

In the beginning, you are on an island, you have an idea to go on an adventure, so you start building a raft with the other guy on the island. The other guy has no building skills, but he procures food, water and wood. The resources on that island are dwindling but you manage to finish the raft just in time.

You begin to sail the raft, you start fishing while out in the open seas. You reach another island and sell the fish, figure out that is the way you can have an easy life since you can pay other people to procure food, water and wood with fish. You build a better boat, hire more people and repeat the process.

You now have a huge rowing boat that goes very far out at sea since there are no fish left close to land, you now fully depend on the people on that boat to make it alive to the next island. There are people who row, people who fish, people to cook, people that are on the lookout for fishing spots and islands.

Your partner notices a guy who eats more than the average rower on the boat, but rows less. You throw him overboard. A fire starts near the rowers, but the rowers continue rowing. Turns out the guy you just threw overboard he always put out fires. You find another rower, tell him to put out the fire. He throws water over it. It is now worse. You figure out the fire is the cook's fault for using too much oil. He only used so much oil because the lookouts thought fish oil is good for their eyes so they can see more ahead. You know this to be only partially true, but they don't seem to understand and even though the fire happened they still demand their food fried in fish oil.

You throw one of the lookouts in the water to make an example. The lookouts stop eating deep fried food. Now the people who fish complain they work too much. Turns out the deep fried food gave the lookouts energy to shout at the people who fish where to fish at. Now, the people who fish need to stop what they're doing and go to the lookouts for information. Because of all the extra effort the people are doing, you are now out of fresh water in the boat.

Congratulations, you now know how a CTO feels like.

CTO of a small-ish startup here. Here is my take on it:

1) Code doesn't really matter as long as it solves the issue you are trying to solve. Don't expect your code to be beautiful from day 1. Be responsible and train your devs to be responsible as well, because in a startup you code, fix and deploy your own stuff. What does matter, though, is code complexity. Manage your complexity, don't overcomplicate things if you don't need to. No need to design a Ferrari when all you need is a horse and carriage.

2) Process matters. From day 1, make code reviews/pull requests the default. If you are the most senior dev, or a technical founder/CTO in a small startup be prepared to spend about 50% of your time reviewing code and helping others. You won't get to code as much, but you'll sleep better at night knowing at least you've tried to catch some bugs before they reach production. In an early stage startup, you will not have the time nor the resources to test everything, but this will give you peace of mind.

3) Tests matter. That being said, in the beginning only test mission critical stuff. If you find a critical bug, fix it and then write a test for it. If a new feature breaks something that already works it is a big no-no and might lose you customers. Testing will change for you as you progress with your startup. Start by making the process easy for the devs to run the tests locally. Then, progress in having CI. Then, maybe have CD as well.

4) Worst case scenario: full rewrite. If a 6 to 12 months old startup decides on a full rewrite. I'll give them the benefit of the doubt, maybe their whole use-case has changed, maybe they DO need a rewrite. That's fine. But, if you are a SaaS that is older than that and your dev team is around 10 devs and they are all busy solving critical bugs and putting out fires, a rewrite might mean your death.

5) Architecture matters. This matters more than code, in my opinion. Say you have a horrible piece of mission critical code, it is SLOW and begins affecting your business. That piece of code will need a rewrite, for sure. But what would you rather do: spend 30 days to fix it and lose customers, or just spin up another machine/add CPU/add RAM? This is a good architecture, it allows you to have time to think things through, allows your code to run well and perhaps most importantly, allows your developers to actually code.

Bad architecture is the leading cause for rewrites. Is that beautiful microservice architecture giving your small team headaches? Did you overcomplicate things, perhaps? You see, bad architecture is very hard to fix. People seem to underestimate how much a simple API + DB can scale and try to mitigate the risks by copying whatever FAANG does. Start small, scale later once you have the resources to do so.

TL/DR: Code quality doesn't matter if you solve your issue. What matters more is mitigating the risks that come with writing code in general. See above for some ideas that came from my own personal experience.