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

Go 1.4 is released

blog.golang.org

Post reply on HN
Print view View original

151–160 of 265 posts

Re: Go 1.4 is released

#151

Post by enneff »

teddyh wrote: post #120
dsymonds wrote: post #62

Earlier quoted context omitted.

Have you actually observed the Go community and how Go has been developed over the last five years? What you are saying are fair concerns in the abstract, but I cannot reconcile them with the reality of how the Go project operates. You also seem unusually hung up on its name. It's not like it's called Google Programming Language All Access.

I see from another comment that this release first happened, and then , afterward , the release was pushed to its “official” Git repository. This is not the way real open projects do releases, and instead indicates that the real development is done in-house and the code thrown over the wall. A name is important, as it is a symbol . As long as the language is called “Go”, Google will always have power over it, no matt…

> I see from another comment that this release first happened, and then, afterward, the release was pushed to its “official” Git repository.

You misunderstand. The release was made from the official open source Mercurial repository, and later pushed to the official Git repository, because this release coincides with the project's migration from Mercurial to Git.

Every single change of this release was written in public, reviewed on public mailing lists, and committed to a public version control system. You are misinformed and spreading FUD. Please stop.

Re: Go 1.4 is released

#152

Post by enneff »

teddyh wrote: post #128
diakritikal wrote: post #96

Earlier quoted context omitted.

Your assertions are at odds with everything observable with regards to development of the Go language.

I freely admit that I do not know the intimate details of Go development, but my point is that they are almost irrelevant. Go is still perceived to be controlled by (and therefore is controlled by) Google. How much that is actually true is almost irrelevant until the perception changes. And with a name like “Go”, Google likely has no intention or wish for that perception to change. I mean, can anyone claim that an in…

> I freely admit that I do not know the intimate details of Go development ... How much that is actually true is almost irrelevant until the perception changes.

Since you freely admit your ignorance, can you please stop making uninformed statements that spread FUD about Go? Those of us in the Go community that invest our lives in this project don't appreciate your senseless negativity.

Re: Go 1.4 is released

#153

Post by Dewie »

chaotic-good wrote: post #150
Dewie wrote: post #109

Earlier quoted context omitted.

I was at a lecture about security in C/++ code a couple of weeks ago. His conclusion was basically: > There are no silver bullets with regards to safety in C/++ code; in order to achieve security, the programmer has to pay the price of being forever vigilant. A lot of the complexity of Rust is for eliminating security pitfalls which are inherent in C/++.

It is common to use ARC and unsafe shared memory access in Rust. This defeats the purpose of this complexity. You can't isolate unsafe memory access. You rather write only memory safe code or end up with fully unsafe codebase where some nasty things (buffer overruns or segfaults) are possible. If somebody needs memory safety - managed languages with GC is the only real option.

> It is common to use ARC

What is unsafe about using atomic reference counting?

> and unsafe shared memory access in Rust.

That should be provided with a safe interface, or an unsafe interface if calling that code is not safe.

As for it being common: I think they are working on minimizing the need for unsafe code.

> This defeats the purpose of this complexity.

Like having a VM implemented in C defeats the purpose of the VM for that language being safe. No, not really - that C code has to be really vetted, just like unsafe code in Rust has to be really vetted.

I guess we might - eventually - be able to formally verify a language implementation, thus really proving that a language is safe (that goes for those managed languages, too). Maybe that will be feasible in a few decades, if ever. Alternatively, you can use the ATS language, where you can prove that unsafe usage of pointers etc. really is being used in a safe way.

> You can't isolate unsafe memory access.

Sure you can - owned and borrowed pointers in Rust are represented as raw pointers at runtime. It's a safe abstraction. And if there turns out to be a bug in that interface, and they aren't really safe, then that will have to be fixed promptly - unlike in C/++, where one would be forced to say "Well, that's your fault for not being careful".

Re: Go 1.4 is released

#154

Post by kibwen »

chaotic-good wrote: post #150
Dewie wrote: post #109

Earlier quoted context omitted.

I was at a lecture about security in C/++ code a couple of weeks ago. His conclusion was basically: > There are no silver bullets with regards to safety in C/++ code; in order to achieve security, the programmer has to pay the price of being forever vigilant. A lot of the complexity of Rust is for eliminating security pitfalls which are inherent in C/++.

It is common to use ARC and unsafe shared memory access in Rust. This defeats the purpose of this complexity. You can't isolate unsafe memory access. You rather write only memory safe code or end up with fully unsafe codebase where some nasty things (buffer overruns or segfaults) are possible. If somebody needs memory safety - managed languages with GC is the only real option.

  > It is common to use ARC and unsafe shared memory access 
  > in Rust
This is false. `Arc` is not common, and when it is used, it is to enable safe shared memory access.

  > You can't isolate unsafe memory access
This is also false. If you get memory unsafety outside of an `unsafe` block, it is a by definition a bug in the compiler.

Re: Go 1.4 is released

#155

Post by NateDad »

draven wrote: post #69
pentelkuru wrote: post #27

Earlier quoted context omitted.

