Golang 1.10 Offers Many Smaller Changes, Restores NetBSD Support

[phoronix]

Phoronix: Golang 1.10 Offers Many Smaller Changes, Restores NetBSD Support

Not only is there a new Rust release this week but the Google developers have put out the Go 1.10 update...

http://www.phoronix.com/scan.php?pag...-1.10-Released

[jacob]

Interesting how Go and Rust are always compared to each other. Yet apart from the superficial common trait that both want to be an improvement over C and both are strongly geared toward parallelism, they really are as different as it gets. They have very different design philosophies, they target very different applications and very different communities.

[AndyChow]

Go and Rust are compared because overall, they compete on the same objectives. Garbage collection (supposedly next-gen type, imo using old tricks with faster hardware), memory safe (i.e. no need to think), and taking advantage of the multicore topology. So while in the practical and technical, they are very different, the reason they are constantly associated is that journalists just look big picture, and big picture they seem similar.

I've played a little with go, and it's quite nice, but removes too much of the thinking that should be involved in programming, imo. I haven't touched rust yet, but it also seems promising. We are entering a brave new world, and this is where things seem to be going. Python is absolutely a horrible programming language, but hey, all the libraries are there and you can glue something very powerful very easily, moving data between completely different programs because someone else built it. So, if we can move past the horrible python syntax, and, this is blasphemy, but ruby also, and into go and rust, then it's probably a step forward. I do hope both gather a large community and improve the entire landscape. Because we need to escape the horrors of C++, Java, and python.

[jacob]

Go and Rust are compared because overall, they compete on the same objectives. Garbage collection (supposedly next-gen type, imo using old tricks with faster hardware), memory safe (i.e. no need to think), and taking advantage of the multicore topology. So while in the practical and technical, they are very different, the reason they are constantly associated is that journalists just look big picture, and big picture they seem similar.

I've played a little with go, and it's quite nice, but removes too much of the thinking that should be involved in programming, imo. I haven't touched rust yet, but it also seems promising. We are entering a brave new world, and this is where things seem to be going. Python is absolutely a horrible programming language, but hey, all the libraries are there and you can glue something very powerful very easily, moving data between completely different programs because someone else built it. So, if we can move past the horrible python syntax, and, this is blasphemy, but ruby also, and into go and rust, then it's probably a step forward. I do hope both gather a large community and improve the entire landscape. Because we need to escape the horrors of C++, Java, and python.

Go and Rust don't compete on the same objectives at all. Your examples are also inaccurate. Rust, unlike Go, doesn't have garbage collection. Go on the other hand, and unlike Rust, is not memory-safe. Go's objective is to be a language somewhere halfway between C/C++ and Python, easy to learn for programmers with backgrounds in either of those two worlds and combine the ease of use of a dynamic interpreted language like Python with the performance of a statically compiled language like C. It sounds like a crazy idea and a recipe for disaster but surprisingly, Go largely manages to achieve that and does it pretty well. Its main target are web app and web service developers, although it has also been picked up by the Linux community as a system programming language for everything related with containers.

Rust's main objectives are speed and security. It has been created by Mozilla because they were fed up with C++. Unlike Go, Rust does not try to be easy (and it most definitely is not an easy language at all), instead it tries to bring the powerful type systems and provability from advanced functional languages to the mainstream, and do it so that you could use it to replace C completely, including and up to writing drivers or OS kernels in it (both of which has been done already). Go can't be used for that at all, and while it is theoretically possible to use Rust for the type of projects Go excels at, it would involve massive, unnecessary pain with little benefit. It has been said that the average C programmer can master Go in 4 days. In the case of Rust, it would probably take 4 weeks just to begin to understand how some of its more unusual features work.

[mmstick]

Go and Rust are compared because overall, they compete on the same objectives. Garbage collection (supposedly next-gen type, imo using old tricks with faster hardware), memory safe (i.e. no need to think), and taking advantage of the multicore topology. So while in the practical and technical, they are very different, the reason they are constantly associated is that journalists just look big picture, and big picture they seem similar.

I've played a little with go, and it's quite nice, but removes too much of the thinking that should be involved in programming, imo. I haven't touched rust yet, but it also seems promising. We are entering a brave new world, and this is where things seem to be going. Python is absolutely a horrible programming language, but hey, all the libraries are there and you can glue something very powerful very easily, moving data between completely different programs because someone else built it. So, if we can move past the horrible python syntax, and, this is blasphemy, but ruby also, and into go and rust, then it's probably a step forward. I do hope both gather a large community and improve the entire landscape. Because we need to escape the horrors of C++, Java, and python.

I've been using Rust for 3 years, and experimented with Go for 2 years. Go doesn't really bring anything to the table. In fact, all of the features in the language were language theories that were developed back in the 1960s and prior. There are many advancements that have happened since the 60s that Go could have used, but did not due to the opinion of it's main developers that everyone should stick to using stone age tools and kludging through problems using The Old Ways, because simple is better than smart. Not to mention, you have a standard library which is both incredibly bare bones with core functionality, and offers a number of random sub-par libraries shipping in the standard library since day one.

Basically, you'll spend a lot of time copying and pasting code, and writing excessive amounts of boilerplate, because the language constructs are so limiting that they lack the capability to be expressive or flexible. I commonly find many use cases for generics in my every day programming that significantly reduces the amount of work I need to do to develop a solution, and presents a final solution which is leaner & more manageable than the equivalent Go solution. What features you are tossed are generally incredibly bad. Check out the awkward tuple pair return values, awkward error handling, awkward for loops & range syntax, and awkward interfaces.

