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

What Golang Is and Is Not

danmux.com

Post reply on HN
Print view View original

31–40 of 279 posts

Re: What Golang Is and Is Not

#31

Post by codygman »

pjmlp wrote: post #8
catnaroek wrote: post #5

Earlier quoted context omitted.

C++, otherwise a deeply flawed language, gives you more abstraction than Go and allows you to optimize and micromanage things more.

Not only C++, there are plenty of options. The only thing good about Go, is being an evolution path for C coders willing to embrace a GC and some type safety.

One thing I can credit Go for is leading me from the untyped world to the typed one. I soon found the holes in the Go type system, and went looking for a stronger type system.

I now generally prefer Haskell.

Re: What Golang Is and Is Not

#32

Post by bluejekyll »

namelezz wrote: post #20
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…

> This is a huge improvement over Java, and something every language should have an option for. I am not sure what improvement you are talking about. Deploying Go apps requires recompiling for the target platform. On JVM, you only need to install the JVM. There are also tools to wrap JVM apps in executable files that will automatically download and install a suitable JVM.

I'm specifically talking about the classpath, jars, separate jvm install. These are a pain to manage across environments.

I'm a longtime Java engineer, it's a great language, but I do think the compile once thing isn't as big an advantage anymore.

With the advent of the LLVM, it's easy to target specific machines. rustup, even makes it possible to build binaries for every target environment you have.

And let's be honest, how many people target more than Linux/x86_64 on the server side? Even if you target FreeBSD or Windows, my bet is that your still generally only targeting one platform.

Btw, Rust has a great std lib that is very portable across all major platforms. https://doc.rust-lang.org/book/getting-started.html

Re: What Golang Is and Is Not

#33

Post by Jtsummers »

knucklesandwich wrote: post #13
catnaroek wrote: post #11

Earlier quoted context omitted.

> Go decided to not have generics, to keep the language easier to learn and more approachable. It's hard to argue with this one. Plain parametric polymorphism is super easy to understand. Standard ML could be learnt in a week by someone who doesn't know how to program. Admittedly, the interaction between parametric polymorphism and subtyping is tricky and subtle. And it seems most programmers have gotten used to taki…

The biggest irony of Go is that they have invariant parametric types for channels, arrays, etc. and indeed primops like channel sends, make, len, etc. are parametric functions. So for all the defensiveness about how parametric polymorphism is "difficult to understand", Go programmers seem to deal just fine with it on a day-to-day basis. What they lack is the ability to let programmers introduce their own parametric t…

If we consider Go in the context of a systems (their definition) engineering language within Google's enterprise, limiting choice is not about how dumb the programmers are, but about ensuring conformity.

Rewriting code is expensive. As my office knows well. We maintain lots of old embedded systems and have to periodically rewrite or rehost it because the old hardware platforms aren't available or aren't performant enough for new features. These become multi-year, multi-million dollar projects, for relatively little gain.

By ensuring that developers and architects conform to certain conventions, it means (in theory) that this code maintenance is much cheaper, and that rewrites can be avoided or minimized. This is a good thing and lets organizations be more flexible and productive, as their time and money is no longer wasted on the old things, but can be spent on the new things.

Re: What Golang Is and Is Not

#34

Post by tinco »

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++ ?

There are many compiled languages with embedded runtimes. Haskell is among the best of them.

Re: What Golang Is and Is Not

#35

Post by erikpukinskis »

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.

In some ways they converge, in some ways not. On some level "nice to look at" means everything conveys some meaning, and nothing is obviously awkward. "Easy to understand" means everything you might need to know is on the screen. Those things are often aligned, but sometimes orthogonal.

Put another way, you can make something that looks simple and pleasing, but hides a lot of complexity that's required to understand in order to be able to do your work.

Re: What Golang Is and Is Not

#36

Post by vvanders »

xyproto wrote: post #30
soulbadguy wrote: post #7

Earlier quoted context omitted.

Golang is only 'near cpu' when compared to python or ruby. Golang is much closer to java/c# then c/c++

Go (the language) have at least two implementations: the official Go implementation and GCC (yes, Go is included in GCC, along with Fortran and Ada). The latest Go implementation (Go 1.7) has made Go a lot faster. I would argue that it closer the speed of executables generated with GCC (gcc/g++) than OpenJDK, the Oracle JVM, Mono or the .NET compiler for C#. Go (the language) can be made just as fast as C (the langua…

Until you have control over stack/heap and data locality you're never going to be able to approach C/C++/Rust speeds.

Conversely if you're using C/C++ through a ton of heap/virtual pointers then you're losing a lot of the value the language brings and should be using something higher level.

Re: What Golang Is and Is Not

#37

Post by iends »

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…

What better language did you settle on?

Re: What Golang Is and Is Not

#38

Post by randomdata »

sergiotapia wrote: post #3

The author is quite correct. Go is super boring, and runs fast. Two great points for it. For me however I just never felt happy writing Go code. I have a couple of open source projects with it, so I have put it through it's initial paces to see if we fit. The language that did make me happy was Elixir. Everything about the language and the surrounding tooling is polished. You end up with significantly less lines of c…

Are those really idiomatic examples though?

For instance, without changing too much, you could implement scrapeProfile like this: https://play.golang.org/p/sP34n9acy7 I think that reads quite nicely, although I'm sure someone else can do even better.

If you modified dumpToCSV to take an interface instead of the concrete type, you wouldn't even have to prepare the user structure. You could pass in the vcard directly.

Re: What Golang Is and Is Not

#39

Post by [deleted] »

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…

[deleted]

Re: What Golang Is and Is Not

#40

Post by iends »

omni wrote: post #12
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…

> There are no guide rails telling you that you forgot to check an error result. This is a runtime thing you need to discover. Is this actually simpler? This may be considered cheating since it isn't baked into the language but there are tools to do this at build time, here's one: https://github.com/kisielk/errcheck

There are lots of tools in Go that make up for issues people have with the language. Another example is the IDE macros people use for the standard if err != nil {} block.
Post reply on HN