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

Why I Don't Want to Learn Go

arantaday.com

Post reply on HN
Print view View original

121–130 of 139 posts

Re: Why I Don't Want to Learn Go

#121

Post by Scaevolus »

batista wrote: post #22

For all the talk of the speed benefits of Go, and it being static et all, I don't see much improvement over, say, Python. A lot of the questions re speed bumps on the mailing list are answered with "those are microbenchmarks, what matters is real cases" and generally a "lalala hands in the ears approach", even when it's obvious that the problem is deeper than some microbenchmark only case. Like this example: https://…

The conclusion of that thread was that his Python benchmark was accessing the hashmap's entries in sequential order (due to python's hash function being intentionally non-random), while the Go benchmark was accessing keys at random (since its hash function is random) and trashing the cache.

Re: Why I Don't Want to Learn Go

#122

Post by pjmlp »

webjprgm wrote: post #104

Why can't someone make a language where you can optionally use GC on one chunk of memory and use automated reference counting on another chunk? Tell the compiler which variables should be in which category, and then most of the quick programming is done in GC while all the stuff that needs to be performant will be in reference counting but automatically managed so you shouldn't have to know outside of the one keyword…

Modula-3, Ada, Oberon are just a few of such languages.

Re: Why I Don't Want to Learn Go

#123

Post by andolanra »

msutherl wrote: post #120
heretohelp wrote: post #4

I concur with the concurrer and the author with my own more 'positive' addendum: I just want a cleaned/tarted up C. Something that doesn't make the critical mistakes of Go and Obj-C (adding runtime overhead), but adds optional compile and runtime semantics that can be very helpful and powerful. Some ideas: No GC. This is NOT negotiable. I'm tired of belabouring that point. Give me something nicer than the current C b…

I'm curious if anybody has written something equivalent to CoffeeScript for C...

Something that provides syntactic sugar that compiles down to C? You'd be looking for Vala[1]. I haven't used it so I can't vouch for it in practice, but I know it compiles to C and uses the GObject system for object-oriented programming. It's not as much of a syntax change for C, but it apparently adds quite a bit semantically. There's also a Scheme implementation called Chicken[2] that compiles to C source, and I know there are others that I'm not recalling off the top of my head.

[1]: https://en.wikipedia.org/wiki/Vala_%28programming_language%2... [2]: https://en.wikipedia.org/wiki/Chicken_%28Scheme_implementati...

Re: Why I Don't Want to Learn Go

#124

Post by losvedir »

msutherl wrote: post #120
heretohelp wrote: post #4

I concur with the concurrer and the author with my own more 'positive' addendum: I just want a cleaned/tarted up C. Something that doesn't make the critical mistakes of Go and Obj-C (adding runtime overhead), but adds optional compile and runtime semantics that can be very helpful and powerful. Some ideas: No GC. This is NOT negotiable. I'm tired of belabouring that point. Give me something nicer than the current C b…

I'm curious if anybody has written something equivalent to CoffeeScript for C...

As I understand it, this fellow named Bjarne Stroustrup did once. Of course, the project eventually grew beyond its humble beginnings...

Re: Why I Don't Want to Learn Go

#125

Post by adgar »

acdha wrote: post #117
adgar wrote: post #100

Earlier quoted context omitted.

I'm a bit concerned about at least one measurement: Read 16-byte file 100000 iterations 2.1s for 100k reads 21219.3ns per read This appears to be testing... the filesystem cache? It's certainly not seeking on a rotational disk, "SSD" isn't on the page, so... not sure where he's getting 21 microsecond reads from.

It's measuring the overhead of a set of open()/read()/close() syscalls - exactly the situation where you would want to use the cache to avoid physical disk latencies swamping the language variation.

Then it should say so, not suggest any rereading is being done and that it's just kernel plus memcpy.

Re: Why I Don't Want to Learn Go

#126

Post by modeless »

nknight wrote: post #98
flogic wrote: post #76

Earlier quoted context omitted.

In C, don't people just allocate a slab of memory for critical paths too?

Sometimes, perhaps, but simple malloc/free are much faster and more predictable than what you see in GC'd languages, often mitigating the problem. On top of that, many critical paths can avoid even those by confining their memory allocation to the stack, something that effectively ceases to exist in GC'd languages.

malloc is not "much faster" than GC; it's often a performance bottleneck. That's why any C/C++ project worried about performance writes custom slab allocators, which a GC doesn't prevent you from doing. In fact, the GC frees you from thinking about memory management in most cases so you can focus your effort on optimizing the pieces that count. GC doesn't prevent stack allocation either; C# has explicit stack allocation and Java does it implicitly with escape analysis. The only advantage of malloc is its predictability. Hopefully Go will eventually get a pauseless collector to mitigate that concern too.