You should be able to get up and running with Go extremely quickly if your default language is C. If there's a reason you must be using C rather than another language (require manual memory management, require code to be as fast as possible, etc.), then Go might not be applicable. Otherwise, Go feels like an updated C and I don't see a compelling reason not to invest a little time in checking it out for yourself.

> require code to be as fast as possible It's also pretty easy to write the performance critical parts of the code in C and call them from Go.

Yes but you really almost never need to do that. The speed difference is usually only a factor of 2ish... It's not like the factor of 10-30x for interpreted languages.

Re: Go 1.4 is released

#156

Post by NateDad »

tormeh wrote: post #138
Morgawr wrote: post #135

Earlier quoted context omitted.

>imagine yourself building UI component without classes or inheritance I see no problem at all. UI development in my opinion becomes much more elegant, concise and easy to follow/reason about in a functional language that does not implement classes or inheritance. As you said, Go has struct inheritance and interfaces, that's how you do things in Go and every Go developer is familiar with the concept, it's clean and e…

Well, if what you are doing is inheritance-heavy, then OOP features will make your code cleaner. It's what OOP is made for. You can do it in Go, but it's not as elegant.

There is almost never code that requires inheritance.

Re: Go 1.4 is released

#157

Post by steveklabnik »

matt_trentini wrote: post #139
MichaelGG wrote: post #60

Earlier quoted context omitted.

If you're using C/C++ and need the performance, look at Rust. Fairly expressive, good type system (and they figured out generics), and C++ like or better performance. All the power of manual memory control, with none of the downsides.

"or better performance"? I'd like to see some evidence if you have any. Rust has great performance in general - and I also agree that it is an appealing language - but I haven't heard anyone claim better than C++ performance before. I'd be very dubious of anyone making that claim...

As with all performance, it really, really, really depends on what you're doing. I _hate_ the Benchmarks Game, but there are some that we are faster: http://benchmarksgame.alioth.debian.org/u32/rust.php

Re: Go 1.4 is released

#158

Post by kibwen »

chaotic-good wrote: post #89
MichaelGG wrote: post #60

Earlier quoted context omitted.

If you're using C/C++ and need the performance, look at Rust. Fairly expressive, good type system (and they figured out generics), and C++ like or better performance. All the power of manual memory control, with none of the downsides.

It's too complex, we're already have C++.

Rust has fewer edge cases than C++ by an order of magnitude or so. Rust is effectively all the tools and best practices of C++11, except without the burden of twenty years of backwards compability (not to mention the albatross of being an almost-but-not-quite superset of C), and as a result it can design the entire language around these best practices and optimize them for ergonomics (Rust's boxed pointer is much easier to use than std::unique_ptr, especially since Rust defaults to move semantics), for safety (Rust's borrowed references are amazing when all you're used to is the use-after-free-for-all that is C++ references), and for speed (Rust's Rc smart pointer is faster than C++'s std::shared_ptr, because knowledge of ownership allows Rust to safely use non-atomic operations to bump the refcount).

Re: Go 1.4 is released

#159

Post by kibwen »

matt_trentini wrote: post #139
MichaelGG wrote: post #60

Earlier quoted context omitted.

If you're using C/C++ and need the performance, look at Rust. Fairly expressive, good type system (and they figured out generics), and C++ like or better performance. All the power of manual memory control, with none of the downsides.

"or better performance"? I'd like to see some evidence if you have any. Rust has great performance in general - and I also agree that it is an appealing language - but I haven't heard anyone claim better than C++ performance before. I'd be very dubious of anyone making that claim...

Rust has several specific areas where it is faster by default than C and C++, thanks to knowledge of ownership in the type system. The most dramatic example of this is that almost every pointer in Rust can be automatically and safely proven not to alias any other pointer, which is the equivalent of sticking `restrict` on every pointer in a C program. Sadly, Rust isn't actually passing this information onto LLVM just yet, so it's not generating code nearly as well as it could. :P

On the other hand, Rust also has specific areas where it is slower by default than C or C++. The most dramatic example here is that array bounds access is checked by default, with an unsafe method call for doing unchecked access. It strives to bypass this restriction by leaning heavily on iterators, which are an abstraction that allow you to safely omit the bounds check.

In the end, all that matters is that both languages offer zero-cost abstractions, so the ultimate arbiter of speed will be the optimizer on the backend. Saying that Rust is "faster than C++" is definitely premature at this point; I'll reserve that judgment for when it at last starts making use of all its free aliasing info.

Re: Go 1.4 is released

#160

Post by dragonwriter »

tormeh wrote: post #138
Morgawr wrote: post #135

Earlier quoted context omitted.

>imagine yourself building UI component without classes or inheritance I see no problem at all. UI development in my opinion becomes much more elegant, concise and easy to follow/reason about in a functional language that does not implement classes or inheritance. As you said, Go has struct inheritance and interfaces, that's how you do things in Go and every Go developer is familiar with the concept, it's clean and e…

Well, if what you are doing is inheritance-heavy, then OOP features will make your code cleaner. It's what OOP is made for. You can do it in Go, but it's not as elegant.

Inheritance isn't a property of what code does, but how the programmer chooses to do it. There is no problem that is inherently inheritance-heavy.
Post reply on HN