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

91–100 of 207 posts

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

#91

Post by mhd »

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…

I think if you're replacing "Google" with "those Bell Labs guys", you're closer to the truth. A lot of the design decisions are quite familiar if you look at the past work of e.g. Rob Pike.

It's not necessarily all about peak efficiency for specific enterprise applications.

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

#92

Post by _Codemonkeyism »

oweiler wrote: post #70
_Codemonkeyism wrote: post #43

Earlier quoted context omitted.

I like Kotlin too, but in which way is it "much more expressive" in your opinion? What can you express in Kotlin that you can't express in Java? Scalas type system is much more expressive than the one in Java as an example. Only thing that comes to mind in Kotlin is non-nullable references. Most of the stuff in Kotlin looks more like less boiler plate (data classes) than "more expressive".

There are quite a few things in Kotlin which are not possible in Java * Top level declarations * Sealed classes * Coroutines (in Java this is currenty only possible with Bytecode manipulation) * Inlined Functions and Reified Generics * Covariant Collections * Tail Recursion

I do not argue that Kotlin is a nicer and a language with more features that are useful.

What of these would you call "more expressive"? I'd agree with sealed classes, they express a limited set of possible classes. Perhaps tail recursion as I can express problems in way of recursion without stack overflows. I don't think coroutines are more expressive than Futures/get, only a runtime optimization for many concurrent executions.

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

#93

Post by symlinkk »

mkesper wrote: post #48
egeozcan wrote: post #25

Earlier quoted context omitted.

> it's definitely a "Windows First" language C# used to be that but I don't think that's the direction anymore.

Which platform-agnostic GUI toolkit do you use?

Which platform-agnostic GUI toolkit do you use for Go? What about Python?

No language ships a cross-platform GUI toolkit in its standard library.

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

#94

Post by ssijak »

wolco wrote: post #88
hasenj wrote: post #64

Earlier quoted context omitted.

What would you choose instead?

For a website? PHP or Ruby. If you feel you have low level needs move to rust. If you want microservices use node. Go is a compromise of everything.

Those languages that you mentioned compromise on much more than go.

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

#95

Post by yla92 »

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…

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

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

#96

Post by mhd »

pjmlp wrote: post #30
oblio wrote: post #27

Earlier quoted context omitted.

Yeah, but Kotlin Native loses all the Java libraries. The more interesting thing would be Java native compilation coupled with Kotlin. So you'd write a Kotlin Java app and pass that through the Java native compiler introduced in Java 9. Unfortunately that's a beta feature right now, I think it only supports Linux x64, that's why I said Kotlin 2019, I assume that by then the Java native compiler will support all Java…

Java compiles to native code since version 1.0, only not for free. All commercial JDKs had this option in one form or the other, and many of them are still around. If you want to try this for free on open source projects, Excelsior JET is one option.

> Java compiles to native code since version 1.0, only not for free.

Well, there was GCJ, but I think that hurt more than it helped.

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

#97

Post by sidlls »

_Codemonkeyism wrote: post #42
Dowwie wrote: post #39

What I've noticed, and personally experienced, about these porting projects is that they're generally a premature optimization but are a great way to learn a new language. The gains from a port are largely intrinsic in nature, residing with the programmers. However, systems and operations largely carry on just fine with the original language chosen. Only one story comes to mind where a programmer had a legitimate pro…

Developers have the gain, company suffers, developers move on for higher salary with more skills, CTO is in it, doesn't fullfil his duty towards the company or investors, CEO has no clue and doesn't manage the CTO. The story I see over and over again as a startup CEO consultant.

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 engineer just wants to stick "built stuff in X" on his resume. He doesn't have a good reason to not use our existing stack. If I were the manager I'd demand more technical justification.

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

#98

Post by leetrout »

wybiral wrote: post #87
laumars wrote: post #67

Earlier quoted context omitted.

> But if you do a website or webapp, 99% of your code is not using interface{} in it's methods. That's not really true. If you want an SQL database to back your website, then you'll deal with interface{} with Go's sql package. If you want to gzip your output, then you'll use interface{} with your writer. To be fair, I think interface{} gets an almost unfair amount of hate. While it is fscking annoying when passing ar…

> That's not really true. If you want an SQL database to back your website, then you'll deal with interface{} with Go's sql package. True. But for most real world scenarios I only ever use interfaces at the boundaries between APIs and they quickly get asserted into a type after being passed. Conceptually they're a bit like passing marshalled data between APIs in that sense.

> Conceptually they're a bit like passing marshalled data between APIs in that sense.

That's IMHO a great way to think about when it's Good™ to use them. Yes, there are times when you just have to use the empty interface type but it's really not as bad as everyone makes it out to be.

I love Go because it is explicit and because explicit types make everything easier in the long run. I get tired of seeing Go written like Python/Ruby/$otherDynamicLang with overuse of interface{} and/or reflect.

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

#99

Post by 4c2383f5c88e911 »

yla92 wrote: post #95
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…

> 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.

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

#100

Post by laumars »

jerf wrote: post #85
laumars wrote: post #78

Earlier quoted context omitted.

[deleted]

"io.Reader and Writer are interface{}'s[1]." No, they are interfaces , but they are not interface{} s, the interface that is met by having no methods and is therefore met by everything. Nobody is complaining about the use of interfaces that declare a useful set of methods, and are meant to be used when the set of methods is all the target code cares about. They may complain about some of the edges around them (no sup…

[deleted]
Post reply on HN