Live data from Hacker News

Why Tech Startups Should Look at Go

startupedmonton.tumblr.com

101–110 of 110 posts

Re: Why Tech Startups Should Look at Go

#101

Earlier quoted context omitted.

I find java's ecosystem to be it's biggest drawback. Yes, there are libraries and frameworks available for everything. The drawback is that every simple task, from building to testing to servers is wrapped in so many useless layers of indirection and configuration I just want to tear my eyes out. If you could throw out all the nonsense that has infected java and just build simple things from scratch on the jvm that w…

In the rust example error handling is enforced via the type system whereas with Go it depends on your (and others) discipline.

You're correct. Go doesn't leave it entirely to discipline, since unused (or unhandled) variables are a compiler error. You can silence that error with _, but it sticks out to the eye as broken code.

However I'm not trying to argue that go gives you the same type safety guarantees that rust does, it doesn't.

Re: Why Tech Startups Should Look at Go

#102
post #91
post #48

Earlier quoted context omitted.

An experienced programmer friend of mine uses Go professionally. I was surprised to hear that he much prefers Java: he said that many concurrency libraries are available for Java and that Go's features are quite limited in comparison. He dislikes the fact that you have to break Go's poor type system to get many things (such as tests) to work. He has a pretty strong background in FP, so I think that perhaps Go's inter…

An explanation for downvotes would be appreciated... perhaps "poor type system" was too strong wording, and for that I apologize. But it was surprising to hear his opinion re: concurrency, as from what I understand that's one of the biggest features of Go.

"poor type system" isn't too strong, it's just what it is.

Re: Why Tech Startups Should Look at Go

#103

Earlier quoted context omitted.

In the rust example error handling is enforced via the type system whereas with Go it depends on your (and others) discipline.

You're correct. Go doesn't leave it entirely to discipline, since unused (or unhandled) variables are a compiler error. You can silence that error with _, but it sticks out to the eye as broken code. However I'm not trying to argue that go gives you the same type safety guarantees that rust does, it doesn't.

Thanks, I forgot about the warnings. It's been a while since I've used Go.

Re: Why Tech Startups Should Look at Go

#104
post #36
post #21

Earlier quoted context omitted.

It's the verbosity that I'm talking about. In go I end up with %70 of my code being error handling or error related... with Elixir it's close to %0.01. I'm giving estimates here, of course, but they aren't off by much. With elixir, using try catch is rare, because it should never crash, and when it does, you lose a process and debug it. With go, every line that calls a function needs to check to see if there was an e…

Ok, verbosity I agree. That doesn't have anything to do with being easy or not, I think. I might be wrong. Verbosity can be a pain. Even after reading Rob Pike's article on "Errors are values" [1], I agree with you that the solution is still verbose. Those numbers you gave, even when you said they're estimates, still seems like made up numbers. I've never used Elixir, so if you could point me to an example so I can b…

here is a podcast where they cite error handling stats of C++ vs Erlang.

http://mostlyerlang.com/2014/11/19/049-supervisors/

starting at 28:45 although you might want to listen to the whole podcast

Re: Why Tech Startups Should Look at Go

#105

It's not at all surprising that those startups solved their problems with Go: if you switch from a language that doesn't address your problems to one that does, you're going to see a big benefit. But there are lots of languages that address the problems mentioned by those startups, and I think that Go is possibly the worst of the options. It's telling that none of the startups in question switched out of a language w…

> Go would have a reasonable compile-time type system, except that without > generics you end up having to cast a lot, which renders your compile-time > type system almost irrelevant. In my experience of Go, this is not actually true. For example, in the latest project I've been working on, there are 8487 lines of non-test code. In that code, there are a total of 16 dynamic casts, more than half of which are checked…

How do you deal with container-type classes? The only way I can see to do this without casts is to duplicate the same container class for each contained type, which is fraught with its own problems.

Re: Why Tech Startups Should Look at Go

#106
post #34

Earlier quoted context omitted.

For example, https://www.techempower.com/benchmarks/

Go still beats Java sometimes: https://www.techempower.com/benchmarks/#section=data-r9&hw=i... I'm not saying Go wins more, but they are very close compared to other languages.

I want to point that in fact Go is extremely performant on EC2 for every tests and average on Peak. So with that and all its features, it seems that Go is an awesome solution for startups.

And then Java when you start to be quite big.

Re: Why Tech Startups Should Look at Go

#107

Earlier quoted context omitted.

You're correct. Go doesn't leave it entirely to discipline, since unused (or unhandled) variables are a compiler error. You can silence that error with _, but it sticks out to the eye as broken code. However I'm not trying to argue that go gives you the same type safety guarantees that rust does, it doesn't.

Thanks, I forgot about the warnings. It's been a while since I've used Go.

Its not a warning, its a "will not compile" :)

Re: Why Tech Startups Should Look at Go

#109

Earlier quoted context omitted.

Its not a warning, its a "will not compile" :)

Isn't the technical term "error"?

I suppose the technical term would be "fatal error". I was just clarifying it was a warning since C compilers, for example, will happily spit out many warnings and then hand you binary-

Re: Why Tech Startups Should Look at Go

#110

Earlier quoted context omitted.

Isn't the technical term "error"?

I suppose the technical term would be "fatal error". I was just clarifying it was a warning since C compilers, for example, will happily spit out many warnings and then hand you binary-

Yeah, it's a worthwhile clarification. Of course, the distinction is less hard than it might be, given that a lot of us build with -Werror.
Post reply on HN