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

61–70 of 207 posts

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

#61

Post by proto-n »

reacharavindh wrote: post #24
proto-n wrote: post #5

Earlier quoted context omitted.

Coming from a data science background, don't anaconda and environment description files [1] solve this problem with python? Not even sudo is needed to install anaconda and setup / clone environments, also it can manage python versions independently from the system's python. [1] https://conda.io/docs/user-guide/tasks/manage-environments.h...

Thanks for your comment. I have just started using Conda locally to learn before taking it to work. I'm a new sysadmin and my predecessor maintained a restricted list of python packages on all cluster systems like a dictator. I don't want to be one. Does conda cloning the environment mean I can just copy the project directory to another server and expect my program to run without it looking for the packages on the in…

No, the intended way of cloning works by exporting the exact specifications to a text file and re-creating the environment from the text file.

If you use packages from conda channels (which are repositories of packages), then it should work flawlessly. Usually basically everything is available from either the official channel (anaconda) or some community channel (like conda-forge). At least in the data-science domain. I'm not really familiar with the python web-development scene, so not sure about that.

Edit: actually once I had to copy an environment from one machine to another (because of connection problems), and I seem to recall that worked too, but I don't think this method is officially supported.

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

#62

Post by reacharavindh »

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…

Cheers to Nim. I'm learning it in my spare time for fun. However, I will not consider using it for anything more than toy projects until it hits 1.0. Hopefully soon.

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

#63

Post by hasenj »

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…

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 "deoptimization" (if that's a word).

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

#64

Post by hasenj »

fellowmartian wrote: post #46
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…

Using a compiled language is not a premature optimization if you're not sacrificing expressiveness. With that said, Go is not the best choice. Like, for anything.

What would you choose instead?

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

#65

Post by brudgers »

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.

That Go solves some problems for programmers outside Google is a side effect of being a general purpose programming language. It is not a primary business goal except in so far as it raises Google's bottom line, creates a hiring pipeline, and keeps its employee moral off the floor.

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

#66

Post by crdoconnor »

dx034 wrote: post #58
crdoconnor wrote: post #56

Earlier quoted context omitted.

>they're generally a premature optimization This example actually seems to be the opposite of an optimization. There's 50% more code to maintain and there appears to be almost no appreciable benefit to compensate for that.

LOC is a bad measure for the complexity of code. Quite the opposite, expressive code can be faster to understand and easier to maintain than the same functions with half the code size. In any case, switching to a compiled language and static types should bring some benefit, in addition to the gain in speed.

IME 95% of the time SLOC approximates code complexity just fine. Just because you can write horrendous 'clever' one liners in perl does not mean that most code out in the wild is like that. I certainly don't think the same author writing the same app in two different languages will be writing like that.

Zero mention was made of bugs caught or customer-noticeable speed improvements so I'm inclined to think that there was actually no benefit to having static typing.

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

#67

Post by laumars »

zaarn wrote: post #23
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…

>- 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) Depends on what you do. I've written a good chunk of go code and interface{} is the rare exception rather than the rule, usually employed where a user might supply arbitrary types (ie a unmarshaljson like function) But if you do a website or webapp, 99…

> 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 around core types (I hate having to use switch clauses just to inspect the type of an interface{}!!!) I do love how interface{} is used for complex structures. In fact there are a few areas of Go's standard library which I wish used interface{} more in that respect (eg Go's `file` struct should be an interface{} so I can create custom methods for os.Stdin/out/err)

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

#68

Post by crdoconnor »

hasenj wrote: post #63
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…

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…

>Writing in a fast compiled language is not premature optimization.

If the fast compiled language is equally expressive and equally fast to write then no.

Those things are rarely (if ever) the case, though. It's certainly not true in this case. Go appears to be about 30% less expressive.

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

#69

Post by weberc2 »

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 haven't had a problem with testing in Go, but I also don't mock many things. Most things that should be mocked are already interfaces in my code. My biggest grievances with Go are its limited type system and dependency management. Unlike most[^1], I don't need semantic versions--I just need deterministic, reproducible builds, and for that, vendoring is fine in theory, but Go's tooling around it needs work.

I love that Go is a language that can be mastered in a matter of months; that it has such a simple "get up and running" story; that its tools mostly do the right thing by default; and that almost everything is straightforward. In most other languages, I have to figure out what build system to use, how to script it, how to specify and download dependencies, what testing library to use, how to actually run the tests, how (if it's possible at all) to get a static binary, etc--and then I usually have to learn a complex language on top of all of that. For the most part, Go just works out of the box.

I think folks also underappreciate Go's runtime--it has a fast garbage collector and an awesome goroutine scheduler that all get statically compiled into your application binary. Mostly, I want a functional language that compiles to Go so I can still leverage Go's awesome tooling, runtime, and deployment model, but with things like generics and algebraic data types. I've started prototyping it too, and so far it's coming along smoothly (modulo all the things I'm learning about building a programming language). On that note, there is some effort going on in the Go community to build a VM for Go, which would probably make an even more attractive compilation target, at least from a toolchain perspective. Even if my project doesn't take off (and it likely won't), I think this is a low-effort way to address Go's most significant complaints.

[^1]: Well, "most" judging by the significance many of Go's critics place on semantically versioned dependencies

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

#70

Post by oweiler »

_Codemonkeyism wrote: post #43
oweiler wrote: post #26

Earlier quoted context omitted.

Kotlin covers all those features - much simpler than Scala while still being much more expressive than Java - clean syntax, with a higher consistency than e.g. Java - Generics, Higher Order Functions, Multiline-Strings, Destructuring, ADTs, Pattern Matching - Coroutines (experimental but production-ready) - IntelliJ Community Edition (or Ultimate) - not yet but will be possible with Kotlin Native - has its own ecosys…

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

Post reply on HN