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

31–40 of 139 posts

Re: Why I Don't Want to Learn Go

#31

Post by smanek »

stcredzero wrote: post #24

And before you tell me that the GC isn't that big a deal: it is. Literally every big project I've worked on in a garbage collected language reserves a bunch of memory off-heap at startup and uses that for allocations on the critical path because the GC kills performance. You could replace occurrences of GC with malloc, switch the language to C, and it would be just as factual. Basically, what the author is saying is…

It's different, because I'm saying that much system level work has to optimize by not using a garbage collector. I've literally implemented off-heap malloc()/free() in Java because GC is so untenable.

I argue that makes a language with has a GC that you can't avoid (as far as I know, it's impossible to allocate an 'object' off-heap in Go) a fairly poor choice for much system level work.

Which means, if Go is to find a niche, it's got to be at a 'higher-level.' And that requires competing more directly against Java or Python - a much higher bar than trying to be better than C.

Re: Why I Don't Want to Learn Go

#32

Post by heretohelp »

groovy2shoes wrote: post #28
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…

Have you had a look at Clay? http://claylabs.com/clay/

It's the most promising out of the current cohort that includes Rust, I'll say that much.

Clay seems to understand that you cannot compromise.

Re: Why I Don't Want to Learn Go

#33

Post by jacquesm »

batista wrote: post #23
heretohelp wrote: post #11

Earlier quoted context omitted.

It seems most people don't really understand the core of systems programming. Let me try to summarize: There can be no limitations of any kind in terms of expressing to the machine, precisely how the machine should behave. Period. No ifs-ands-or-buts about it. This means you must be able to define memory layout, management, instruction behavior and semantics, and optimally, be able to predict cache locality (arrays v…

It seems most people don't really understand the core of systems programming. Let me try to summarize: There can be no limitations of any kind in terms of expressing to the machine, precisely how the machine should behave. Period. No ifs-ands-or-buts about it. Actually it seems you don't understand that people mean different thing by "system's programming". Not all system programming is about no-compromise, i.e as it…

Chances with these 'random dudes on HN' are that they actually know a thing or two, I'd hate to make any assumptions there.

As for your 'what people mean by systems programming', how about you both stick to the definition/description used here:

http://en.wikipedia.org/wiki/System_programming

That would make it much easier to communicate. From the looks of it systems programming is all about no compromise, specifically for the reasons outlined by the GP. Now I wouldn't know him from Adam but even outside the realm of driver and OS programming there is plenty of room for software that is 100% deterministic in terms of time and space consumed.

Note that the 'alternate usage' term in the page linked above was specifically not what the GP was talking about if I understood it correctly.

Re: Why I Don't Want to Learn Go

#34

Post by zoul »

microtonal wrote: post #16
jrockway wrote: post #7

Go is designed for large codebases, which is a problem that the author may not have, and so he may not see the benefits. One key feature is that the Go compiler itself is the style guide: it automatically reformats your code to remove style guide violations. This makes it easy to work on a codebase the size of Google's because everything looks like it was written by the same person. We try to do the same thing for C+…

Go is designed for large codebases, which is a problem that the author may not have, and so he may not see the benefits. Aren't most serious languages designed for large code bases? (and compile faster than anything else), So, why not invest in incremental compilation for an existing language? E.g. the ECJ compiler for Java has done wonders in terms of immediate feedback while developing. clang aims to do the same fo…

> Aren't most serious languages designed for large code bases?

Maybe the big companies like Google and Facebook are approaching a new meaning of a “large codebase”. They have a huge number of programmers, the development is much more distributed into different locations and time zones, and the release cycles are much smaller than they used to be with large codebases in the past. There’s for example this very interesting discussion about the way these companies use their versioning systems:

https://news.ycombinator.com/item?id=3548824

Some of the practices (like keeping their whole codebase in one big repository) look quite questionable, if not downright stupid from a smaller viewpoint, but make sense in their case. Go could be a similar thing – most serious languages are designed with good modularization, encapsulation and other features that support large scale code bases as most of us know them, but that does not mean these languages are a great match for software at the Google scale.

Re: Why I Don't Want to Learn Go

#35

Post by heretohelp »

jacquesm wrote: post #33
batista wrote: post #23

Earlier quoted context omitted.

It seems most people don't really understand the core of systems programming. Let me try to summarize: There can be no limitations of any kind in terms of expressing to the machine, precisely how the machine should behave. Period. No ifs-ands-or-buts about it. Actually it seems you don't understand that people mean different thing by "system's programming". Not all system programming is about no-compromise, i.e as it…

Chances with these 'random dudes on HN' are that they actually know a thing or two, I'd hate to make any assumptions there. As for your 'what people mean by systems programming', how about you both stick to the definition/description used here: http://en.wikipedia.org/wiki/System_programming That would make it much easier to communicate. From the looks of it systems programming is all about no compromise, specificall…

