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

141–150 of 402 posts

Re: The State of Go

#141

Post by tejasmanohar »

AsyncAwait wrote: post #138
markwolfe wrote: post #133

Earlier quoted context omitted.

I really enjoy programming in golang, having recently taught quite a few people the language I am forever thankful for its simplicity. This paired with vscode + click to see other peoples code is a great platform to get started with systems programming and tools development. Can't thank the go developers enough.

I also enjoy it, but just wanted to note that Go is not really a systems programming language, unless you mean "cloud/network systems".

Yeah, systems programming != distributed systems. I think Rust is a better example of a modern "systems" language.

Re: The State of Go

#142

Post by stcredzero »

coldcode wrote: post #32

I for one will be more interested in using Go when Jetbrains finishes their IDE. Clearly not everyone cares to develop in an IDE but after 33 years of doing it, I prefer the idea. Give Swift (my current work) as many years as Go has had (10 years), and maybe I won't find Go that interesting any more.

I for one will be more interested in using Go when Jetbrains finishes their IDE.

Gogland will be better, but for now, Jetbrains Webstorm with the Go plugin is pretty good.

Re: The State of Go

#143

Post by algesten »

randomdata wrote: post #104
labrador wrote: post #41

Earlier quoted context omitted.

I keep reading this and I keep wondering what's stopping someone familiar with language design from writing generics code

I wonder this too. For how important generics are claimed to be, it does seem strange that nobody has stepped up and helped out the core team in this capacity. They have been quite open about wanting generics, but do not have the resources to dedicate to implementing them in an acceptable fashion. But being an open source project, anyone can step up to fill that void.

How can a google backed project not have the resources?

Re: The State of Go

#144

Post by kajecounterhack »

nine_k wrote: post #132
sametmax wrote: post #111

Earlier quoted context omitted.

I don't know. I feel like if I need something productive, I would go very high level like Python. In the VERY rare case Python is too slow, I would go really low level like rust. I don't see the interest for something that not really low level, but not realy high level either like Go. If concurrency is the main issue and is the niche I'm targeting, I would go Erlang or Elixir. I have a hard time finding any use case…

The target audience is people who don't know Elixir and Rust, have no time and not enough conceptual base to learn them in a reasonable time, and have to ship concurrent code, fast. Go is stupidly simple; this can also be an upside . Python's concurrency story is much better in 3.5+ than in 2.x, but a lot of people use 2.x for various reasons.

Turns out also that, from an organizational perspective, it can take a lot to support n+1 programming languages. A codebase with 10 languages is more difficult to maintain than one with 2 or 3.

As a result I think there is large benefit to having a language like Go -- it satisfies many overlapping needs, and organizations can avoid adopting too many other languages that fulfill niche areas.

At Google there are only (5) core / officially supported languages: Python, Javascript, Java, C++, and Go.

Python is generally applied in a scripting context. Javascript in frontend context. Java / C++ where you'd expect. Go for writing servers, application infra, tools, scripts, etc.

Re: The State of Go

#145

Post by tejasmanohar »

Taek wrote: post #137
ptero wrote: post #21

IMO the Go goal is to be an enhancement of C. It is not as expressive as some existing languages (i.e., Go programs may be longer), but it is very good for translating clearly thought through logic into efficient machine code. It supports some of the features that original C lacks (networking, parallelism, channels, etc.), which to me is a very good thing. With minimal forethought this allows writing programs that ca…

In my experience writing go is very fast and reading go is also very fast. The language was designed to be very comfortable, and they did a great job with that. You sit down to write something and you don't have to think too much about the best way to tackle the problem, the lines of code just flow from your fingertips. There's mostly one way to do everything, which makes doing things easy. Code review is much the sa…

I feel the same. Go is a different type of terse. I think terseness goes beyond the number of lines. When I skim Go code, I can grasp the meaning of it very quickly.

Re: The State of Go

#146

Post by prodigal_erik »

bboreham wrote: post #71
greg7mdp wrote: post #38

Earlier quoted context omitted.

How can you write an efficient container without generics?

Container as in "Docker container"

That's just a jailed process. There's no reason to need a completely different language, especially one without any specific support for running untrusted code.

Re: The State of Go

#147

Post by oscargrouch »

Taek wrote: post #137
ptero wrote: post #21

IMO the Go goal is to be an enhancement of C. It is not as expressive as some existing languages (i.e., Go programs may be longer), but it is very good for translating clearly thought through logic into efficient machine code. It supports some of the features that original C lacks (networking, parallelism, channels, etc.), which to me is a very good thing. With minimal forethought this allows writing programs that ca…

In my experience writing go is very fast and reading go is also very fast. The language was designed to be very comfortable, and they did a great job with that. You sit down to write something and you don't have to think too much about the best way to tackle the problem, the lines of code just flow from your fingertips. There's mostly one way to do everything, which makes doing things easy. Code review is much the sa…

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.

Re: The State of Go

#148

Post by cdelsolar »

Groxx wrote: post #91
rpercy wrote: post #62

Earlier quoted context omitted.

Not really. In a language like Java, some of the questions I'd have to ask myself are: - Should I try to catch the exception, or just let it bubble up and edit my interface to include it? - Should I create a new exception type or reuse an existing one? - Should I throw a checked or unchecked exception? - Am I exposing implementation details via my interface? (eg I don't want to throw an SQLException from GenericDataS…

> check if err != nil, prepend a descriptive message, and return it. That'd be the RuntimeException equivalent, sure. But what do you do for the equivalent of checked exceptions? Errors are frequently recoverable, "err != nil" alone does nothing to help you there, and string manipulation is a horrific alternative to types.

You can have typed errors too. This is fairly common in Go. As long as it implements the Error interface.

Re: The State of Go

#150

Post by hota_mazi »

seagreen wrote: post #136
joaodlf wrote: post #14

I don't share some of the opinions I see in the comments here. I've recently started programming in Go and I am having a blast. Plus, I am making my systems faster and simpler with Go. I love concurrency in Go. I love the concept of Goroutines, the simple and intuitive use of Select. Channels still present a few mysteries here and there... But I'll get it at some point. But the n#1 thing for me in Go is: It's written…

Maybe it's because I don't have the "depth" of some of the HN users, but Go feels great to me. I doubt I have any more depth than you as a programmer, but I've gone one step farther than you down the language safety progression, so maybe my thoughts from here will be interesting. When I moved from Python to Go not only did my code become more safe, I actually became a better programmer. There are a lot of silly thing…

> When I moved from Python to Go not only did my code become more safe, I actually became a better programmer.

This is probably more due to the fact that you moved from a dynamically typed language to a statically typed one rather than this new language itself.

Post reply on HN