5 ms·
Python is high level language while Go is low, system level language (I think it’s fair to say it’s C 2.0). 95% of asciinema codebase is high level code... I g
by quacker 10y ago
Python is high level language while Go is low, system level language (I think it’s fair to say it’s C 2.0). 95% of asciinema codebase is high level code...
I get this sentiment. There's an attitude among golang developers that things which are "trivial" to implement don't belong in the go standard library (even if they would see high usage). That, and Go's animosity toward generic code and syntax sugar make me feel like I'm fiddling with nuts and bolts sometimes.
For example, Go stubbornly excludes a math.Round() function from it's math package because "the bar for being useful needs to be pretty high" (this comment was followed by several buggy implementations of the method[1]). Go excludes integer math functions, and the lack of generics means I have to cast to float64 or write my own implementation everywhere.
Go’s lack of versioned packages and central repository makes packaging cumbersome.
One of the big headscratchers of the golang ecosystem. It's resulted in a million different package managers and ridiculous tools that rewrite all of your imports for you.
My favorite method of managing requirements now is glide[2] which pins all of your dependencies (to a git commit or tag) in a glide.lock file. Glide fetches dependencies into the vendor directory, but you never need to commit your vendored dependencies. Instead, commit the glide.lock file and glide can fetch everything for you.
----
1. https://github.com/golang/go/issues/4594#issuecomment-66073310 https://github.com/golang/go/issues/4594#issuecomment-660733...
2. https://github.com/Masterminds/glide https://github.com/Masterminds/glide
- weberc2 10y agoI'm a Python programmer by day, and I would very much appreciate a stricter type system so it was apparent what arguments a function might accept, what arguments a function might return, etc without having to open up my browser and dig through documentation. I also love that Go doesn't have much in the way of syntactic sugar--it's absolutely obvious what everything does. For example, there's no way to overload `==` so it returns an object (looking at you, SQLAlchemy). The lack of generics is the only real pain point I feel with Go, but it's not for trivial integer functions--rather for larger data structures, like various kinds of trees. Of course, it's silly to think Python "does it better", Python has no typing at all, which you can do as well in Go via `interface{}`, and there are data structures libraries which do exactly this, but you pay a performance cost (probably still faster than Python).
- nine_k 10y agoIf you've a python programmer, you're used to high-level, succinct code. If you want a typed language of this kind, try Haskell, or Kotlin, or maybe Rust, or Nim, or even (gasp) java 8. Compared to Python, Go severely lacks expressive power.
- dilap 10y agoone persons 'lack of expressive power' is another persons 'this code is easy to read'. i've moved from python -> go for server backends & some personal command-line tools, and couldn't be happier. i still use python for interactively for figuring stuff out, but for anything big enough to be saved to a file, i'll reach for go. ymmv!
- crimsonalucard 10y agoexpressive power can make things easier to read. python reads like pseudo code and is arguably the most readable language out there. C has more expressive power than assembly and is also more readable.
- weberc2 10y agoPython can be very readable. In practice, it's much less readable than Go. Also, Python's lack of typing makes it very hard to follow type arguments (something I lament daily). I love that I can enter a few keystrokes in vim and see the type signature, methods, fields, documentation, or even the full definition. Python doesn't really have this (at least not unless your project is using mypy).
- xapata 10y ago> in practice I guess that depends on who is practicing.
- trentnelson 10y agoOne of the side projects I've been working on attacks this in a different way; what if we efficiently trace every single call point at the Python and C level, including all arguments, such that we can build up a historic inference of types a given object label had at any point in time.