You have it right and seems to understand systems programming and the consequences of the necessities underlying it perfectly.

Re: Why I Don't Want to Learn Go

#36

Post by jacquesm »

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://…

You could compare python with perl or php, you could compare Go with C, C++ or Java.

But to compare Go to Python is a bit weird.

Of course, you could do it, but why would you, almost every metric that you'd want to use would be off. You're comparing a compiled language with lightweight threads aimed at just-above-low-level programming backed by a single vendor with an interpreted language that is mostly geared towards single threads of execution with a very high level of expressiveness that is developed by a bunch of open source gurus under the supervision of a benevolent dictator.

Re: Why I Don't Want to Learn Go

#37

Post by masklinn »

heretohelp wrote: post #30
masklinn wrote: post #19

Earlier quoted context omitted.

Wasn't bitc trying to do some of that stuff? An other option you might want to look into is Rust[0], especially since the language is still in its early days (0.1) and the developers are more than willing to fix things which don't work. * It does not have bit fields or bounds-checked arrays (which it calls vectors) at this point I think * A bit of GC: it has a reference-counted pointer type, which is task-local, whic…

Been following Rust and bitc. I'll leave bitc alone and instead comment on Rust: Rust gets a lot closer than Go, but is still straddling this awkward territory between C and Java. I would imagine that Rust would be fantastic for implementing a database or a web browser or anything else equally complexity-management and performance driven. The concurrency and safety semantics seem to make that case even stronger for m…

> I would imagine that Rust would be fantastic for implementing a database or a web browser or anything else equally complexity-management and performance driven.

Yeah that's about what I'd expect considering the language's goals.

> Safety is one thing, mandatory safety means a mandatory runtime overhead with a mandatory reduction in control and power over the code which is unacceptable.

Rust has the `unsafe` escape hatch for this, unsafe blocks can do whatever the hell they want and are "unsafe function" and "unsafe pointer" types which are known to bypass Rust's safety mechanism and can only be used in unsafe blocks.

Re: Why I Don't Want to Learn Go

#38

Post by alexchamberlain »

heretohelp wrote: post #8
jgrahamc wrote: post #6

This is addressed on the Go FAQ: http://tip.golang.org/doc/go_faq.html#garbage_collection The authors believe that they can make GC a low overhead operation in Go and they believe that it's essential to take memory management out of the hands of the programmer to save programmer effort. Lastly, they say that should you need to you can always work around the GC by doing your own memory management (linked example). It…

Nobody believes GC is a bad idea, it's a canard to suggest otherwise. It's that it's a contradiction of terms to say that you are offering a "systems" language but the language in question has non-optional GC. Go isn't competing with C and C++, it's competing with Java and C#.

I believe GC is a bad idea. Programmers should know what their objects are doing.

Re: Why I Don't Want to Learn Go

#39

Post by heretohelp »

alexchamberlain wrote: post #38
heretohelp wrote: post #8

Earlier quoted context omitted.

Nobody believes GC is a bad idea, it's a canard to suggest otherwise. It's that it's a contradiction of terms to say that you are offering a "systems" language but the language in question has non-optional GC. Go isn't competing with C and C++, it's competing with Java and C#.

I believe GC is a bad idea. Programmers should know what their objects are doing.

It doesn't always matter in all use-cases, I'm afraid.

Re: Why I Don't Want to Learn Go

#40

Post by heretohelp »

masklinn wrote: post #37
heretohelp wrote: post #30

Earlier quoted context omitted.

Been following Rust and bitc. I'll leave bitc alone and instead comment on Rust: Rust gets a lot closer than Go, but is still straddling this awkward territory between C and Java. I would imagine that Rust would be fantastic for implementing a database or a web browser or anything else equally complexity-management and performance driven. The concurrency and safety semantics seem to make that case even stronger for m…

> I would imagine that Rust would be fantastic for implementing a database or a web browser or anything else equally complexity-management and performance driven. Yeah that's about what I'd expect considering the language's goals. > Safety is one thing, mandatory safety means a mandatory runtime overhead with a mandatory reduction in control and power over the code which is unacceptable. Rust has the `unsafe` escape…

Then it might work out fine, I don't know.

In general I have to work off of their purported goals and priorities to get a feel for where the final destination of the language will be when it's more complete.

If they say they aren't going to prioritize machine semantics, C-level runtime performance, or systems-grade control over code generation then I have assume those priorities will fall wayside to the established priorities of safety and concurrency.

I'm not saying Rust will "fail" like Go seems to be doing so far, I'm just saying I don't think they're going to prioritize making Rust useful for driver development[1].

[1] Which I think is brilliant anyway. It's solving a very hard problem that needs solved.

Post reply on HN