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.
Learning Go by porting a medium-sized web back end from Python
81–90 of 207 posts
Re: Learning Go by porting a medium-sized web back end from Python
#82Earlier 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…
> except the ecosystem/commercial backing
If this is not the most important feature on that list, here is one more vote for Nim. Give it a try, it might (pleasantly) surprise you!
Re: Learning Go by porting a medium-sized web back end from Python
#83>However, it was only 1900 lines of Go (about 50% more than the 1300 lines of Python). >However, I’d seriously consider using Go for larger projects (static typing makes refactoring easier) Assuming a fully tested codebase and a relatively sane runtime type system, I'd much , much rather maintain the shorter codebase than the statically typed one. Having less code makes refactoring easier.
I agree that brevity sometimes aids refactoring, but there are many parameters that have to be weighed in, and often I find that the benefit of static typing outweigh whatever ignoring the type or checking it at run-time might offer.
Re: Learning Go by porting a medium-sized web back end from Python
#84I 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…
Re: Learning Go by porting a medium-sized web back end from Python
#85Earlier quoted context omitted.
I don't see anything about interface{} on https://godoc.org/compress/gzip , only byte slices, io.Reader and io.Writer.
[deleted]
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 support for contra- or covariance), but that's not the complaint that is being discussed here.
The complaint is specifically around interface{}, which is a type that means nothing, and so everything fits into it. It means that if you are a function that is receiving an interface{}, you know nothing about the argument to start with, and will have to either pass it along to something else, or examine it via type assertions or in the worst case, the reflect library.
As a multi-year Go programmer, I agree that A: the "true" interface{} that is the meaningless type appears less often than people think, and that if you program is shot through with it, you are either working in a domain where Go is not suitable (complicated math processing, IMHO, for instance), or you are programming some other language in Go, and need to learn how to use Go properly, but also, B: it does happen that things that would be well-typed in other languages will have interface{} show up, which means you're going to sacrifice runtime safety and some performance, though the exact impact depends on what you are doing.
(I say the "true" interface{} because there's also some places where interface{} shows up, but it doesn't hurt you. For instance, the standard JSON library accepts an interface{} to say what data structure to parse the JSON into, and the code that implements that is somewhat complicated, but for the most part, that interface{} doesn't bother you, the Go user. In theory you can encounter run time errors if you pass in something that doesn't work, but in practice, if you pass in the same type every time, which is the natural case that is going to result if you just program normally, it's not a problem. In general, `interface{}` showing up in the incoming parameters of a library is much less concerning than an interface{} showing up in the return parameters for a library. In the former case, even though the language does not enforce type safety, you can enforce type safety by how you use the method; in the latter, you are stuck with an interface{} in your code with all that implies.)
Re: Learning Go by porting a medium-sized web back end from Python
#86Earlier 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…
>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
#87Earlier quoted context omitted.
>- 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 ar…
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.
Re: Learning Go by porting a medium-sized web back end from Python
#88Earlier 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?
Re: Learning Go by porting a medium-sized web back end from Python
#89>However, it was only 1900 lines of Go (about 50% more than the 1300 lines of Python). >However, I’d seriously consider using Go for larger projects (static typing makes refactoring easier) Assuming a fully tested codebase and a relatively sane runtime type system, I'd much , much rather maintain the shorter codebase than the statically typed one. Having less code makes refactoring easier.
Assuming a fully tested codebase, there is an overhead in writing and maintaining unit tests that has to be considered as well, and using a static type system obviates a whole category of them. You move the type specification out of tests and manual documentation directly into the code where you'll find out at compile time what you did wrong. Not at run-time, or during testing because you diligently wrote a test that…
I've not found this to be true, and tests that do type checking are a waste of time in any language.
Bugs that are caught by static type systems are almost always caught by a combination of behavior tests and a sprinkling of sanity/type checks on border code (e.g. a module's publicly facing API).
>you'll find out at compile time what you did wrong
In a fully tested code base that is regularly tested the distinction between compile time and runtime does not matter a lot.
By contrast n code bases in dire need of tests (which is more common than generally assumed), the distinction is absolutely vital.
Re: Learning Go by porting a medium-sized web back end from Python
#90Earlier 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".
It's not immediately obvious, but when you write some Kotlin you'll see. Little things that are a apin in Java and elsewhere are quick and natural in Kotlin: - nullable types are smoother than Options - null checks are relatively painless - the stdlib works with you, not against - named parameters and optional parameters means no need for builders - etc. Etc.
"nullable types are smoother than Options - null checks are relatively painless"
Might be the case, but Options are more expressive in that I can combine them and restrict them with other type classes to express larger constraints. Reusabilty is higher e.g. with Monad transformers like OptionT.
So nullable types are less code, but also less expressive as building blocks of larger constructs.
They might be also less expressive because they conflate two concepts: Not initialized and not-there, whereas Option expresses not-there and _ (in Scala) expresses not-initialized.
"named parameters and optional parameters"
Not sure how this more expressive?