Learning Go by porting a medium-sized web back end from Python
151–160 of 207 posts
Re: Learning Go by porting a medium-sized web back end from Python
#152I 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…
Re: Learning Go by porting a medium-sized web back end from Python
#153Earlier quoted context omitted.
How about this: once you write code in Go and test it well, you can deploy it and forget about it unless there is a hardware issue? I recently ported some C++ code to Go which processes 8 Billion events per day flawlessly.
I feel like this is true for any language though. Once you write a well designed, well tested, and feature complete piece of software, you can deploy it and forget about it unless the server it's running on breaks. Go isn't special in that regard, unless there's something that makes Go easier to write, test, or deploy, which might be the case, but you haven't supported that.
Re: Learning Go by porting a medium-sized web back end from Python
#154Re: Learning Go by porting a medium-sized web back end from Python
#155Earlier 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…
I think my dream language would be C# but with a slightly more Pythonesque syntax (significant indentation, no semicolons or braces...). I wonder if a transpiler like that exists.
Once you get used to it, though, you'll probably want to write idiomatic F#.
Re: Learning Go by porting a medium-sized web back end from Python
#156Earlier 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…
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.
Re: Learning Go by porting a medium-sized web back end from Python
#157Recently 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 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…
What about Java? Its easy, modern in the way you describe, has a good concurrency story, multiple great IDEs, can compile to a static binary with commercial JVMs, or experimentally in OpenJDK9. Really big ecosystem. Huge commercial backing. It just maybe fails at historical baggage and syntax.
Kotlin fixes those last two. And Java 10 will also fix a good chunk of the syntax complaints.
In all fairness though, I think you're focused on nitpicks that have no practical benefits. You're asking for a language with a better user experience. Which is great, as it can make programming more pleasant, and I'm all for it.
That said, I'd focus on language changes that provide functional value. Haskell adds a powerful correctness layer at a low expressiveness cost. Go adds a useful CSP concurrency mechanism with green threads, as well as being friendly to containerisation. Erlang and co add a great deal of reliability features and massive parallelism with first class actors. Clojure gives you powerful metaprogramming, state of the art immutability and a similar CSP layer as Go, while maintaining the access to Java's large ecosystem. Kotlin adds null type checking, and better functional primitives. Rust gives you safe memory access without the performance overhead of a GC. Chapel allows for super parallel computing. Scala gives you OOP with the safety layer of Haskell on it. Nim gives you faster python, with type safety. Crystal gives you faster Ruby with type safety. Etc.
Those are the languages that challenge the status quo, and have a chance at bringing real value in terms of the average output they result in when used to program with.
A slightly better UX for Java or Python is a hard sell. Its like the famous Unix quote: "the most dangerous enemy of a better solution is an existing codebase that is just good enough." - Eric S. Raymond
Java, C#, Python, Ruby, C++ are all good enough, even UX wise, to be displaced by something that doesn't offer compeling functional value. At least, in my opinion.
Re: Learning Go by porting a medium-sized web back end from Python
#158Earlier 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…
I don't follow this logic. Why not use C all the time by default then?
But why not get all the gain? Well, sure, if performance is the only thing you care about. But it usually isn't. You might also care about networking, or multithreading. Would I rather write that code in C, or in Go? Is it enough better in Go to be worth that last 10% of performance? Arguably, yes.
When someone says "X matters", it doesn't mean that they are saying "X is the only thing that matters". It is not correct to conclude that they should, for consistency, be saying "turn the X knob as far as you can". Instead, interpret it as saying "given your other constraints, look for a sweet spot where X is somewhat toward this end of its range."
Re: Learning Go by porting a medium-sized web back end from Python
#159Earlier 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…
What's the IDE support like for Nim?
Nim itself does not come with an IDE, but does include nimgrep and nimsuggest which underlie intelligence and other features in every IDE setup.
Re: Learning Go by porting a medium-sized web back end from Python
#160Recently 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…
Chances are, if you are using mocks in Go, you are doing it wrong. Functions should take interfaces (not interface{}, but interfaces that list methods) and return structs. In your tests, you create a fake that meets the interface and pass that to your function under test. If you have to test file io or DB interaction, you can either do the adapter pattern or, as I prefer, just actually use the filesystem and DB but w…