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

191–200 of 207 posts

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

#191

Post by lmm »

hasenj wrote: post #182
lmm wrote: post #111

Earlier quoted context omitted.

No-one goes out of their way to choose a slower language. People who choose to write something in Python are getting value out of it, or at least believe they are; if writing the program in Go will be more costly (in development time, defect rate, library availability or something else) than writing it in Python then writing it in Go is premature optimization, and if writing it in Go wouldn't be more costly than writ…

> No-one goes out of their way to choose a slower language. > (...) > why were you thinking of writing it in Python at all? They simply have no awareness of how slow it is, or how important performance is. > IME thinking about language performance at all is premature optimization Are you serious? Python code is about 10 times slower than equivalent code in Go.

> Are you serious? Python code is about 10 times slower than equivalent code in Go.

And 98% of the time it doesn't matter. For most business problems that you'd want to solve with a computer, for modern hardware, Python's performance is more than adequate. It's really not worth worrying about.

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

#192

Post by _Codemonkeyism »

calcifer wrote: post #176
oweiler wrote: post #70

Earlier quoted context omitted.

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

> Reified Generics It's implemented with some bytecode hackery and hence limited to inlined functions [0], which makes it significantly less useful. Funny how a misguided design decision from the Java 1.5 days (running generic 1.6 code with a 1.5 jre) still haunts us today... [0] https://kotlinlang.org/docs/reference/inline-functions.html#...

See "Brian Goetz - Stewardship: the Sobering Parts" https://www.youtube.com/watch?v=2y5Pv4yN0b0&t=3399s

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

#193

Post by hasenj »

lmm wrote: post #191
hasenj wrote: post #182

Earlier quoted context omitted.

> No-one goes out of their way to choose a slower language. > (...) > why were you thinking of writing it in Python at all? They simply have no awareness of how slow it is, or how important performance is. > IME thinking about language performance at all is premature optimization Are you serious? Python code is about 10 times slower than equivalent code in Go.

> Are you serious? Python code is about 10 times slower than equivalent code in Go. And 98% of the time it doesn't matter. For most business problems that you'd want to solve with a computer, for modern hardware, Python's performance is more than adequate. It's really not worth worrying about.

No. This is only true if you have a script you run once an hour or so.

If you have a server side application that you hope to be successful then the code will be running all the time and you will pay the price literally because cloud hosting services charge for CPU and RAM usage, which will be off the charts if your server is in Python.

