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

321–330 of 402 posts

Re: The State of Go

#321

Post by JacksonGariety »

I'm in a pretty weird place with Go.

On the one hand, I really cannot stop using it. I can build an small web applications in a day or two, I can write them in just slightly more lines than Rails, and the applications I can build are much speedier than Rails applications.

On the other hand, I really, really hate using Go. It's tremendously boring and I never feel the code is that elegant.

I've tried Haskell, but I end up messing around monads too much because there's so much IO.

Rails is fantastic, but I'd prefer to experiment. I never grow as a developer when I use Rails.

Node.js is great. But if I don't need to write a lot of JavaScript on the frontend I end up asking myself: why am I writing JavaScript on the backend?

Racket or Chicken Scheme look like good directions for me. Erlang looks interesting. Maybe I should give Clojure another shot?

Re: The State of Go

#322

Post by nickpsecurity »

vvanders wrote: post #228
pjmlp wrote: post #172

Earlier quoted context omitted.

> To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language. Having a GC doesn't forbid that, in very specific cases. Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, System C#, Swift, D are all examples of such languages.

I never said anything about having a GC, just that if you can't poke directly at memory when you need to then you're going to have a heck of a time working on the Systems Programming space.

Also remember Go was inspired a lot by Oberon-2. The Oberon languages were used for writing operating systems despite a GC. They just used assembly or UNSAFE constructs for stuff the type-safe or GC parts couldn't handle.

Re: The State of Go

#323

Post by geodel »

solipsism wrote: post #288
dilap wrote: post #81

Earlier quoted context omitted.

Nah. I like Go because the language itself is minimal yet powerful, and because the quality of engineering is extremely high. I am so tired of having to deal with bullshit because of poorly-thought-out and poorly-engineered tools; Go minimizes that. An excellent example is the handling of this bug report(§): https://github.com/golang/go/issues/12914 which resulted in this language-change proposal: https://github.com/…

I am so tired of having to deal with bullshit because of poorly-thought-out and poorly-engineered tools Seems to be some cognitive dissonance (in the modern erroneous sense of the word) going on. This was a hack necessary because the design of the library wasn't fully thought out. Imagining the world would one day become Google is not thinking things out.

> This was a hack necessary because the design of the library wasn't fully thought out.

Easy to say 'not fully thought out'. It took Java from version 1.2 to 1.8 to fix its date/time library.

Re: The State of Go

#324

Post by JackMorgan »

JacksonGariety wrote: post #321

I'm in a pretty weird place with Go. On the one hand, I really cannot stop using it. I can build an small web applications in a day or two, I can write them in just slightly more lines than Rails, and the applications I can build are much speedier than Rails applications. On the other hand, I really, really hate using Go. It's tremendously boring and I never feel the code is that elegant. I've tried Haskell, but I en…

Your comment is similar to how I feel about Clojure. It's "good enough" for me for most things. Whenever I need something fast, that's what I grab for first. But, it feels "mushy" after +10k lines of logic, and I'm wishing it was F# or Haskell. I think I just need to bite the bullet and only use Haskell from now on. If it's slower at first, meh, it'll catch up when it grows.

Re: The State of Go

#325

Post by nickpsecurity »

coldtea wrote: post #262
pvg wrote: post #225

Earlier quoted context omitted.

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 essentia…

Systems are relationships between input from the environment, algorithms/functions to process it, and output to the environment. Basically programs at a high-level representation. Systems analysis, design, and implementation started with basic control systems far as I can tell. At some point, there was a distinction between "systems" and "application" programming made by whoever. Original meaning of the term covered all programming where you then picked tools (eg languages) best suited for particular task.

Go's predecessors... Oberon-2, C, and Limbo... were two languages for OS's plus a distributed, systems language. Go's core is the first two with last being mainly for concurrency IIRC. That with ability to do unsafe stuff makes me think of Go as a systems language used mainly for regular applications.

Re: The State of Go

#326

Post by solidsnack9000 »

sidlls wrote: post #305
solidsnack9000 wrote: post #282

Earlier quoted context omitted.

Loops are just implicit goto... The argument for maps and folds is the same as the argument for structured programming in general: using common/reusable idioms brings clarity and familiarity.

Terseness doesn't necessarily bring clarity.

It's the recognizability, not the terseness, that brings clarity.

Although Python's approach is not terse -- `fstyle = [f(x) for x in arr]` -- it is eminently recognizable.

Your argument is not really about anything I specifically said; and without something to counterbalance, it argues against structured programming, too.

Re: The State of Go

#327

Post by sagichmal »

Scriptor wrote: post #315
sagichmal wrote: post #304

Earlier quoted context omitted.

Map hides a loop behind a statement. That's all I meant.

You can hide a loop behind a function call in Go, Python, really any imperative language. What makes map different is that it separates the looping mechanics (incrementing, initializing and appending to the collection) from the actual computation we want to perform on each element. It's just separation of concerns.

Yes. In Go, function and method calls are the primarily, perhaps only, mechanism of abstracting computational complexity. That is, when you see a function or method call, you know that "anything goes" back there, and you need to dig and find out what the computer is gonna be doing. Pretty much everything else is implemented "in plain sight"; in the case of fold/map, that means with a for loop, where you see precisely how many iterations you're going to step through.

You're right: map separates looping mechanics from computation. In Go, that's a bit too much obscurity.

Re: The State of Go

#328

Post by geodel »

tigershark wrote: post #212
oscargrouch wrote: post #147

Earlier quoted context omitted.

And those are the secret ingredients of a great language for team programming. And thats why Go will dominate the market that once was meant for Java.

I really hope not, there is already a lot of awful code around written in Java. I can't imagine codebases on the MLOC range written in a language even worse than java 1.4 (it didn't have generics, but at least it had exceptions)

There are already MLOC projects in Go like Kubernetes, Docker etc.

Re: The State of Go

#329

Post by geodel »

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…

Some(A lot of?) people use programing language just for day job. For them Java or Go would just do fine.

Re: The State of Go

#330

Post by [deleted] »

niftich wrote: post #163
vvanders wrote: post #155

Earlier quoted context omitted.

Normally it's the other way around, Go gets compared to other "Systems Programming" languages because somehow services got lumped in with that name over the last few years. To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language.

Go gets compared to "systems programming" languages because its designers specifically intended it to be used as such [1][2], albeit the definition of 'systems' they are using is deliberately evolved from the original shade of meaning as suggested by low-level languages that are sometimes deemed to be for 'systems programming' to illustrate that the nature of environments has changed, and a new approach is advantageo…

[deleted]
Post reply on HN