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

Seven years of Go

blog.golang.org

Post reply on HN
Print view View original

141–150 of 318 posts

Re: Seven years of Go

#141

Post by jkn »

pcwalton wrote: post #127
jkn wrote: post #124

Earlier quoted context omitted.

Indeed. But looking at the GC improvements in Go 1.8 ("typical" GC pauses of less than 100us), the set of cases where you can't use the language might be shrinking significantly. Now if only they could turn that in some sort of guarantee...

The sole performance metric of GC is not pause times! Throughput matters just as much if not more! GC pauses are not the only reason to use Rust. Rust is not "little Go" that you reach for only if you don't want GC. You might want package management, data-race-free concurrency, a mature optimization framework, runtime-free operation, concurrent data structures, fast C interfacing, etc. etc.

You're right of course about the GC metrics. And there was some disappointing increase of GC CPU usage with the 1.8 changes (I don't now the current status). But some of the items you mention (package management, mature optimization framework) will hardly make cases where Go cannot be used, which was the original point. Same for concurrent data structures which can be implemented in Go, even if the lack of generics makes it less convenient. I do agree with you regarding the other items.

Re: Seven years of Go

#142

Post by fizzbatter »

jerf wrote: post #72
fizzbatter wrote: post #28

Earlier quoted context omitted.

Type safety mainly, i think. Performance is a definite concern, but they have a lot of internal applications and the stability of them varies. I offered up that less dynamic languages would provide more speed and reliability to boot. I know Python got types in 3.5, though i'm not sure if it has Go-like Interfaces (Traits in Rust). If not, i think it really should. I do firmly believe they'll be quite happy with Go th…

Python has always had Go-like interfaces in practice. The problem was that they were not reified into the code, so you had no easy way to know when calling a function and passing it a "file" exactly what file-like things the function was going to do with that "file" without reading the source code. You had to extract the interface yourself.

Not only that, but there's simply no guarantees. You can abuse a function in any way you see fit in Python, and the only one that suffers is your runtime sever :(

Optional types in 3.5 look awesome - but i don't want to lose duck typing. I want Go-interfaces in Python.

Re: Seven years of Go

#143

Post by olauzon »

brandur wrote: post #41
fizzbatter wrote: post #8

So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding. Now, i joined a new job and they're in need of a new language for some backend tasks - the choice was mine. Rust or Go? The backend tasks were heavy API servers - nothing amazing, we don't do groundbreaking work. Python was their existing language, but they w…

I've taken a very similar path recently myself and started looking into Rust. > 2. Proper error handling. I love error checking Hugely agree here. I can get behind Go's overall mentality of returning errors instead of throwing exceptions, but in my mind there are not enough primitives in the language to keep this style of coding safe and sustainable. Rust's `Result` type, `try!` macro, and pattern matching are an inc…

