11–20 of 449 posts
I was under the impression that Go was more performant than Kotlin. TMYK :)
Go was written for servers, Kotlin for mobile apps. Seems an obvious choice really.
Not really. Kotlin was just a better JVM language developed by the JetBrains folks before Google adopted it as a first class Android language, but I don't believe it was specifically developed for mobile initially.
I was under the impression that Go was more performant than Kotlin. TMYK :)
Go was written for servers, Kotlin for mobile apps. Seems an obvious choice really.
I was under the impression that Go was more performant than Kotlin. TMYK :)
- The decision seems to be primarily a software architecture one, without much mention of all the other architects whose input will shape how the finished product is run and supported. In a modern software development environment, all the other parts of the org should be consulted on greenfield work to "Shift Left" anything that may need to change down the pike. Design in a silo leads to ineffective products.
- They're going from "hmm we need to upgrade from Python 2 to Python 3", to "we need to redesign everything in a new language with a radically different software architecture". This is definitely the second system effect. It's going to take years to make this thing reliable and sunset the old product.
- They're porting over the logic? Even if this is actually the right move, wouldn't a clean-room implementation potentially give better outcomes?
- Why are they continuing to use App Engine if the writing's on the wall for 2024?
I was under the impression that Go was more performant than Kotlin. TMYK :)
Go was written for servers, Kotlin for mobile apps. Seems an obvious choice really.
I disagree with this. It's a Python project's dependencies that make it hard to move from 2 to 3, and most libraries have been updated.
Of course, you could argue that it isn't easy to migrate a codebase from one major version of a language (or framework, or database) to another, but when you eliminate easy from your vocabulary it becomes harder to describe different levels of difficulty.
We turned our monolith into a bunch of micro services almost 6 years ago to the day. For a long time I was very happy with the new pattern but over the years the weight of keeping everything updated along with the inevitable corners that fall behind and have...questionable..security due to how long they sit neglected has really left me wondering if I am happy with it after all. I would love hear some thoughts from ot…
The article says this: "Moving from Python 2 to 3 is not an easy task." I disagree with this. It's a Python project's dependencies that make it hard to move from 2 to 3, and most libraries have been updated. Of course, you could argue that it isn't easy to migrate a codebase from one major version of a language (or framework, or database) to another, but when you eliminate easy from your vocabulary it becomes harder…
source: no python services at my company are going to be migrated to python 3; it’s all moving to a JVM