Live data from Hacker News

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

benhoyt.com

111–120 of 207 posts

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

#111
post #63
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…

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 writing it in Python then why were you thinking of writing it in Python at all?

IME thinking about language performance at all is premature optimization; language performance almost never makes the difference, other between-language differences will swamp any gains from language performance.

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

#112
post #64

Earlier quoted context omitted.

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?

The most general answer is OCaml, though in practice I'd probably use something else depending on the details. For most cases there's a better pick than OCaml, but I don't think OCaml is ever a worse choice than Go.

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

#113
post #48

Earlier quoted context omitted.

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.

TCL comes with TK, Python comes with PyTk, Java comes with JavaFX...

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

#114
post #70

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

>Tail Recursion

Interesting. I thought the lack of proper tail recursion is a JVM limitation. Hence why Clojure uses loop/recur to handle it by translating it to a loop rather then as an actual tail call. Which means things like mutually recursive functions are not possible in Clojure without blowing the stack.

How does Kotlin handle that? Is it internally rewriting to a loop or trampoline, or did they find some way to actually make proper tail calls?

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

#115
post #78

Earlier quoted context omitted.

[deleted]

>io.Reader and Writer are interface{}'s[1]. With this statement, you've shown you have close to 0 Go experience. * interace{} - a place-holder for a value of "any type". It means "a value that satisfies the empty interface", i.e. an interface with no methods. All types implement it. To do anything with the actual data it encapsulates, you have to do a type assertion to unbox the value. The type assertion will panic o…

> With this statement, you've shown you have close to 0 Go experience.

With that statement you've shown yourself to be an arrogant dick so I stopped reading.

Maybe when you're in the mood to play nice I'll link you to some of the stuff I've written in Go over the last 6 years. Some of them are pretty cool - if I do say so myself - and definitely not beginner projects.

For what it's worth, we all have the occasional blind spot when it comes to semantics. Including yourself. So there's no need to be an arrogant dick the few occasions you happen to be in the right.

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

#116
post #61

Earlier quoted context omitted.

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…

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

Snatching defeat from the jaws of victory :)

But I'm not sure who to believe, the other reply to the parent comment says that copying things around is actually possible.

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

#117
post #28
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…

What's the IDE support like for Nim?

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

#118

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.

I guess beauty is in the eye of the beholder, though your eye seems questionable, the only "shortened keywords" I can find in the wikipedia page are "rec" (which is a long-standing shortening of "recursive" in recursive lets) and "fun" (for functions).

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

#119
post #63
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…

I agree that writing in a fast, compiled, statically typed language is not necessarily premature optimization. It is my first choice for a new project in the absence of any other mitigating factors.

There are often mitigating factors, though.

And switching from an existing language to use a new one that is possibly more optimized carries costs that have to be considered. If the new implementation shaves a few percent off some time or other resource scale, and the sum of that savings over the life of the program is more than the cost to do development and maintenance it's worth it. But that often isn't the case.

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

#120
post #69
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 t…

Have you used dep? https://github.com/golang/dep
Post reply on HN