Not to mention all the time you will spend firefighting the performance issues that will inevitably arise. Which also literally costs money in terms of developer salaries and opportunity cost (you can't spend that time to develop new features).

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

#194

Post by boomlinde »

erik_seaberg wrote: post #162
boomlinde wrote: post #86

Earlier quoted context omitted.

Another way to look at it is that Go expresses additional things that you can't express with Python.

In Go it's impossible to make for...range support user-defined types, and you have to write out every loop the hard way (and rewrite any loop that was using a builtin type). In Python you just define __iter__. That's what's meant by expressive, you can write what you mean instead of having to explain yet again how it should be implemented.

Of course they're different on that level of detail. In go, if you want programmable iteration behavior, you would create a channel that is fed values by a coroutine. Then you can range over it. It's not a new type, but that distinction seems a bit picky.

What I am talking about is the static type system. You can't express that in Python, despite how much more convenient some of its features are.

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

#195

Post by 4c2383f5c88e911 »

olalonde wrote: post #161
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…

Your criticism would have been a lot better if you had pointed to an alternative.

Why? I'm not saying go is a bad language at all, it has a lot of good points, as outlined in the source of this discussion. It is however not a perfect language and as such, it never hurts to criticize it, if only in the hope that it will improve in the future. I personally find the mental model required for go quite abrasive, but that's only me, and I won't hold it as valid criticism.

The alternatives vary according to the issue you want to tackle, so I would be hard pressed to recommend a particular one. And go does fill some vacant spots in language space.

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

#196

Post by randomdata »

Daishiman wrote: post #186
randomdata wrote: post #133

Earlier quoted context omitted.

- Go's opinion about generics has always been that it should have them, but finding the right expertise to implement them in a non-ridiculous way has been a struggle. They are marked for inclusion in coming versions (2.0). - error is an interface. If you are returning strings most of the time, you're probably doing it wrong. - Wasn't gofmt originally executed during compile time? I'm not sure why it changed, but it s…

> Go's opinion about generics has always been that it should have them, but finding the right expertise to implement them in a non-ridiculous way has been a struggle. They are marked for inclusion in coming versions (2.0). The fact that people can claim that C#, Java, Scala, Kotlin, Haskell, Rust, Swift have "ridiculous" implementations of generics sounds like a very bad excuse.

Is anyone claiming that?

The Go team has, until recently, been quite open about not being confident enough in their own abilities to implement it well in Go. Maybe to the point of absurdity, but they were explicitly warned by designers of other popular languages (specifically some of those on your list, I believe) to not be cavalier in how they add generics.

That doesn't mean nobody on earth can implement generics well. I'm sure if someone from the C#, Java, Scala, etc. teams, with the necessary expertise, wanted to step in and contribute generics for Go, it would have been a welcome addition. At very least for the community who would have jumped all over a fork with generics. However, I do not see that code anywhere. You cannot force people to do things they do not willingly want to do.

Now that the Go team has had enough time to put for the effort to learn more about generics and the research related to them, they feel more confident about being able to add them in a somewhat reasonable way and have officially announced that they will be added in the near-ish future.

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

#197

Post by nspattak »

_Codemonkeyism wrote: post #49
nspattak wrote: post #47

Earlier quoted context omitted.

So if I get your argument correctly: Developers learn a new language that is faster to develop, safer and faster to run than existing solutions (which work but are of increased technical debt) and successfully & quickly port the existing solution to the new tool. The company doesn't really benefit from it apparently because they never scale enough or because they lacked a target so they had their developers working o…

"Developers learn a new language that is faster to develop, safer and faster to run than existing solutions" Most often only in the eye of the developers with no proper evaluation. "Furthermore, shouldn't the CEOs and the CTOs know better and to a better job?" Yes.

Well, the "in the eye of ... with no proper evaluation" argument can be had for a lot of other aspects of software development and product management, doesn't it?

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

#198

Post by nspattak »

acdha wrote: post #79
nspattak wrote: post #47

Earlier quoted context omitted.

So if I get your argument correctly: Developers learn a new language that is faster to develop, safer and faster to run than existing solutions (which work but are of increased technical debt) and successfully & quickly port the existing solution to the new tool. The company doesn't really benefit from it apparently because they never scale enough or because they lacked a target so they had their developers working o…

> Developers learn a new language that is faster to develop, safer and faster to run than existing solutions Would that it was that simple. Most of the time I've seen this it's been more like “writing new code is fun, fixing a bad design in our current code is too much like work” without factoring in the cost of rewriting, testing, optimizing all of the code which wasn't a problem relative to simply replacing the hot…

I understand the situations you are describing and I still have the impression that the main problem behind this is inadequate leadership (and probably at several layers...).

There are more than enough Real Programmers or lacking soft eng who are not experienced or knowledgeable enough to know when to use C/python/go/sql/etc but again for me the problem is either whover hired them and whoever is managing them.

I also more than agree with the last sentence.

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

#199

Post by Can_Not »

beagle3 wrote: post #28
oblio wrote: post #7

Earlier quoted context omitted.

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…

Nim has everything nailed down except the ecosystem/commercial backing; It does have some of those, but not to the extent that I would blindly tell you they are there. It's as fun as writing Python (with a similar syntax), but it has essentially all the goodies you want from Lisp when you need them, runs as fast as equally optimized C, produces standalone native binaries, _or_ standalone JavaScript if that's your thi…

Does Nim have a good story for borrowing c/c++ ecosystems?

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

#200

Post by beagle3 »

Can_Not wrote: post #199
beagle3 wrote: post #28

Earlier quoted context omitted.

Nim has everything nailed down except the ecosystem/commercial backing; It does have some of those, but not to the extent that I would blindly tell you they are there. It's as fun as writing Python (with a similar syntax), but it has essentially all the goodies you want from Lisp when you need them, runs as fast as equally optimized C, produces standalone native binaries, _or_ standalone JavaScript if that's your thi…

Does Nim have a good story for borrowing c/c++ ecosystems?

Yes. The most common compilation path is through C or C++, which together with the source-based FFI makes the integration mostly seamless.

There’s also c2nim which will generate the bindings for you (though it might need some hand holding if the header files make extreme use of macros)

Post reply on HN