What Golang Is and Is Not • Hacker News Board

Re: What Golang Is and Is Not

#131

Post by tinco » Sun, Aug 21, 2016, 8:48 PM UTC

karma_vaccum123 wrote: post #125

tinco wrote: post #57

Earlier quoted context omitted.

How is it dangerous? Your qualifying remarks with regards to Haskell's domain make no sense. If you need a fast, compiled language with managed memory, high ease of development and a strong ecosystem then you can't go wrong with Haskell. 'Type stable computation' and a strong correctness guarantee are some added benefits of Haskell, though any strongly typed language (like for example Rust) will have these qualities.…

Haskell's runtime has one overriding attribute: laziness. If laziness is not desirable in your domain, Haskell is not a useful option

Can you give me an example of a domain where laziness is not desirable? I only do Haskell for side projects, so perhaps I lack exposure to some domains.

Re: What Golang Is and Is Not

#132

Post by RodgerTheGreat » Sun, Aug 21, 2016, 8:52 PM UTC

thatswrong0 wrote: post #44

codygman wrote: post #28

Earlier quoted context omitted.

Go doesn't make real world programming easier. It makes you work hard for pointless things. Most of its problems are from a lack of generics.

Yep. Add those and a proper type system and you have yourself a decent language. But when the creator of the language doesn't see the value in abstractions [0], then it's probably never going to happen. [0] https://github.com/robpike/filter

His formulation of reduce() is strikingly clumsy, both in signature and implementation. I daresay I wouldn't have much use for such a function either!

Most languages which provide a reduce() permit programmers to provide an initial "carry-in" value. This is a neater and more useful way to handle the cases of a zero- or one-element list. Moreover, it lets you do more interesting things with the reduction. Consider the following, using ES6-style JavaScript to collect a set of the unique values of a list via reduce():

    function unique(list) {
    	return list.reduce(function (sofar, item) {
    		if (!sofar.includes(item)) { sofar.push(item); }
    		return sofar;
    	}, []);
    }

Re: What Golang Is and Is Not

#133

Post by Scarbutt » Sun, Aug 21, 2016, 8:53 PM UTC

dominotw wrote: post #18

bluejekyll wrote: post #6

> “There is nothing new under the sun” rings true in all languages since the 80’s. Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go. Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to…

>innovative feature of Go is the small runtime built into the binary making deployment dead simple and easy. Is rust the only good alternative here to golang if you one doesn't want to write c/c++ ?

Definitely Swift,but is not as mature yet as the other options mentioned.

Re: What Golang Is and Is Not

#134

Post by xiaoma » Sun, Aug 21, 2016, 8:56 PM UTC

geodel wrote: post #124

xiaoma wrote: post #116

Earlier quoted context omitted.

Go has been around nearly a decade with the backing of none less than Google and yet it remains a fairly fringe language. Elixir is on a much steeper adoption curve. So is Swift, but Elixir doesn't even have a tech heavyweight behind it.

Go 1.0 is released in March 2012 so it is not even half decade old.

By that logic, Elixir is not even two years old!

Edit: karma_vaccum123 has greatly edited the gp comment but for the record, Google has been using golang since 2007.

Re: What Golang Is and Is Not

#135

Post by f2f » Sun, Aug 21, 2016, 9:06 PM UTC

iends wrote: post #53

bluejekyll wrote: post #43

Earlier quoted context omitted.

Yep, but I think there are others that will fit people's needs as well. Rust suits my needs/wants perfectly.

Rust really impresses me because the community and the ecosystem, but I've not looked at it too much.

nobody has.

Re: What Golang Is and Is Not

#136

Post by seabrookmx » Sun, Aug 21, 2016, 9:07 PM UTC

behnamoh wrote: post #128

I'm not a Golang programmer, but the mere fact that GOOG decided Java for android is convincing enough that even GOOG does not believe in its Go. (Frankly, I doubted that a little, until I realized Al-*-Go was not actually written in Go!)

Android predates Go. And it wasn't even started by Google.. Android was it's own company and had already made it's decision on Java well before Google decided to buy it.