> Overall though, Go is probably still the more practical choice between the two languages (due to Rust's incredibly high barrier to entry).

Does Rust really have an "incredibly high barrier to entry?"

I've been using Rust for a few months, and just deployed my first high-throughput application a month ago, and my experience has been the opposite. Yes, the first couple of weeks were a bit rough while I was getting used to the ownership system, but since then I have been progressing at a relatively quick pace. The package and dependency management facilities are incredibly good, and I've found high-quality libraries for nearly all my initial needs.

Compilation times could be faster, but the error messages provided by the compiler are so useful that I have come to depend on compilation errors for refactoring. The gains in predictable performance and resource utilization have far outweighed any initial cognitive overhead in the learning process. The community and the resources they provide are fantastic.

Coming from a mixed dynamic language and functional programming background, I could see room for improving certain FP aspects of the language, but am impressed with the pervasive pattern matching and collection handling.

Not a knock on Go, but rather an endorsement of Rust and its future.

Re: Seven years of Go

#144

Post by fizzbatter »

pcwalton wrote: post #129
weberc2 wrote: post #113

Earlier quoted context omitted.

Right, but I think those cases are few and far between. Basically where you need blistering performance and/or deterministic resource usage. I would throw "safety" in there, but many (most?) safety-critical applications are written in C, and Go is certainly safer than C.

> Right, but I think those cases are few and far between. Basically where you need blistering performance and/or deterministic resource usage. No, there's a lot more. See my reply to your sibling comment. > I would throw "safety" in there, but many (most?) safety-critical applications are written in C, and Go is certainly safer than C. This argument doesn't make any sense to me. Why is being better than a language fr…

> Besides, Go is not any safer than C when it comes to data races. I care about those a lot too.

Agreed. It may be safer in the realm of "oops i forgot to free memory", but i've had more panics than i could count in Go.

Re: Seven years of Go

#145

Post by fizzbatter »

greendragon wrote: post #122
snovv_crash wrote: post #44

Earlier quoted context omitted.

From my time doing server backend python dev, it is only catching any problems at runtime, everything from missing arguments to typos in variable names that accidentally match another variable, turning your int to a string. Having a compiler catch these saves much time and hairpulling. And having unit tests as a final defense, rather than the only defense, does wonders for my peace of mind.

As a Python user and fan I hear this complaint a lot. I understand but I can't really agree since things like typos and type fails pretty much never happen to me, at least in production. My secret? I use the REPL, heavily. (And not even in the grand Lisp fashion, because Python's REPL isn't very advanced, mostly I use it just off to the side and maybe or maybe not running an instance of the full program, or parts of…

> plus it can catch things compilers don't, such as null pointer exceptions.

Note, that it depends on the language. In the case of Go, yes. In Rust? Definitely not.

Re: Seven years of Go

#146

Post by weberc2 »

pcwalton wrote: post #134
weberc2 wrote: post #118

Earlier quoted context omitted.

I'm a former C++ dev. I've made repeated attempts to learn Rust over the last few years. I now feel like I'm capable of building things with much effort and frustration and constant Googling, but with a small fraction of the effort. By comparison, I got to the same point in Go in an afternoon.

I'm not interested in debating which language is easier to learn for C++ programmers. I'm pushing back against the (clearly false, IMO) idea that adopting Rust is a mistake .

In the context of the conversation, adopting Rust over Go is a mistake for the majority of applications primarily because of the difference in learning curve. Of course there are other factors, and not all applications are equal. I threw in my C++ background to demonstrate that I'm quite capable of thinking in the low-level terms demanded of Rust programmers, and my learning curve was still very large. You can disagree if you like, but my comment was related.

Re: Seven years of Go

#147

Post by weberc2 »

pcwalton wrote: post #112
weberc2 wrote: post #92

Earlier quoted context omitted.

I don't mind the repetitive glue code. It might be nice to clean it up a bit, but it's the least of my concerns with Go. When I miss generics, it's usually for some tree-like structure, but the cases where I need a high-performance tree structure and can't take the performance hit of `interface{}` are few and far between.

Performance is not the main problem with interface{}.

Right, but it's a problem tagged-unions solve.

Re: Seven years of Go

#148

Post by ramchip »

Skinney wrote: post #137
wyager wrote: post #120

Earlier quoted context omitted.

Precisely as I said, "The only major benefits over, say, C++ or Java (which I don't think are very impressive languages) are a few convenient threading primitives" 99% of projects don't need green threads. But for those that do, I'd much rather use a language better suited to the purpose, like Haskell or Erlang. This isn't a very convincing argument for Go.

Erlang isn't necessarily better than Go in this regard. Since Erlang is interpreted and everything has to copied between processes, Go is bound to be faster than Erlang, especially when it comes to parallelism. Go is also statically typed, which in my experience makes it easier to avoid bugs in large teams. Erlang, however, is much better at distributed concurrency. There are few who suits this use case better. As in…

Erlang is actually compiled, and binaries above a certain size are reference-counted rather than copied between processes. It still makes various compromises like using bignums and doing preemptive scheduling which make it slower in general.

Re: Seven years of Go

#149

Post by pcwalton »

jkn wrote: post #141
pcwalton wrote: post #127

Earlier quoted context omitted.

The sole performance metric of GC is not pause times! Throughput matters just as much if not more! GC pauses are not the only reason to use Rust. Rust is not "little Go" that you reach for only if you don't want GC. You might want package management, data-race-free concurrency, a mature optimization framework, runtime-free operation, concurrent data structures, fast C interfacing, etc. etc.

You're right of course about the GC metrics. And there was some disappointing increase of GC CPU usage with the 1.8 changes (I don't now the current status). But some of the items you mention (package management, mature optimization framework) will hardly make cases where Go cannot be used, which was the original point. Same for concurrent data structures which can be implemented in Go, even if the lack of generics m…

Aggressive compiler optimizations are not optional in many domains.

One rule of thumb that a lot of people don't realize is that if you aren't maxing out your sequential performance, your parallel multicore algorithm usually loses to an optimized sequential one. The reason is simple: parallelism introduces overhead, leading to guaranteed sublinear speedups. Compiler optimizations, on the other hand, frequently result in multiple factors of improvement.

Re: Seven years of Go

#150

Post by wsmith »

richard_todd wrote: post #70
gtrubetskoy wrote: post #24

I have decided to get proficient in Go about 3 years ago and I am glad I did. One of the discoveries in the process was that Go enables you to do things that previously were extremely difficult and you'd typically not even consider as options. Many of the "old" ways of thinking do not apply to Go, and I had to get over the phase of looking for an ORM or webapp or testing frameworks - they don't exist because they are…

I miss generics, not because I would write new generic functions all the time, but because a few key generics provide infrastructure that increases the beauty of programs dramatically. The tupled (T, error) return types are a key area I think generics would help. The error-tuples themselves aren't the problem, but rather Go's inability to cleanly handle them. Threading error state around requires repetitive glue code…

Which is better, generics or macros?
Post reply on HN