Live data from Hacker News

Go + Services = One Goliath Project

engineering.khanacademy.org

271–280 of 449 posts

Re: Go + Services = One Goliath Project

#271
post #250

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?"

The Romans or the Chinese?

Re: Go + Services = One Goliath Project

#272
It is crazy to see they are still using python 2. Seeing how slow the conversions to python 3 have been, was creating python 3 a good decision for python community? Can it be argued that developing python 2 further in a backward compatible way would have been better for the community? I know that evaluating this kind of thing is hard as metrics are bound to be subjective and speculative. But I am curious if there was any serious attempt to figure it out.

Re: Go + Services = One Goliath Project

#273

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…

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.

How are you preventing transaction couplings? For example, module A and B are called by C. C starts a transaction that wraps A and B. If you move B up as a network feature, you lose the transactionalty.

Re: Go + Services = One Goliath Project

#274
post #26

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…

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…

Which companies are those? Because neither Google nor Dropbox have claimed the things you're implying they did.

Re: Go + Services = One Goliath Project

#275
post #223

Earlier 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…

Just because you can do something doesn't mean you should have done it. And sometimes that's only found out in hindsight.

Re: Go + Services = One Goliath Project

#276

Earlier 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…

Didnt you guys recently decide to write some services in kotlin? Are you rewriting those in go now since everything is going to be one language?

Re: Go + Services = One Goliath Project

#277

Earlier quoted context omitted.

> fast compiles, fast startup and fast runtime All I can think of is D, but it’s not quite mainstream. Are there any other less popular languages that meet all 3 conditions?

https://vlang.io

LoL

Re: Go + Services = One Goliath Project

#278

Earlier 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...

What comes to mind immediately is that you would lose the ability to `break` unless you had another convention like returning a specific value to indicate you want to break.

Re: Go + Services = One Goliath Project

#279
post #99

Earlier 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.

The question isn't, is porting Py2 to Py3 easier than porting Py2 to Go. The question is, if you spend the same effort on porting Py2 to Go that you would have spent porting to Py3, and that only gets you 60% of the way there, but the ROI on that work is much higher, are you better off?
Post reply on HN