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

Less is exponentially more (2012)

commandcenter.blogspot.com

Post reply on HN
Print view View original

91–100 of 102 posts

Re: Less is exponentially more (2012)

#91

Post by apta »

wahern wrote: post #86
apta wrote: post #83

Earlier quoted context omitted.

The irony is that golang was created to replace C++ at Google, yet it didn't even make a dent in its usage for serious products. C++ and Java remain the heavy lifters there, as well as at other major establishments, precisely because of reasons like performance and (on the JVM) monitoring. golang ended up being more of a Python replacement.

Go was never intended to replace C++. It was aimed at a very specific target: engineers, especially junior engineers, writing function-as-a-service software. Thread-based concurrency (as in logical thread of execution, not "kernel threads") with message-based synchronization, structural typing, and static compilation were their answers to what in their experience were the biggest impediments to writing good network s…

> Go was never intended to replace C++

As per the creators of the language who claimed that they got the idea of writing a new language while waiting for C++ to compile, it was. You can read up about this from them, they were quite clear about it. They even expressed surprise as to why they didn't get the migration of C++ programmers they were anticipating to golang, but instead got Python programmers.

It's not like the lack of green threads stopped people from writing highly concurrent code. Libraries like Vertx, Reactivex, and Akka have existed for a while now. Also, all major platforms have a notion of green threads/coroutines (Java is getting the former and C++ is getting the latter). This was practically the only thing golang had going for it, and once they're implemented for those platforms, it's hard to make a case for golang given it's bad design decisions.

> Hassles with dealing with timeouts exposed flaws in their scheduling and message passing abstractions.

That's a good point, which is why Java's green thread implementation is superior to golang's. Timeouts and cancellations are designed in from the start, as well as hierarchies of green threads (similar to Erlang's).

Again, it just show's that golang does the minimum, and pushes complexity onto the user under the guise of simple language design.

> licensing, tooling, interop, etc, was an extremely poor fit for Linux, and in many ways still is.

The JVM is open source and has been for a while now. Could you elaborate on why it's not a good fit for Linux?

Re: Less is exponentially more (2012)

#92

Post by hactually »

apta wrote: post #90
hactually wrote: post #85

Earlier quoted context omitted.

Got an example repo you've worked on as happy to help work with the ecosystem rather than against it?

It's a non-public code base.

So a single project, that you designed and built is causing you problems?

I don't think Go is the problem

Re: Less is exponentially more (2012)

#93

Post by hactually »

apta wrote: post #91
wahern wrote: post #86

Earlier quoted context omitted.

Go was never intended to replace C++. It was aimed at a very specific target: engineers, especially junior engineers, writing function-as-a-service software. Thread-based concurrency (as in logical thread of execution, not "kernel threads") with message-based synchronization, structural typing, and static compilation were their answers to what in their experience were the biggest impediments to writing good network s…

> Go was never intended to replace C++ As per the creators of the language who claimed that they got the idea of writing a new language while waiting for C++ to compile, it was. You can read up about this from them, they were quite clear about it. They even expressed surprise as to why they didn't get the migration of C++ programmers they were anticipating to golang, but instead got Python programmers. It's not like…

> That's a good point, which is why Java's green thread implementation is superior to golang's.

So the future invention of something that doesnt currently exist is going to be better than something that does exist is your argument?

Re: Less is exponentially more (2012)

#94

Post by hactually »

apta wrote: post #89
hactually wrote: post #84

Earlier quoted context omitted.

I'm not sure I understand the irony but keen to know what monitoring you are talking about?

* https://openjdk.java.net/jeps/328 * https://www.baeldung.com/java-flight-recorder-monitoring * https://docs.oracle.com/javase/tutorial/jmx/overview/javavm....

Those are all focused on the JVM, not Java tho? Go doesn't have as many issues as the JVM on performance nobs to twiddle (a good thing)

If we're comparing language exposed we've got pprof which can profile and generate flamegraphs etc all part of it as standard that blows your argument away IMO [0]

[0] https://golang.org/doc/diagnostics.html

Re: Less is exponentially more (2012)

#95

Post by DLA »

pjmlp wrote: post #88
DLA wrote: post #78

Earlier quoted context omitted.

