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

Learning Go by porting a medium-sized web back end from Python

benhoyt.com

Post reply on HN
Print view View original

141–150 of 207 posts

Re: Learning Go by porting a medium-sized web back end from Python

#141

Post by sidlls »

criddell wrote: post #127
sidlls wrote: post #97

Earlier quoted context omitted.

Hell, I've seen this as a lead/senior engineer. I'm seeing it right now, in fact, as a person on our team wants to write some stuff in language X, which nobody else on the team has experience with, and which isn't used anywhere else in the company, and to solve a problem that is perfectly well solved (in both development time and performance) with the language and tooling we already use. As far as I can tell this eng…

I'm a senior engineer and I'm also the person that wants to use the shiny new thing. I'm just learning Go and I'm itching to find a project to use it on. It's super hard to justify it though when C# or Python would work just as well and those are languages that we already use.

The best time to do it is on a new project or component of an existing system, in my opinion. It doesn't make it a good idea, but it can be a nice way to introduce something new and possibly more productive.

Re: Learning Go by porting a medium-sized web back end from Python

#142

Post by rjammala »

joshuamorton wrote: post #134
rjammala wrote: post #80

Earlier quoted context omitted.

How about this: once you write code in Go and test it well, you can deploy it and forget about it unless there is a hardware issue? I recently ported some C++ code to Go which processes 8 Billion events per day flawlessly.

I feel like this is true for any language though. Once you write a well designed, well tested, and feature complete piece of software, you can deploy it and forget about it unless the server it's running on breaks. Go isn't special in that regard, unless there's something that makes Go easier to write, test, or deploy, which might be the case, but you haven't supported that.

Our team was able to develop/deploy about 20 Microservices in Go in the past year or so which is really awesome. I can say this after having worked with several other languages.

Re: Learning Go by porting a medium-sized web back end from Python

#143

Post by weberc2 »

4c2383f5c88e911 wrote: post #99
yla92 wrote: post #95

Earlier quoted context omitted.

> gofmt is a good idea (just like clang-format or yapf), and having it is great, but the maintainers specifically refuse to add simple features, saying "running it in an automated process is not supported", despite all github projects already having it in their automated CI suite A Golang noob here. Can you (or anyone else) expand more on this? Are there any links that I can read more about this?

Actually, the mistake is mine, I meant to write golint (but too late to edit). I have no issue with gofmt. As for golint, https://github.com/golang/lint/pull/100 is the kind of thing I'm thinking about.

The Go team aren't the most respectful, but I think Dsymonds is uncharacteristically rude. Most of my experiences with the rest of the Go team have ranged from "sorta terse, but I'll give the benefit of the doubt" to very positive.

Re: Learning Go by porting a medium-sized web back end from Python

#144

Post by hajile »

Double_a_92 wrote: post #50
masklinn wrote: post #14

Earlier quoted context omitted.

OCaml seems to match a majority of the criteria, though AFAIK no "good IDE" (tooling like merlin is available, but if you're looking for e.g. a refactoring IDE you're probably SOL), the ecosystem is small, and it does have some historical baggage.

> - clean (nice syntax ...) Just looked at wikipedia examples and the code is full of special chars and shortened keywords. Doesn't look nice or simple to me, tbh.

SML is what Ocaml should have been. With a few small syntactic changes (mostly to add some nice-to-have features), SML syntax would be better in every way instead of almost every way.

Re: Learning Go by porting a medium-sized web back end from Python

#145

Post by hajile »

oblio wrote: post #7
trumpeta wrote: post #3

Recently I have had the opportunity to write a microservice in Go. It was a very refreshing experience switching from Scala. Go is a lot faster to compile and runs with a far smaller footprint. The channels are nice. On the other hand the testing feels wrong because its so annoying to do mocks. And don't even get me started on the dependency management. Overall Go feels to me like some version compiled PHP with bette…

I really wish that there was a language which had these features: - simple (so not Scala, Haskell, Perl 6, etc.; no Rust either, unfortunately) - clean (nice syntax, preferably Python inspired, but consistent) - modern (generics, some functional features, string interpolation, etc.) - decent concurrency/parallelism story - good IDE, preferably supported by the core dev team - compilation to a (possibly static) native…

I think F# has the things you're looking for.

Re: Learning Go by porting a medium-sized web back end from Python

#146

Post by TheAceOfHearts »

Double_a_92 wrote: post #50
masklinn wrote: post #14

Earlier quoted context omitted.

OCaml seems to match a majority of the criteria, though AFAIK no "good IDE" (tooling like merlin is available, but if you're looking for e.g. a refactoring IDE you're probably SOL), the ecosystem is small, and it does have some historical baggage.

> - clean (nice syntax ...) Just looked at wikipedia examples and the code is full of special chars and shortened keywords. Doesn't look nice or simple to me, tbh.

As another commenter mentioned, you might want to try out Reason [0]. It's a new-ish programming language from Facebook that uses OCaml as its backend.

[0] https://reasonml.github.io

Re: Learning Go by porting a medium-sized web back end from Python

#147

Post by Danihan »

didibus wrote: post #126
hasenj wrote: post #63

Earlier quoted context omitted.

Writing in a fast compiled language is not premature optimization. Premature optimization would be something that makes the code more complicated and more difficult to follow but produce better performance. Writing the same code in a fast compiled language is just the default thing that you should be doing when you are not doing premature optimization. Writing in a slow interpreted language is more like premature "de…

I don't follow this logic. Why not use C all the time by default then?

A lot of people do..

Re: Learning Go by porting a medium-sized web back end from Python

#148

Post by [deleted] »

brudgers wrote: post #65
4c2383f5c88e911 wrote: post #21

I can agree with most of the article, but for some it looks like we have not been using the same language ecosystem at all. Go really feels opinionated around the wrong things, in order to claim "simplicity" as a feature: - No generics just mean you're going to be handing interface{} all the way in your stack, it makes things more complex and less readable for no reason (and less safe) - error handling which is essen…

The opinions expressed in Go are solely those of Google about the productivity of Google programmers. Nothing else is driving design. It is by Google employees for Google employees. Making it widely available and open source is a strategy for extracting value in the form of bug reports and patches and Google friendly upgrades from a world wide community for the price of a few conference talks and some sticker swag. T…

[deleted]

Re: Learning Go by porting a medium-sized web back end from Python

#150

Post by [deleted] »

sethammons wrote: post #71
trumpeta wrote: post #3

Recently I have had the opportunity to write a microservice in Go. It was a very refreshing experience switching from Scala. Go is a lot faster to compile and runs with a far smaller footprint. The channels are nice. On the other hand the testing feels wrong because its so annoying to do mocks. And don't even get me started on the dependency management. Overall Go feels to me like some version compiled PHP with bette…

Chances are, if you are using mocks in Go, you are doing it wrong. Functions should take interfaces (not interface{}, but interfaces that list methods) and return structs. In your tests, you create a fake that meets the interface and pass that to your function under test. If you have to test file io or DB interaction, you can either do the adapter pattern or, as I prefer, just actually use the filesystem and DB but w…

[deleted]
Post reply on HN