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

51–60 of 279 posts

Re: What Golang Is and Is Not

#51

Post by piotrkubisa »

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…

> You end up with significantly less lines of code that's easy to understand.

That is very interesting claim, but there is something more than just tooling and number of lines of codes - a paradigm. Elixir is a functional [1] but Go is imperative [2] programming language. It changes a point in discussion quite a lot, especially when you say 'code is easy to understand'. Personally I prefer Elm over JavaScript/React, because it is 'easier and simplier', but I remember a situation in college when after C#-course we had introduced Prolog and F# and many of newbies found functional programming very difficult... But maybe it is matter of taste.

> Everything about the language and the surrounding tooling is polished.

I don't have strong Elixir experience, but playing with Phoenix framework made me really happy to see how many packages are well documented to create backend for web application. But is almost perfect, almost - because it is not Go.

Go is way more performant (Elixir have results comparable to Python or PHP[3]), has great virtual file system [4], auto generating docs (godoc), gofmt, gorename, golint, gocode (no matter which editor you use - VSCode, SublimeText, Vim you have great autocompletion) and a lot of other things (i.e. examples) which makes learning Go easy for newcomers (i.e. devs who are bored of PHP).

[1]: https://en.wikipedia.org/wiki/Functional_programming

[2]: https://en.wikipedia.org/wiki/Imperative_programming

[3]: https://www.techempower.com/benchmarks/#section=data-r12&hw=...

[4]: https://godoc.org/golang.org/x/tools/godoc/vfs

Re: What Golang Is and Is Not

#52

Post by catnaroek »

Jtsummers wrote: post #33
knucklesandwich wrote: post #13

Earlier quoted context omitted.

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 en…

> By ensuring that developers and architects conform to certain conventions

Enforcing conventions is of course a good thing! The problem is how Go enforces conventions:

(0) When Go enforces a convention mechanically, it's a triviality that can be adequately handled by external tools (e.g., naming, formatting, unused variables, etc.).

(1) When a convention is actually useful (e.g., the correct way of using an interface), Go's type system is too dumb to understand it, let alone enforce it.

> aren't performant enough for new features

Second-class parametric polymorphism (“generics”) is purely a compile-time feature. It can be completely eliminated (that is, turned into the non-generic code you would've written otherwise) using a program transformation called “monomorphization”, before any target machine code is generated. So there's no runtime price to be paid.

Re: What Golang Is and Is Not

#53

Post by iends »

bluejekyll wrote: post #43
zatkin wrote: post #42

Earlier quoted context omitted.

Probably Rust.

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.

Re: What Golang Is and Is Not

#54

Post by bluejekyll »

namelezz wrote: post #41
bluejekyll wrote: post #32

Earlier quoted context omitted.

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 hon…

> I'm specifically talking about the classpath, jars, separate jvm install. These are a pain to manage across environments. I agree with the classpath issue and hopefully it will be fix in Java 9. Separate jvm install? Why? JVM is backwards compatibility. > And let's be honest, how many people target more than Linux/x86_64 on the server side. Those that develop non server apps since Java is a general-purpose language…

Yes. I'm serverside generally.

The JVM is, but sometimes there are things that require specific bug fixes in the GC for example where it's just a big issue combining the jars with the JVM etc.

My only put is that a single thing to deploy is easier than multiple.

Re: What Golang Is and Is Not

#55

Post by skybrian »

spriggan3 wrote: post #49
iends wrote: post #40

Earlier quoted context omitted.

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.

> Another example is the IDE macros people use for the standard if err != nil {} block Which doesn't make code easy to read when there are 10th of these blocks in a single function.

It may be 4 lines of code where 1 or 2 would do, but I don't find it hard to read.

Re: What Golang Is and Is Not

#56

Post by vvanders »

dilap wrote: post #48
vvanders wrote: post #36

Earlier quoted context omitted.

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.

Go allocates on the heap unless it can prove something doesn't escape, in which case it's on the stack. Not explicit programmer control, but I think you can reasonably make it do what you want. Because it exposes pointers as a first-class concept, you also have good control of how data is laid out in memory (=> locality). It's not like Python or Java where everything is a pointer and gets spread out all over memory.

Can you do an arena allocator in Go with disparate types? If not then you're really missing out on data locality.

In also not a huge fan of a compiler "automatically" performing escape analysis. Makes a single change causing cascading perf problems very easy and hard to catch.

Re: What Golang Is and Is Not

#57

Post by tinco »

soulbadguy wrote: post #46
tinco wrote: post #34

Earlier quoted context omitted.

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

> haskell is among the best of them There is little need for this kind of absolutism. Citing a haskell as one the best language in a contest where op ask about rust and c++ is dangerous. To op : if your domain calls for modeling relatively 'type stable computation', and need strong correctness garanty, haskell is a great match.

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.

A nice benefit of Haskell that most other languages don't have is that it is explicit about side effects which gives you some extra confidence in the behaviors of your code. Related to this is its unusually powerful type system, which allows you to make some abstractions for generic code that are not possible in most other languages.

Re: What Golang Is and Is Not

#58

Post by snaky »

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…

> The latest Go implementation (Go 1.7) has made Go a lot faster

After previous implementation has made Go a lot slower.

Re: What Golang Is and Is Not

#59

Post by skybrian »

codygman wrote: post #24

As someone who writes Go every day for work, I can't agree that Go is simple. Using a language for analytics without generics can be quite painful and error prone. Go is a language that pushes remembering corner cases and failure conditions onto the programmer rather than the language and runtime itself. When you already have to remember a myriad of corner cases for business logic, also remembering so many corner cas…

Having tried to use Go for analytics, I agree that it's not a good fit for that use case. (It does work well for scripts and simple servers, though.)

Re: What Golang Is and Is Not

#60

Post by iamd3vil »

piotrkubisa wrote: post #51
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…

> You end up with significantly less lines of code that's easy to understand. That is very interesting claim, but there is something more than just tooling and number of lines of codes - a paradigm. Elixir is a functional [1] but Go is imperative [2] programming language. It changes a point in discussion quite a lot, especially when you say 'code is easy to understand'. Personally I prefer Elm over JavaScript/React,…

Go has more performance if there is some number crunching work but if it comes to APIs or web applications, I don't think so. That techempower benchmark for Phoenix is seriously flawed [3]. We use Elixir in production and according to our benchmarks, the performance is very close to Go or sometimes even better. We also use Plug (which is used by Phoenix underneath) directly if it is just a small API. These benchmarks relates more to our experience. [1] [2]

1. https://github.com/mroth/phoenix-showdown/blob/master/RESULT...

2. https://gist.github.com/omnibs/e5e72b31e6bd25caf39a

3. https://groups.google.com/d/msg/phoenix-talk/hljH55fsqqw/eFX...

Post reply on HN