Re: Why I Don't Want to Learn Go

#127

Post by dlitz »

heretohelp wrote: post #18
cageface wrote: post #17

Earlier quoted context omitted.

It's hard to love Java as a language but I'll still sometimes reach for it over Ruby or Python or C because it's not that much more verbose and it can get within 4x or so of C++ code without even trying. And often the large codebase finds you, no matter how hard you try to avoid it, and there you start to appreciate some of the design decisions of Java.

I don't deny it has its place for some people, but it's definitely not my experience that >Ruby or Python or C because it's not that much more verbose I've seen some shocking differences in LOC and comprehensibility between Ruby/Python vs. Java code, even when a concerted effort has been made to avoid the typical sins of Java codebases. You might just be more patient than I am, or a better Java programmer. I don't kn…

> You might just be more patient than I am, or a better Java programmer. I don't know. All I know is that I end up experiencing kidney failure every time I have to interact with Java code.

I don't experience kidney failure, just a sudden urge to scrape my skull against a rough, brick wall. Life is too short for me to spend it dealing with that crap and the community that insists that "Java's not slow", even though it needs gigs and gigs of memory to run (which takes forever to populate and blows your cache), has no shared libraries, no copy-on-write, no memory protection, and no dozens of other things that Unix has had for decades for a reason.

Re: Why I Don't Want to Learn Go

#128

Post by stcredzero »

pjscott wrote: post #116
minimax wrote: post #65

Earlier quoted context omitted.

I don't think you're getting his point. I can still replace GC with malloc() and we end up with the same criticisms of C that you have of Go and Java. > I'm saying that much system level work has to optimize by not using malloc(). I've literally implemented off-heap malloc()/free() in C because malloc() is so untenable. Anyone who has had to write fast C programs that make a lot of small objects eventually ends up he…

You could make the same kind of criticisms, but not with the same strength. there are real quantitative differences between the speed of explicit malloc/free and even a really nice garbage collector. (Unless you have a very special allocation pattern, like a whole lot of short-lived allocations and a generational garbage collector that uses stop-and-copy for the nursery generation. That's like the best possible case…

1 - a whole lot of OO and functional Lisp programs use your "very special" pattern of short lived allocations.

2 - You can rig the game so generational GC beats malloc/free.

3 - It's not a criticism, it's a general principle. One always pays for performance. If your performance requirements are low enough, you can even take out a loan on them, so to speak, by using a more expressive language.

Re: Why I Don't Want to Learn Go

#129

Post by kamaal »

mapgrep wrote: post #109
stdbrouw wrote: post #59

Earlier quoted context omitted.

(1) Google spent lots of developer resources on Unladen Swallow, which ended up not giving the speed increases they expected, but that's another story. (2) Last thing I heard, Google's trying to minimize their Python usage in favor of Java.

Re #2, I heard ~November that Python was deprecated in production at Google. No idea what the details/caveats on that are (I presume it applies mainly to new code?).

This is something that I see at many places these days. Scripting has become synonymous with Perl. And for anything else People are really going in for Java.

But Django and Rails seem to be the major reasons why people continue to use Python.

Having said that no company that is making billions in profits is going to bet their very survival on a framework written and maintained by volunteers. Frameworks come and go, Every 5 years there is something new.

Re: Why I Don't Want to Learn Go

#130

Post by kamaal »

leoc wrote: post #111
dagw wrote: post #53

Earlier quoted context omitted.

Given that Google hired Guido Van Rossum and that python is one of the three (and up until very recently two) supported languages for GAE, I think we can safely assume the Google isn't entirely anti python.

> I think we can safely assume the Google isn't entirely anti python. I don't suggest otherwise. It's known that Python is one of Google's three languages approved for internal use (or apparently four now that JS has got a foothold). But I'm sure I've seen reports that people are nonetheless being pushed towards Google's other two officially blessed languages, at least on production code - and in fairness, Google is…

The problem is python never took off as a scripting language. In spirit it was a great language to develop applications in.

This creates a dilemma for a lot of people while choosing a technology. If you have to choose a language where you don't want to develop stuff quickly. Then you now have sufficient time to choose a static language and then develop stuff at the speed desired.

For other quick stuff there is Perl anyway.And it doesn't make sense to use Python, which is slow(compared to java), which doesn't give quick development cycle(compared to perl).

If you wish to relevant for a long time, then you have to do at least one thing properly.

Post reply on HN