Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go + Services = One Goliath Project

engineering.khanacademy.org

Post reply on HN
Print view View original

251–260 of 449 posts

Re: Go + Services = One Goliath Project

#251

Post by abraxas »

tbrock wrote: post #119
bootlooped wrote: post #115

The article mentions Go's superior compile time, when compared to Kotlin. I have done a lot more Java development than Kotlin, but my recollection is that both of them compiled fairly fast. Is Go really significantly faster to compile for similarly sized projects?

I’ve written some things in both languages and compiling go feels an order of magnitude faster.

It's mostly because most setups will use maven or gradle which do much more than just compile code. They will often pull down dependencies, check for bugs and style inconsistencies, run unit tests etc. If you run plain javac against a bunch of files it will compile just as fast as Go. In any case it will be in a blink of an eye.

Re: Go + Services = One Goliath Project

#252

Post by m0shen »

Thaxll wrote: post #191
m0shen wrote: post #78

Earlier quoted context omitted.

If you mean the java 8 bytecode version, that hasn't been true since April: https://blog.jetbrains.com/kotlin/2019/04/kotlin-1-3-30-rele...

But they don't benefit from new runtime features right ? Loom, GC ect ... are no go for Kotlin.

I don't see why it wouldn't benefit from the GC changes. AFAIK Loom has no scheduled release date.

They seem like they're committed to supporting new features, but you're probably right they will lag on some things.

Re: Go + Services = One Goliath Project

#253

Post by abraxas »

nradov wrote: post #209
thatswrong0 wrote: post #39

Ok this is going to sound ignorant, as my only experiences in backend services have been Go and Python. I don't like either. Is there something I'm missing? For simple CRUD apps, both are sufficient. But (in my limited experience), the moment I've wanted to create more complex business logic with stricter constraints, neither has been quite up to the task. Go doesn't make things easy. It asks you to repeat yourself.…

Java can do almost all of that now, and offers excellent runtime performance.

Yes but hipsters won't be seen dead using it. It's soo not cool. Our industry is much less rational than we think.

Re: Go + Services = One Goliath Project

#254

Post by amedvednikov »

genuine_smiles wrote: post #137
tybit wrote: post #128

As much as I personally don’t enjoy writing Go I really can’t fault them. I still find it interesting that for a relatively obvious feature set of fast compiles, fast startup and fast runtime there really isn’t anything mainstream out there to compete with Go. I really hope something like Kotlin, Swift, ReasonML or even AOT JVM/.NET brings something to the table soon. Or perhaps I’ll just have to wait for WASM to rea…

> 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

Re: Go + Services = One Goliath Project

#255

Post by fizx »

bootlooped wrote: post #115

The article mentions Go's superior compile time, when compared to Kotlin. I have done a lot more Java development than Kotlin, but my recollection is that both of them compiled fairly fast. Is Go really significantly faster to compile for similarly sized projects?

It's rare that I notice the compile time for either. Incremental compilers are great!

Re: Go + Services = One Goliath Project

#256

Post by sagichmal »

amedvednikov wrote: post #254
genuine_smiles wrote: post #137

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

Still snake oil.

Re: Go + Services = One Goliath Project

#257

Post by tapirl »

glofish wrote: post #49
CivBase wrote: post #29

Earlier quoted context omitted.

> migrating from python 2 to 3 is such a large task that migrating to any other language is a comparable effort I'm going to call BS on that one. If you're having issues with Python 2, then it might make more sense to switch to another language instead of upgrade to Python 3. But going from Python 2 to 3 is much easier than switching languages completely. Python is not a perfect language. There is no perfect language…

I agree - the statement that migrating from Python 2 to Python 3 is a comparable effort to migrating from Python 2 to Go feels grossly exaggerated.

AT least, it is more exciting for a developer to migrate from Python 2 to Go than to Python 3. :D

Re: Go + Services = One Goliath Project

#258

Post by RandyRanderson »

Why do they call them "micro services" and not distributed systems? Oh right, it's because distributed systems are obviously really hard to create correctly and no sane person would ever agree to pay for that.

Nice: re-branding. I can't wait for the, maybe "consolidated computing" manifesto (aka turning micro services back into monoliths).

Re: Go + Services = One Goliath Project

#259

Post by WoodTree »

antielectronite wrote: post #245
WoodTree wrote: post #238

Earlier quoted context omitted.

Most stuff is web stuff now. And I’m not talking about front end, we do a lot of back end work in TypeScript because node is lighter than the JVM which makes it a better choice for lambdas. I’d say it also has more sophisticated static typing than Java or C++, while also allowing dynamic typing in the few cases where it is convenient. Having the front and back end written in the same language also reduces impedance b…

Most stuff is not web now. There is software in everything everywhere not just web sites. Niche does not mean "stuff I don't personally use at my job", but that is the only definition under which Typecript is not niche and c++ is. C++ in 2019 had the 4th most job listings according to Indeed. Calling that a niche is absurd especially in comparison to Typescript.

The thing about C++ is that you need to recruit specifically for C++ programmers in a way that you don’t need to recruit for programmers in many other languages. The barrier of entry for C++ is high enough that you can’t just take your typical developer and ask them to write good C++, it’s a language which requires far more effort to become competent in.

There are also many places which just ask for Java/C++ experience for no apparent reason. Amazon is like this, all of their job listings mention C++ but only a very small percentage of the code base is in C++. There is at least 10 times as much Ruby code and it is part of systems that most engineers will have to work with, but no job application mentions that.

Re: Go + Services = One Goliath Project

#260

Post by dangoor »

tony wrote: post #240

You can start porting your live codebase to python 3 right now - no downtime at all. You can have a 2+3 compatible codebase live in a week or two, it'll get you about 98% the way there [1] My projects (e.g. https://tmuxp.git-pull.com , https://unihan-etl.git-pull.com ) are both python 2/3 compatible. I learned by reading through other projects like Sphinx, Flask, Werkzeug, and SQLAlchemy: - Flask: https://github.com/…

I appreciate all of the links and the fact that, for a lot of folks, this is the state of Python 2 to 3 migration today. What you're suggesting is, imho, the best path for most (and I appreciate you mentioning the pickle incompatibility because that is a thing which would trip people up when trying to make the move).

If we would have been able to have a 2&3 compatible codebase live in a week or two, we absolutely would have done that. Incompatible changes in some libraries we use, App Engine first gen to second gen changes (which are for the better, but still a big deal), the choice of storing some pickles permanently, plus a need to really verify unicode handling all over the place (especially in a 10 year old codebase), and other factors that aren't coming to mind at the moment mean that this is not a couple week thing for us.

Moving to Go is more work than moving to Python 3, but in our particular case it's not as much more work as people might expect.

Post reply on HN