Not to mention Go is focused on a different use case. Go is gunning for microservices (with it's concurrency chops) and CLI based tools (being a single compiled binary).. whereas Android apps are a totally different beast that stands little to gain from either of those. In fact shipping multiple binaries for different architectures is a bit of a detractor for Android considering it supports MIPS, ARM, and x86.

> until I realized Al-*-Go was not actually written in Go!

Again, AlphaGo was based off technology from DeepMind, a company Google acquired.

Please atleast do some quick wikipedia browsing before spewing FUD.

Re: What Golang Is and Is Not

#137

Post by clappski » Sun, Aug 21, 2016, 9:07 PM UTC

IshKebab wrote: post #112

codygman wrote: post #28

Earlier quoted context omitted.

Go doesn't make real world programming easier. It makes you work hard for pointless things. Most of its problems are from a lack of generics.

It may be harder to write some things, but it definitely is easier to read Go code. Besides, while the language itself may be more verbose than it could be, the standard library is extremely pragmatic and terse. It's like the opposite of the standard C++ library. E.g. to see if a string starts with another string in C++: std::mismatch(prefix.begin(), prefix.end(), toCheck.begin()).first == prefix.end() In Go: strings…

In your C++ example you're giving `std::mismatch`, which is a generic algorithm. If you're so inclined you could provide a wrapper that has the same interface as the Go example, but you're comparing apples to oranges. I'd argue that `std::mismatch` is much _more_ pragmatic than the Go example, in that I can use it to check any lists of user defined types.

In reality, these two methods do completely different things. `std::mismatch` is a completely generic algorithm that 'returns the first mismatching pair of elements from two ranges', which can be used for much more than `strings.HasPrefix`.

Re: What Golang Is and Is Not

#138

Post by pcwalton » Sun, Aug 21, 2016, 9:29 PM UTC

geodel wrote: post #127

pcwalton wrote: post #88

Earlier quoted context omitted.

> Not explicit programmer control, but I think you can reasonably make it do what you want. Escape analysis, like any such analysis, gets much more difficult in the presence of higher-order control flow. Currently the Go compilers punt on higher order control flow analysis. And Go uses higher-order control flow in spades, due to its heavy reliance on interfaces. The end result is that lots of stuff is heap allocated.…

> That's not true for Java. Its generational garbage collector performs bump allocation in the nursery, yielding tightly packed objects with excellent cache behavior. Allocation in HotSpot is like 3-5 instructions (really!) When I see this link I get different impression. http://mechanical-sympathy.blogspot.com/2012/10/compact-off-... It is only heavy use of sun.misc.Unsafe and unidiomatic coding style that give Java…

That post's numbers are entirely based a giant multi-gigabyte long-lived array: the classic worst case for a generational GC. That is not representative of most memory allocations. The generational hypothesis, which has been empirically verified in real world code again and again, is that most allocations are short-lived and small.

Re: What Golang Is and Is Not

#139

Post by pcwalton » Sun, Aug 21, 2016, 9:36 PM UTC

IshKebab wrote: post #112

codygman wrote: post #28

Earlier quoted context omitted.

Go doesn't make real world programming easier. It makes you work hard for pointless things. Most of its problems are from a lack of generics.

It may be harder to write some things, but it definitely is easier to read Go code. Besides, while the language itself may be more verbose than it could be, the standard library is extremely pragmatic and terse. It's like the opposite of the standard C++ library. E.g. to see if a string starts with another string in C++: std::mismatch(prefix.begin(), prefix.end(), toCheck.begin()).first == prefix.end() In Go: strings…

> The Go standard library is full of things that do exactly what you want them to, whereas in other languages you have to manually do it yourself.

Sorting a slice is a pretty obvious counterexample.

Re: What Golang Is and Is Not

#140

Post by mixedCase » Sun, Aug 21, 2016, 9:44 PM UTC

themgt wrote: post #15

viach wrote: post #10

Earlier quoted context omitted.

Elixir is nicer to look at, Go is easier to understand.

I find "nice to look at" and "easier to understand" tend to converge over time. Elixir pushes me to expand my mental maps a bit more than Go, but once I grok it the code reads much more coherently and concisely. Go to me reads like an ELI5 programming language.

>I find "nice to look at" and "easier to understand" tend to converge over time. Elixir pushes me to expand my mental maps a bit more than Go, but once I grok it the code reads much more coherently and concisely.

Sounds like something that won't hold up as well over time.