Live data from Hacker News

Program your next server in Go

talks.golang.org

141–150 of 384 posts

Re: Program your next server in Go

#141

Earlier quoted context omitted.

> There is no universal best language nor there will ever be the one. I never made that claim, I just emphasized the widely accepted fact that having types is better than not having them. To a Java developer, Go feels like the Java of ten years ago in that respect, so you will encounter some justified push back. > Right tool for the job is a better flexible mindset Of course, but not all tools are equal. In programmi…

javascript and python would disagree with you.

A lot of people are perfectly happy if Javascript and Python disagree with them.

Re: Program your next server in Go

#142

Earlier quoted context omitted.

> you have to first unlearn your existing ways of thinking and then you will have a place for it. Unlearning is not always acceptable, especially when you have to unlearn sound and proven practices, which Go often requires to do. I think it really depends where you're coming from: people coming from dynamically typed languages like Python and Ruby are quite happy with Go since it's a small ramp up on the type ladder,…

The good programmers I know are not attached to their tools. They prefer to use the right tool for the job. Many other programmers want to solve the problems using tools they know. There is nothing wrong with that. A company with good programmers who could do similar things more efficiently will add to competitive advantage.

Again, we all agree about the motto.

If you need to screw something and you have a choice between

1. A screwdriver

2. Electric drill A

3. Electric drill B

you will certainly look funny at someone considering the screwdriver over the alternatives.

Someone who automatically narrows this choice between the two electric drills is not "attached to their tools", as you say. They are just picking the better tool.

Re: Program your next server in Go

#143

Earlier quoted context omitted.

That's odd. I think the absence of generics in Go is a reasonable answer for a JVM developer to justify they are not interested. No need to go petty.

This feeds into language supremacy mindset. There is no universal best language nor there will ever be the one. Right tool for the job is a better flexible mindset. If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers.

> If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers.

That's a flawed analogy. Here is a better one:

If you need to drill something, do you consider a screwdriver and an electric drill equally?

Re: Program your next server in Go

#144

I love Go. It has become the default Go-To (pun intended) language for me for almost anything that needs to be small and portable. However, I don't see myself writing a full server with it, I would still prefer a dynamic language like Ruby/Python for that and use Go for micro-services CLIs and the rest. For example: Our main application is Rails, it communicates with SOLR as the search index, in between the applicati…

Go type rigidity makes Go code tedious to write. Instead of thinking "How can we solve that problem" developers writing Go end up thinking "How can we make the problem fit Go type system". I'm not even talking about concurrency here, I'm talking about Types. Saying otherwise would be dishonest, unless one has never used anything but C... Anybody who doesn't believe me just has to look the reflect package. Reflection…

I've been writing Go daily for almost two years now and outside of wishing for generics a few times I've never struggled to fit a solution into the type system. I've certainly never considered going back to a duck typed language like Python or Ruby. Not once. Not ever. We have slowly replaced even our glue scripts that are written in Python with Go versions because maintenance and understandability trump any perceived speed advantage of writing something in Python.

Re: Program your next server in Go

#145

Earlier quoted context omitted.

> There is no universal best language nor there will ever be the one. I never made that claim, I just emphasized the widely accepted fact that having types is better than not having them. To a Java developer, Go feels like the Java of ten years ago in that respect, so you will encounter some justified push back. > Right tool for the job is a better flexible mindset Of course, but not all tools are equal. In programmi…

javascript and python would disagree with you.

Parent's claim:

  Of course, but not all tools are equal. In programming
  languages, languages that have a static type system have
  an insurmountable advantage of dynamically typed ones. 
Your response:

  javascript and python would disagree with you.
My question:

  How so?
Since the claim is about the advantages of static type systems, I'll respond on that claim alone. The primary advantage of static type systems, particularly expressive ones, but even of less expressive ones like C, is that a large class of errors can never occur in run-time code. You cannot, possibly, without deliberate effort to defeat the type checker do the following in a statically typed language without at least a compile time warning (to permit C and its weak type system and occasional implicit casting):

Define a function in your language of type: int -> int -> int [or (int, int) -> int]. Pass in something that is not an int to either parameter.

Python will happily accept this code:

  def add(a,b):
    a + b
  ... some context
    add("aoeu", 3)
And not tell you until that add call occurs. A run-time error. Could be very infrequent, which makes it really hard to reproduce.

In C:

  int add(int a, int b) {
    return a+b;
  }
  ... some context
    add("aoeu",3);
the add call won't even make it past the compiler.

JavaScript is even worse: You won't get an error at all!

  function add(a,b) { return a + b; }
  ... some context
    add("aoeu",3) // results in "aoeu3" as the return!
Dynamic and weak typing!

This doesn't mean python and javascript are bad. But it does mean they possess disadvantages relative to statically typed languages. Their type systems mean that significant testing has to be put in to verify/validate your program for guarantees that are baked into statically typed languages (caveat for implicit conversions of certain types, again, in languages like C, but this usually gets at least a warning if not an error).

Re: Program your next server in Go

#146
post #41

I once tried to convince an enterprise java developer to give golang a try. The guy passionately hated it and the reasons were very very petty. The other younger engineers who did not have prior bias loved golang and they were productive so fast. The person truly had a java supremacy attitude that was very difficult to deal with. Golang is a kind of shift in thinking that you have to first unlearn your existing ways…

IMO switching an enterprise developer from language such as Java to Go is like asking someone who has very developed vocabulary in English to try Toki Pona[1].

Yes, it is simple, and you can learn it fast, you also can also communicate with it, but you will often have to fight with the language to express what you want. That person generally won't be satisfied.

Go's shortcomings wouldn't be so bad if in exchange, the language would ensure that your code is less prone to errors, but that doesn't seem to be true. In fact Go programs from my experience appear to be slightly below average in terms of stability and robustness compared to other statically typed languages.

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

Re: Program your next server in Go

#148
post #31

I'd love to see Nim on this diagram: https://talks.golang.org/2016/applicative.slide#13 - it could be close to the top right corner.

The whole axis is so subjective. It really depends what you are working on. For certain tasks you can even find C more fun than other languages.

I think what they were trying to show is whether languages are high or low level (i.e. how far are they from machine code). In C for example every statement (maybe except switch) you can guess what assembly code it would translate to. Not so much with languages on top.

Re: Program your next server in Go

#149

Earlier quoted context omitted.

javascript and python would disagree with you.

Parent's claim: Of course, but not all tools are equal. In programming languages, languages that have a static type system have an insurmountable advantage of dynamically typed ones. Your response: javascript and python would disagree with you. My question: How so? Since the claim is about the advantages of static type systems, I'll respond on that claim alone. The primary advantage of static type systems, particular…

"insurmountable advantage" - I don't think so.

the simplicity that javascript and python provides is an enormous advantage to many kinds of projects.

Re: Program your next server in Go

#150
post #20
post #13

What are some cases where I would choose to write a server in Go instead of in Erlang?

When you want to hire developers.

> When you want to hire developers.

When you want to hire good developers pick Erlang, Elixir, Rust, Haskell, ML, LISP. Because chances they went out of their way to learn the language as it is not taught in US universities in depth. They are probably curious, good learners and could probably learn or adapt to other new things thrown at them.

I am at shop were we use Erlang and syntax has not phased new people that much. If typing . instead of ; is a big deal, then what are they doing to do when a netsplit hits or they have to understand other concurrency issues.

I don't know, I find Erlang's syntax rather nice, if anything it tells my brain "this is not C anymore, don't think like C". Works for me, any way.

There is Elixir of course if syntax is an issue. Elixir has other useful features as well but still runs on the same battle proven platform.

Post reply on HN