Earlier quoted context omitted.
Java killed it for general purpose use in the 90s. It’s never your first option unless you are in areas like games, graphics, some embedded work, or quantitative trading.
"All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a fresh water system, and public health, what have the Romans ever done for us?"
Go + Services = One Goliath Project
271–280 of 449 posts
Re: Go + Services = One Goliath Project
#272Re: Go + Services = One Goliath Project
#273We 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…
I moved back to monolith and am very happy. I think of the monolith now as a collection of modules. The rule is now, one should be able to drag any of the modules to the top-level of our monorepo and create a new microservice pretty easily when the time comes. I think the microservices book (that came from that Uber engineer...?) suggests a rule of 5 engineers per service.
Re: Go + Services = One Goliath Project
#274The 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…
Numerous large projects and companies have publicly stated that they are stuck on Python 2 and it's easier to migrate languages, even to ones that they have to invent (Go) than to migrate to python 3. At least one of these companies had Guido on their staffs for years. Another, also with Guido on the staff, needed over three years to migrate from 2 to 3. The overwhelming body of evidence shows that migrating a large…
Re: Go + Services = One Goliath Project
#275Earlier quoted context omitted.
Never announce a plan to do something. Announce the results after doing it. If you announce a plan, you're making a bet (sometimes with your reputation) that's it's going to be successful, and telling the world about it. If however, you didn't announce it, you could still get the benefit of success, or make it looks like learning the lessons of a failed experiment.
We have the good fortune of not having to be super secretive about our tech. We _want_ to talk about this project as we go along and share what we learn. We've already got more interesting stuff to talk about, and it'd be a lot less interesting, I think, without this context for the overall project. As mentioned in the post, a small piece of our GraphQL schema is already in Go running in production. This blog post is…
Re: Go + Services = One Goliath Project
#276Earlier quoted context omitted.
I don't really understand moving to microservices if you aren't going to give the service teams the autonomy to make their own decisions and move at their own pace. Microservices always seemed to me to be more of an organizational strategy than a technical one - if you have services, but they can't operate independently, it feels a bit like you are just creating a distributed monolith.
We're making a certain set of tradeoffs. For example, we're not adopting the "write code in whatever language you want" form of microservices that some folks adopt, because we don't feel like we're large enough to support that. Like I said, though, we do want to minimize the library footprint. The vast majority of deploys in this new world will be single service deploys, with the benefits that come with that. We alre…
Re: Go + Services = One Goliath Project
#277Re: Go + Services = One Goliath Project
#278Earlier quoted context omitted.
This doesn't follow: for loops are there specifically for cases of the complexity that can't be handled by other constructs (like comprehensions). Anonymous functions are not, for the complex cases you give the construct a name. It's a very intentional language limitation, much as semantic whitespace is an intentional limitation. And there is actually a language difference. A for loop is a statement. A lambda is an e…
I tentatively disagree with both of you. I've sometimes wondered whether code would be universally clearer if all you could do in a loop is have a one-liner or call another function/method (mainly when looking at my own code within loops and thinking WTF!!!). Would probably cause issues when teaching programming though. It would be interesting to have a compiler switch that enforced this...
Re: Go + Services = One Goliath Project
#279Earlier quoted context omitted.
Switching to python3 is hard, especially if you have a massive python codebase interacting with other systems. Its not as easy as importing unicode_literals. Unicode breaks in very subtle ways.
and rewriting it in another language will magically fix this and not introduce new bugs? besides, in my experience Python 3's clear separation between bytes and str makes these breakages much less subtle than it silently going wrong in Python 2. i wish them all the best, but would've been much more impressed if they'd done it, not simply announced to do it.