Not to mention, GC-based languages are very much a dated concept. They are incredibly unpredictable, handle resources arbitrarily and abysmally, and are quite heavy on the resources. Go's GC is 'low latency', but make no mistake that this isn't due to some magically superior technology, but because the garbage collector consumes insane amounts of CPU as it constantly polls multiple threads for memory to free. You'll often times find that when running perf, around 30% of your program's CPU time is spent in the garbage collector. It's therefore no wonder that Rust & C are easily 3 times faster than Go.

But even worse is that the garbage collector also makes your language entirely unsuitable for the use of library development. Go libraries will never be suitable for developing system libraries that other languages link to. It's only useful for writing Go libraries. Using Rust, you can easily write system libraries, generate static & dynamic libraries, generate a C header with cbindgen, and then have Go, C, Vala, or any other language link to and use it as if it were a normal C library.

[Iksf]

Yea, I really don't get why Go gets the level of interest it does. Other than goroutines I really just don't see what it brings to the table. It's not innovative, its barely faster than Java most of the time while getting none of the benefits of a JVM base, they've stripped OOP and generic functionality from the language without implementing real alternatives, they've gone and reimplemented some ideas that are really falling out of favour in modern languages; like nulls and full GC, nothing new, interesting or particularly well implemented for control flow or in its basic syntax. I don't know, I keep thinking of Go, Swift and Rust as a little bubble of up and coming interesting compiled languages, Swift and Rust both feel like they're bringing a much more compelling product than Go is. Go just feels really uninspired to me. And I mean when it comes to the goroutine concurrency thing, there were other languages doing this stuff a long time ago, just none of them had the backing of a colossus like Google.

Guess they're really pushing for moving the pythonistas over to something a good bit faster and reliable while putting a really high emphasis on ease of learning?

Still, whatever, if its going to be a thing and be popular it might as well get better so good news on the release!

[jatone]

In fact, all of the features in the language were language theories that were developed back in the 1960s and prior.

old doesn't make the features go choose bad, hell most of the modern AI stuff is from the 60s and 70s. they chose the feature that worked well together. the point of go wasn't to advance programming language design. It was to make developing complex software on a team less painful. for me it hits the sweet spot between painless development and performance.

I commonly find many use cases for generics in my every day programming that significantly reduces the amount of work I need to do to develop a solution, and presents a final solution which is leaner & more manageable than the equivalent Go solution

I suspect you're one of those programmers who overuse generics. interfaces in go replace majority of the usecases for generics. and code generation fixes the rest if you truly need the performance, or safety of the typed implementation of some container class.

It's therefore no wonder that Rust & C are easily 3 times faster than Go.

if performance was the only thing that mattered then we'd never have had the crap shoots that are python, ruby, node, etc.

Go's GC is 'low latency' ... because the garbage collector consumes insane amounts of CPU as it constantly polls multiple threads for memory to free.

wow so much is wrong here. first the most egregious: it doesn't poll to free memory. if you don't allocate you won't GC, just like any other language. manual or automatic GC.

secondly the GC in go makes a simple tradeoff: predictable latency is more important than throughput. This tradeoff makes it extremely easy to write applications that perform consistently and are easily horizontally scaled. compare this with java (prior to the latest GC implementation) where GC's took 30+ seconds on large heaps which is completely unacceptable. meanly end users randomly suffer these massive delays to a request with no real way of fixing the underlying issue. go avoids this problem entirely.

finally: if GC is really hurting your performance, you can avoid it just like any other langauge using slab allocation and buffer pools.

Go just feels really uninspired to me.

depends what you consider inspirational. if new fancy language theories gets you hot and bothered then, yes very uninspired.
its a well engineered language with upfront design decisions that were clearly communicated.
core inspirational ideas in golang:

• latency over throughput, easier to predict scaling requirements.
• optimize the language for reading the code. programmers spend far more time read than writing. no fucking surprises.
• compile -> test -> refactor loop is super optimized. its faster than dynamic languages even on large projects. (latest release is going to make this even better)
• fucking gofmt. brilliant.
• make it easy to build tools for the language. go has some of the best linters, refactoring, and code generation tools I've seen in any language.

Guess they're really pushing for moving the pythonistas over to something a good bit faster and reliable?

which is a good thing. =)

[atomsymbol]

interfaces in go replace majority of the usecases for generics. and code generation fixes the rest if you truly need the performance, or safety of the typed implementation of some container class.

A main point of C++ generics is that it acts like code generation built into the C++ programming language so that there is no need to use external code generation tools.

[boxie]

Yea, I really don't get why Go gets the level of interest it does. Other than goroutines I really just don't see what it brings to the table.

Well - apart from the fact that you can pick it up in a week, is easy to get started with and is easy to read/reason about?

It's not innovative, its barely faster than Java most of the time while getting none of the benefits of a JVM base

and? lots of languages are slower than Java (which btw is pretty quick when not running "AbstractEnterpriseFactoryBeanSingleton"'s :P

they've stripped OOP and generic functionality from the language without implementing real alternatives

Go's implementation of Object Oriented Programming is actually closer to the original definition. Duck Typing is awesome - you should check it out. Also - Go has never had generics - so you cannot strip them out.

The problem with Generics is how do they look in the Go scheme. There are some very smart people tackling that problem for Go2

but hey - each to their own - everyone has different tastes and requirements for languages.

There is more than enough CPU cycles to have the language holding the developers hands and making life easier for them.

[boxie]

I've played a little with go, and it's quite nice, but removes too much of the thinking that should be involved in programming, imo.

The question here is, why should I have to think about memory management? What do I gain by manually managing memory? I would rather spend the brain cycles on implementing my business logic rather than stressing over memory leaks.