> -- Operational complexity vs. Go. The JVM is superior for operations, observability, and monitoring to anything that golang has to offer. >> Disagree on operations part. Take a bare machine and with various configurations (some you don't control) and be ready to drop and run. Nothing beats Go. You cannot be simpler than copy a binary. Yes, the JVM has all sorts of observability. And also a load of tuning that often…

Because of cargo cult of "must be web scale" and people that want to pump up their CVs to work at a FAANG. All those projects are related to Docker and k8s, so naturally get written in Go. Thankfully it is also possible to use Rust, C++, Java and .NET with them without writing a single line of Go.

You could write any program in any non-toy language, of course. This does not make every language a good choice for a given problem.

Here’s some pretty detailed notes from Google about one high volume project they rewrote from C++ to Go.

https://talks.golang.org/2013/oscon-dl.slide#1

Use whatever language you like. Just because you like X and someone else likes Y does not invalidate either language.

And to you totally off base comment about cargo cult of web scale and ‘pump up their CVs’ .... in my case I happen to work with huge data (petabytes) so yeah it matters and has nothing to do with FAANG. In this context I have found Go to be an insanely great tool—-productive, reliable, maintainable, multi-core, networked and fast. Thankfully I will never have to write a line on .NET.

Re: Less is exponentially more (2012)

#96

Post by pjmlp »

DLA wrote: post #95
pjmlp wrote: post #88

Earlier quoted context omitted.

Because of cargo cult of "must be web scale" and people that want to pump up their CVs to work at a FAANG. All those projects are related to Docker and k8s, so naturally get written in Go. Thankfully it is also possible to use Rust, C++, Java and .NET with them without writing a single line of Go.

You could write any program in any non-toy language, of course. This does not make every language a good choice for a given problem. Here’s some pretty detailed notes from Google about one high volume project they rewrote from C++ to Go. https://talks.golang.org/2013/oscon-dl.slide#1 Use whatever language you like. Just because you like X and someone else likes Y does not invalidate either language. And to you totall…

Ah the rewrite that was driven by the Go team itself as a means to prove a point.

Apparently the Android team did not adopt gomobile the same way.

Re: Less is exponentially more (2012)

#97

Post by DLA »

pjmlp wrote: post #96
DLA wrote: post #95

Earlier quoted context omitted.

You could write any program in any non-toy language, of course. This does not make every language a good choice for a given problem. Here’s some pretty detailed notes from Google about one high volume project they rewrote from C++ to Go. https://talks.golang.org/2013/oscon-dl.slide#1 Use whatever language you like. Just because you like X and someone else likes Y does not invalidate either language. And to you totall…

Ah the rewrite that was driven by the Go team itself as a means to prove a point. Apparently the Android team did not adopt gomobile the same way.

Yes and they are very clear about that. What matters is the end result. Shorter, simpler, higher perf code that solved a practical problem, at scale. There's no secret that Brad is a heavy for the Go team. The point is about one way to pragmatically solve a problem and ship code. That's all.

Re: Less is exponentially more (2012)

#98

Post by pydry »

throwaway894345 wrote: post #51
pydry wrote: post #39

Earlier quoted context omitted.

>I'm not willing to script my own build system in an imperative DSL or deal with dependency hell a la Java, Python, C/C++, etc. Ironically, the fact go tried to make me use GitHub as a stopgap package manager (& denied one was necessary) while they built their own was what made me run away screaming. They've since fixed that but seeing them fail at what Perl managed in 1995 and what became standard is larger language…

People scoff about "GitHub as a package manager", but it hasn't chafed me much. Moreover, the scoffing isn't very substantial--it's often some variation of "but GitHub goes down all the time?! You will never be able to build/distribute your software!", which is trivially refuted (the GitHub UI goes down all the time, but its git service going down is much rarer; you can use a caching proxy if you're really concerned…

>it's often some variation of "but GitHub goes down all the time?!

It was never about github's downtime. It was about having to manage the code of your dependencies yourself.

>you can use a caching proxy if you're really concerned about reliability

yay one more piece of infrastructure that will break.

>There are probably lots of good reasons for why the GitHub model is inadequate, but for whatever reason these aren't brought up in the aforementioned scoffing

I really think they were.

Re: Less is exponentially more (2012)

#99

Post by apta »

hactually wrote: post #94
apta wrote: post #89

Earlier quoted context omitted.

* https://openjdk.java.net/jeps/328 * https://www.baeldung.com/java-flight-recorder-monitoring * https://docs.oracle.com/javase/tutorial/jmx/overview/javavm....

Those are all focused on the JVM, not Java tho? Go doesn't have as many issues as the JVM on performance nobs to twiddle (a good thing) If we're comparing language exposed we've got pprof which can profile and generate flamegraphs etc all part of it as standard that blows your argument away IMO [0] [0] https://golang.org/doc/diagnostics.html

The JVM yes, and Java is the platform language, so it is the most efficient language for the JVM, and the one with least impedance mismatch.

golang is not a magical solution that doesn't have problems. It has its fair share. Its gc is subpar for throughput purposes for instance.

pprof is different. JFR provides live streaming events with minimal overhead. Regardless of what language you use, this feature is invaluable. It's not just for performance, but for debugging, monitoring, and tracing.

Re: Less is exponentially more (2012)

#100

Post by apta »

hactually wrote: post #92
apta wrote: post #90

Earlier quoted context omitted.

It's a non-public code base.

So a single project, that you designed and built is causing you problems? I don't think Go is the problem

It's a huge code base, with literally thousands of sub-projects, with non-overlapping teams working on them. When I see the same issues arise, the only common thing is the language.
Post reply on HN