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

The State of Go

talks.golang.org

Post reply on HN
Print view View original

261–270 of 402 posts

Re: The State of Go

#261

Post by cube2222 »

kuschku wrote: post #246
twic wrote: post #209

Earlier quoted context omitted.

These uses of panic look a lot like the canonical use of unchecked exceptions in Java: the programmer has made an error, which they could have avoided. It's a bug. There's no point returning an error and letting the program try to recover, just blow up with as much information as you can, so the bug can be fixed. The canonical use of checked exceptions in Java is for unpredictable events - almost always related to in…

> There's no point returning an error and letting the program try to recover, just blow up with as much information as you can, so the bug can be fixed. Well, imagine a game letting the user roll a dice. "Chose a number of sides for your dice". In such cases, handling such a panic might be useful. And knowing that it exists might be useful, too. If the language does not allow specifying a range of a type (for example…

You should ALWAYS check the input you get from users. So this really wasn't a good counter argument.

Re: The State of Go

#262

Post by coldtea »

pvg wrote: post #225
danellis wrote: post #194

Earlier quoted context omitted.

Perhaps you could help clear up the misconception by fixing Wikipedia's 'System Programming' and 'System Programming Language' entries. It might also be worth commenting on these[0] Stack Exchange answers, too. [0] http://softwareengineering.stackexchange.com/q/151610/54726

Why would I? They support what I said directly - 'system programming' is not limited to operating systems. Here's a bit from one of the Wikipedia entries you mention. "System software is computer software designed to operate and control the computer hardware, and to provide a platform for running application software. System software is computer software designed to operate and control the computer hardware, and to p…

"System software includes software categories such as operating systems, utility software, device drivers, compilers, and linkers"

Most of those things can be summed up as "operating systems" (operating system, device drivers, and utility software, e.g. basic backend services) plus some essential supporting stuff (compiler and linker).

So, yeah, it's pretty much constrained to "operating systems" and the few essential items. It's not about network servers the kind Go is used for.

Re: The State of Go

#263

Post by jcadam »

nvarsj wrote: post #201
chimeracoder wrote: post #189

Earlier quoted context omitted.

