Some people have “moved on” to distributed monoliths
FTFY
90% of these so called microservices share a database and make api calls to each other.
South Africa’s biggest forum. Discuss, discover, and connect with thousands of members.
Some people have “moved on” to distributed monoliths
In this context OP was eluding to a large code base. If you have large code base in your micro services you doing it wrong.FTFY
90% of these so called microservices share a database and make api calls to each other.
That is all I've been doing for the last 10 years professionally.The world has moved on to micro services..
I would have fought you to the death but I am all in for golang now days. Performant, compiled and doesn’t rely on the bloated crusty frameworks like dotnet.That is all I've been doing for the last 10 years professionally.
Building "micro" services that communicate with each other over APIs.
Still wouldn't build it in Python.
My personal favorite is when people put typing hints or something like that in Python.
They basically put a type system on Python.
All the drawbacks of static typing without all its guarantees
Python is great for a lot of things, but building services for production backend systems is not one of them.
Sure there are people that swear by it so hard they do build them and some may even be stable.
But maintenance by multiple people on a dynamically typed language service is an absolute nightmare.
And if you are introducing typing into Python you may as well drop it completely, you're using it wrong.
I don't really care which language you use.I would have fought you to the death but I am all in for golang now days. Performant, compiled and doesn’t rely on the bloated crusty frameworks like dotnet.
/shots fired!
Tldr dynamic type languages suckI don't really care which language you use.
But I have strong opinions about the right language for the right job.
I've used both Ruby and Python professionally for very large services (not bloated as you suggest)
I use Kotlin, Java & Scala for very large services.
I use C/C++ very regularly for hobby use
Between those the dynamic language services were all eventually replaced by the non-dynamic variant simply because the maintenance got to the point that deploying new version became scary.
My company is absolutely enormous (we have literally thousands of developers just in my division), so these changes happened across different teams and services.
It wasn't somehow my influence.
I can go into a lot of reasons why that is but they aren't unique or due to "bad environment"
With dynamically typed languages you pretty much need 100% unit testing of every branch because a single typo can bring down your entire service at runtime.
And this always ends up happening. Someone put a branch somewhere, the variable name or getter for a property changed on the object somewhere else and suddenly that branch breaks everything.
Anyway I'm on a rant here, there are so many cases I can list here that I've observed and they just aren't worth it.
For hobby use, for testing new concepts, for research purposes, etc. Python is great.
For a constantly revolving software team running a critical service, good luck!
And above is generally true for dynamically typed languages, you set yourself up for pain.
I'm using Python as an example because it is being touted as a panacea.
But these examples are really true for Ruby/Javascript/PHP too.
Statically typed languages really solve a LOT of these cases for you.
There is no best language obviously, but there is definitely a wrong language (or at least wrong paradigm, which I think dynamically typed is for serious systems).
If you run a single developer system, go for it. But this is just not true for any serious software company. People come and go and I want that static typing at compile time to help me to help them.
At my work everything is Javascript (Nodejs).
We've looked into migrating to Typescript, but there's a big trade off between spending many months rewriting (± 200k lines of code) vs shipping more features for customers.
Right now moment we're rewriting a core frontend component into React + TS as a prototype (arguably the hardest part of the App), which is fun but there's a lot of trial and error involved.
I still use Python + Django for most hobby projects.
Rust is even worse...I am really liking Python.
Especially for knocking out quick code - Jupyter is great for setting up example stuff.
I use a mix of things in my day, currently doing a lot of C++, which is downright horrible in a lot of respects.
I need to start playing with Rust at some point.
He’s giving pros and cons of the languages he’s used in no particular order. He specifically says that he does not dream in Python and that C flavored C++ is his choice for serious work.
As an aside, while I have a ton of respect for Carmack, there are many, many people at his level and beyond, however, they just didn’t write a popular game.
Oh my...I'm writing C flavoured C# code (in Unity that is).
Yeap, most new client side features are being written in TS, which is an incremental start.Why migrate the entire code base? Why not just incrementally add typescript?
Don't worry, in a year you will move all the micro-services back into a monolith.The world has moved on to micro services..
just like python...Django is an abomination.
Those things still have to run somewhere and Python is still definitively slower.The world has moved on to micro services..
Rust's syntax may actually be even worse than C++, but it does have a compiler which checks a lot failure possibilities at compile time. I don't know if C++ compilers are moving that way, but if not then it's a good reason to consider Rust instead.I use a mix of things in my day, currently doing a lot of C++, which is downright horrible in a lot of respects.
I need to start playing with Rust at some point.
Rust syntax is dogshitThose things still have to run somewhere and Python is still definitively slower.
Rust's syntax may actually be even worse than C++, but it does have a compiler which checks a lot failure possibilities at compile time. I don't know if C++ compilers are moving that way, but if not then it's a good reason to consider Rust instead.