> It's not a criticism I'm responding to criticisms in this and other HN threads about Go, so yes, I'm talking about a criticism. > it's literally how the Go language creators themselves describe it. See the Rob Pike quote Unless you think Rob Pike is saying that Google is hiring mediocre programmers (hint: he's not), that statement is intended as a criticism of academics ("researchers"). He's saying that the same th…

> Unless you think Rob Pike is saying that Google is hiring mediocre programmers (hint: he's not), Actually that's exactly what he's saying - although "inexperienced" is probably a better word than mediocre. Golang is the modern blub language. It's really great for large companies and big code bases used by many people who want to get quickly up to speed. A decent, even new, programmer can get up to speed and be very…

Bah, a language being 'easy to get up to speed with' and 'a perfect fit for large teams working on huge code bases' should be a clue to stay the hell away from it.

Because if Golang maintains its current momentum, someday soon the developing world will start pumping out legions of mediocre Golang coders, just as they did with Java.

Re: The State of Go

#264

Post by watwut »

MichaelGG wrote: post #65
rpercy wrote: post #10

Earlier quoted context omitted.

Do you have an example of the community celebrating mediocrity? My impression is of a community willing to go without some features, in order to preserve those it values. Namely simplicity, explicitness, terseness, and consistency.

Explicitness and terseness seem a bit at odds - I wouldn't call go code very terse at all. It seems verbose and repetitive. Consistency? Aren't only some built in types blessed with generic functions? Mediocrity? The preference for writing loops over simple maps or folds is a bit mediocre. IIRC in Tim Sweeny's "Next Mainstream Programming Language"[1], he notes that around 90% of all the loops in Unreal are folds or…

The loop and map are equally readable, it is just that some people are used to one form more then the other.

More importantly, how many character needs to be used for simple idiom like that has zero influence on how maintainable your system is going to be few months later on, how fast it is and so on. The difference between loop and map wont make you do less or more bugs. It may make you read the code few seconds longer first time you encounter form you are less used to - but then you will adjust and read it just fine.

Re: The State of Go

#265

Post by coldtea »

chimeracoder wrote: post #198
prodigal_erik wrote: post #169

Earlier quoted context omitted.

>I strongly reject the criticisms that Go is meant for "mediocre" programmers I don't know how else to describe people who don't resent being second-class citizens under the library designers, who don't insist on being able to create their own abstractions and use them with the operators that slices or maps support. The language has extensible interfaces but doesn't use them for things like iteration and equality.

> I don't know how else to describe people who don't resent being second-class citizens under the library designers... One suggestion: describe them as "people who have a different opinion than I do", rather than automatically concluding that anyone who doesn't feel the same way as you do about something must be "mediocre". There are popular languages that I can't stand writing, and languages that I think are badly d…

>One suggestion: describe them as "people who have a different opinion than I do"

Some "different opinions" are just different opinions, other "different opinions" do indeed point to mediocre programmers.

I'm not saying that is the case with Go: just that what you wrote is orthogonal. One can have a different opinion that is NOT to be respected, but dismissed. Not everything is equally valid.

Re: The State of Go

#266

Post by pka »

eeZah7Ux wrote: post #239
prodigal_erik wrote: post #173

Earlier quoted context omitted.

It's an apt metaphor. Much like programming, there are a hell of a lot of people driving who really shouldn't be.

Then there should be programming licenses: Level 1: let interns use Go(-karts), like their parents did with Basic. Level 2: most languages. Proper training required and you still have to be careful. Level 3: C, C++, critical code, kernels, crypto code. Training a commercial airline pilot takes years; and while this stuff is not hip enough for some, there's plenty of demand.

C programmers should be held personally accountable for the damage they cause.

Now of course everybody makes mistakes, but if you deliberately choose C when there are better options available then you should pay out of pocket for your buffer overflows and 0-day exploits.

Re: The State of Go

#267

Post by fnl »

Strom wrote: post #223
fnl wrote: post #210

Golang really seems to have come a long way. But what holds me back from using it are the dangers of deadlocks and segfaults (due to forgotten error handling) that might be introduced even inadvertedly if applied to industrial-scale projects (say, 1M+ LOC, 10+ developers). That is, I see many small (server/microservice) projects flourish with Golang, and it seems an excellent replacement for certain types of C projec…

It's even easier to mishandle errors and get deadlocks in C++. That is in addition to all sorts of other fun like buffer overruns. If the team is capable of not messing these things up in C++, then they are more than capable of not messing up in Go.

Modern C++14 provides quite good support on those fronts, and modern Java8 has lost most of its "code notoriety".

But that's just arguing back and forth. Here's the real argument: What popular OSS projects of noteworthy scale are being developed in Go? I know a few dozens in either Java or C++, and even a few fairly noticable Scala projects (Spark, Flink, Play, ...), but I yet have to see anything written in Go that can be called "industrial sized".

Re: The State of Go

#268

Post by Hydraulix989 »

enneff wrote: post #250
Hydraulix989 wrote: post #149

Why are we getting rid of OSX 10.8 and some of ARM6? Are they _really_ that much extra work to support? I have a hard time believing so.

Well Apple stopped supporting 10.8, so why should Go continue to support it? ARM6 support is a lot of work, actually, as IIUC a lot of stuff that the chip doesn't support needs to be done in software, and we don't have a reliable platform for testing against ARM6.

I guess I am a bit more upset about ARM6. How were you testing before? Have you considered using an emulator? Even Linux still supports ARM6.

Re: The State of Go

#269

Post by hellofunk »

hlandau wrote: post #22
greg7mdp wrote: post #7

My impression is that Go is a language that was cobbled together to simplify the coding of some specific applications, such as simple servers. It lacks any kind of purity, is not the best choice for any specific task, but is just good enough for some (many?) tasks. And poor type safety! Frankly, I can't help being disappointed by how bland this language is, and I have zero interest in using it. Maybe because I like c…

Personally I like Go; it's a very fun language for me. It's true that it sometimes feels like a language designed for the precise purpose of writing daemons, but that's exactly why I like it. The thing about Go is that its opinions on concurrency are ones I share, to the point where I was practically waiting for something like Go to be invented. Other than say, Erlang, I'm not aware of many alternatives which provide…

Re: green threads

The C++ Actor Framework is awesome

https://actor-framework.org

Re: The State of Go

#270

Post by ice109 »

mattnewton wrote: post #93
DrBazza wrote: post #42

Given some of the comments, I'll make the same comment I've made before: Stroustrup is right, there are languages that people complain about, and languages that no-one uses. Go is now firmly in the former camp. I'm a C++ dev, and I really enjoy using Go. If you don't like what it does or how it does it, it's not for you. Either way, people are out there using it, making systems from it, and generally getting on with…

Idk if that's such a clean binary, one of my favorite languages is Haskell, and people both complain about that and don't use it :)

I'm starting a backend job tomorrow that's all Haskell. what are people's complaints?
Post reply on HN