5 ms·

On the off chance you're not already acquainted, you might really like Go. There are no classes, thus struct types are the bread and butter. "Methods" are light

On the off chance you're not already acquainted, you might really like Go. There are no classes, thus struct types are the bread and butter. "Methods" are lightweight syntactic sugar combining structs and functions; structs effectively double as classes, but the scope and complexity they offer are perhaps easier to juggle compared to the typical object-oriented language. The inheritance mechanism, implemented via interfaces, is interesting because it stresses conformance to behavior rather than explicit relationships between types. If your Circle struct type walks and talks like a Shape, then it is implicitly usable as a Shape. It's functionally identical to explicitly defined inheritance between types in other languages, but there's something about the _feel_ of developing with Go's interfaces. You begin to think more about the simple behaviors that each type should exhibit, rather than drawing hard lines in the sand about the hierarchy of relationships. Circles and Squares don't extend a base Shape type. Rather, a Circle can calculate its surface area. A Square can do the same. Conveniently, it just so happens that any type that can calculate its area is promoted to being usable anywhere a Shape is expected.

SlowRobotAhead 8y ago
Is there a Go VM for 32bit embedded?
- developer2 8y ago
  The parent I replied to made me think so strongly of Go that I forgot the context regarding embedded systems. A quick search shows support for ARM; beyond that, I don't know if any options exist.
  - SlowRobotAhead 8y ago
    When a language says ARM like that, they mean the ARM that runs your phone. Not the ARMs that run your Fitbit.
- nicoburns 8y ago
  In that context you'd probably be better off with Rust (which takes a similar attitude to inheritance).
weberc2 8y ago
Yeah, I love that Go uses structs. Go is my favorite language, but it still has lots of rough edges, like no generics or sum types. If I were designing Go2, I might also get rid of interfaces in favor of closures or explicit vtables (but that's a little puritanical and I might change my mind after programming in that style for a while). Still, I get things done faster in Go than I do in many of the languages that I've used professionally, like Python, JS, C, and C++.
- vram22 8y ago
  >Still, I get things done faster in Go than I do in many of the languages that I've used professionally, like Python, JS, C, and C++. What's the reason for that, in your opinion? Do you mean dev time or run time? If it is dev time, I can understand it about Go vs. C and C++, not sure about JS, but vs. Python? (I know some Go, but much more of Python.) I know Go has a fast compiler and is somewhat fast to write and run too, sort of a cross between dev time of Python and run time of C (I've that heard from someone who used it for a startup, and others), but I would have thought Python may have somewhat of an edge (even if small) when it came to dev time, over Go, or at least that they would be about the same, all other things (like dev experience) being equal. That's just a guess, though. Don't have data to back it up.
  - weberc2 8y ago
    Thanks for asking, happy to share. I was referring to dev time, but Go is also much faster than Python at runtime. To give a little context, I've been writing Python since 2007, and professionally for ~5 years. I've been using Go in my hobby time for about ~5 years as well. I think Go allows me to develop more quickly for a variety of reasons. First of all, it is statically typed by default. This means that APIs tend to make more sense out of the box. You don't get APIs like Pandas' or matplotlib's or etc where you can pass three strs and an int or two floats and a datetime unless it's a Tuesday. I don't need to spend time pouring over documentation because it's all right there in the type signature, and there are high-quality plugins available for every major text-editor that allow the text editor to show you the function signature (and docs) at the push of a button (this is possible largely because of static typing). Also, because of static typing, I get faster feedback when I've broken something. Unit tests do a pretty good job of catching things in Python, but I still find a couple of bugs a week in our Python codebase (usually in error paths) that a static analysis tool would have caught. Now of course Python has a static type checker (mypy), and mypy can catch many of these errors. However, static typing support in Python isn't great. mypy is buggy, many popular libraries like SQLAlchemy simply can't be annotated, simple types like JSON can't be represented (no recursive types), dealing with type variables is miserable, and the documentation is poor. Things are progressing, but progress is slow. I will say that I like that Python at least has typing.Generic and typing.Union; Go has no generics and the idioms for sum types are all painful in one way or another. Also, because of static typing, the documentation generation support in Go is way ahead of Python. Python basically has sphynx and readthedocs, which takes a pretty miserable syntax and turns it into a giant wall of HTML. Many popular projects are incompletely documented. Just today, I was searching on aiohttp's docs page for the errors documentation. It just doesn't exist, but they definitely have an exception for every HTTP status code. Many times, devs just punt and give you a handful of parameters and maybe their types (even in the stdlib, like `subprocess.run()` which tells you that the params are sorta like `subprocess.popen()`). It's basically impossible to ctrl-f in the docs either because you never know which class's `__str__()` method you're looking at. Also, in our own project, we kept seeing the sphinx docs getting out of date since there was no type checker running on the sphinx annotations (wrong annotations are worse than no annotations). Many times I just have to fire up the REPL and test the method until I figure out what the hell it actually expects for its args and what its concrete return type is, and this is an even bigger pain when the library depends on a connection to some remote database or service. By contrast, Go has http://godoc.org http://godoc.org which generates docs for any public package based on comments (no special syntax!) and types. You can tell at a glance that you're looking at `Foo.String()` instead of `Bar.String()` when you search for `String()` on the page. Even if the developer doesn't document anything, plenty of information is available, and if you ever need more information, each identifier has a link to its definition on Github (or bitbucket, gitlab, etc), so you're never more than a mouseclick from the complete information. So static typing is a pretty big deal here, but there's also things like async. I'm really happy that async is taking off in Python, but it's still pretty confusing and tedious. I still don't have the whole model in my head (we've only been using it for ~8 months), but it's really annoying that every library that does any I/O at all now needs an async version. Recently I was trying to concurrently build Docker images from a Python script, but the Python Docker API isn't async, so I guess I'll need to fork a process or something. Most popular projects like Docker and AWS have some Joe Developer maintaining an equivalent async library, but that comes with a bunch of additional concerns. In Go, everything is async by default with a synchronous interface, which is almost exactly the interface I want for async things (although I do prefer Python's `await` to Go's channels and goroutines). Also, making things fast in Go is a lot easier and more straightforward than in Python. First of all, Go is 10-100X faster than Python, so you don't need to optimize in Go as often as you do in Python. But when you do, the optimizations are usually spelled out to you by the profiler and you can actually fix them (since Go gives you control over things like allocations which allows you to intervene to reduce memory pressure and improve cache performance). Also parallelism; for all intents and purposes, your only parallelism option in Python is multiprocessing, and this is shitty. For most peformance issues, the Python answer is "just use C for your hotpath", but this can actually make things slower for a lot of situations since calling into C typically means converting between Python data structures and C data structures. I had a coworker throw Pandas at a performance problem, but the solution involved running Python on every cell in the dataframe, so we actually lost (10-30X) performance over the naive list-o-dicts solution because of all of the calling across the language barrier. And if you're not using something like Pandas or Numpy, writing C is actually pretty hard for the average Python dev, and writing memory-safe, secure, portable, cross-platform C is hard for lots of above-average C developers. There are definitely cases where "just write it in C" is a reasonable thing to do, but even being able to identify those cases takes a certain amount of expertise that your average Python developer doesn't have. Lastly, Go compiles everything to a static binary. Python finally got pipenv, which solves some of the same problems, but it's still a pain and every issue seems to take a full afternoon to debug. Go binaries just run out of the box on pretty much any Linux. I don't want to give the impression that I write Go 10X better than Python; it's probably closer to 1.2-1.5X, and there are some times where Go is the clear loser. Some libraries just don't exist or aren't yet mature in Go, and any sort of magic is far easier in Python (although this is also a misfeature since you get more people adding unnecessary and/or bug-ridden magic into their APIs). Hopefully this wall-o-text answers your question. As always, YMMV.

SlowRobotAhead 8y ago

Is there a Go VM for 32bit embedded?

developer2 8y ago
The parent I replied to made me think so strongly of Go that I forgot the context regarding embedded systems. A quick search shows support for ARM; beyond that, I don't know if any options exist.
- SlowRobotAhead 8y ago
  When a language says ARM like that, they mean the ARM that runs your phone. Not the ARMs that run your Fitbit.
nicoburns 8y ago
In that context you'd probably be better off with Rust (which takes a similar attitude to inheritance).

weberc2 8y ago

Yeah, I love that Go uses structs. Go is my favorite language, but it still has lots of rough edges, like no generics or sum types. If I were designing Go2, I might also get rid of interfaces in favor of closures or explicit vtables (but that's a little puritanical and I might change my mind after programming in that style for a while). Still, I get things done faster in Go than I do in many of the languages that I've used professionally, like Python, JS, C, and C++.

vram22 8y ago
>Still, I get things done faster in Go than I do in many of the languages that I've used professionally, like Python, JS, C, and C++. What's the reason for that, in your opinion? Do you mean dev time or run time? If it is dev time, I can understand it about Go vs. C and C++, not sure about JS, but vs. Python? (I know some Go, but much more of Python.) I know Go has a fast compiler and is somewhat fast to write and run too, sort of a cross between dev time of Python and run time of C (I've that heard from someone who used it for a startup, and others), but I would have thought Python may have somewhat of an edge (even if small) when it came to dev time, over Go, or at least that they would be about the same, all other things (like dev experience) being equal. That's just a guess, though. Don't have data to back it up.
- weberc2 8y ago
  Thanks for asking, happy to share. I was referring to dev time, but Go is also much faster than Python at runtime. To give a little context, I've been writing Python since 2007, and professionally for ~5 years. I've been using Go in my hobby time for about ~5 years as well. I think Go allows me to develop more quickly for a variety of reasons. First of all, it is statically typed by default. This means that APIs tend to make more sense out of the box. You don't get APIs like Pandas' or matplotlib's or etc where you can pass three strs and an int or two floats and a datetime unless it's a Tuesday. I don't need to spend time pouring over documentation because it's all right there in the type signature, and there are high-quality plugins available for every major text-editor that allow the text editor to show you the function signature (and docs) at the push of a button (this is possible largely because of static typing). Also, because of static typing, I get faster feedback when I've broken something. Unit tests do a pretty good job of catching things in Python, but I still find a couple of bugs a week in our Python codebase (usually in error paths) that a static analysis tool would have caught. Now of course Python has a static type checker (mypy), and mypy can catch many of these errors. However, static typing support in Python isn't great. mypy is buggy, many popular libraries like SQLAlchemy simply can't be annotated, simple types like JSON can't be represented (no recursive types), dealing with type variables is miserable, and the documentation is poor. Things are progressing, but progress is slow. I will say that I like that Python at least has typing.Generic and typing.Union; Go has no generics and the idioms for sum types are all painful in one way or another. Also, because of static typing, the documentation generation support in Go is way ahead of Python. Python basically has sphynx and readthedocs, which takes a pretty miserable syntax and turns it into a giant wall of HTML. Many popular projects are incompletely documented. Just today, I was searching on aiohttp's docs page for the errors documentation. It just doesn't exist, but they definitely have an exception for every HTTP status code. Many times, devs just punt and give you a handful of parameters and maybe their types (even in the stdlib, like `subprocess.run()` which tells you that the params are sorta like `subprocess.popen()`). It's basically impossible to ctrl-f in the docs either because you never know which class's `__str__()` method you're looking at. Also, in our own project, we kept seeing the sphinx docs getting out of date since there was no type checker running on the sphinx annotations (wrong annotations are worse than no annotations). Many times I just have to fire up the REPL and test the method until I figure out what the hell it actually expects for its args and what its concrete return type is, and this is an even bigger pain when the library depends on a connection to some remote database or service. By contrast, Go has http://godoc.org http://godoc.org which generates docs for any public package based on comments (no special syntax!) and types. You can tell at a glance that you're looking at `Foo.String()` instead of `Bar.String()` when you search for `String()` on the page. Even if the developer doesn't document anything, plenty of information is available, and if you ever need more information, each identifier has a link to its definition on Github (or bitbucket, gitlab, etc), so you're never more than a mouseclick from the complete information. So static typing is a pretty big deal here, but there's also things like async. I'm really happy that async is taking off in Python, but it's still pretty confusing and tedious. I still don't have the whole model in my head (we've only been using it for ~8 months), but it's really annoying that every library that does any I/O at all now needs an async version. Recently I was trying to concurrently build Docker images from a Python script, but the Python Docker API isn't async, so I guess I'll need to fork a process or something. Most popular projects like Docker and AWS have some Joe Developer maintaining an equivalent async library, but that comes with a bunch of additional concerns. In Go, everything is async by default with a synchronous interface, which is almost exactly the interface I want for async things (although I do prefer Python's `await` to Go's channels and goroutines). Also, making things fast in Go is a lot easier and more straightforward than in Python. First of all, Go is 10-100X faster than Python, so you don't need to optimize in Go as often as you do in Python. But when you do, the optimizations are usually spelled out to you by the profiler and you can actually fix them (since Go gives you control over things like allocations which allows you to intervene to reduce memory pressure and improve cache performance). Also parallelism; for all intents and purposes, your only parallelism option in Python is multiprocessing, and this is shitty. For most peformance issues, the Python answer is "just use C for your hotpath", but this can actually make things slower for a lot of situations since calling into C typically means converting between Python data structures and C data structures. I had a coworker throw Pandas at a performance problem, but the solution involved running Python on every cell in the dataframe, so we actually lost (10-30X) performance over the naive list-o-dicts solution because of all of the calling across the language barrier. And if you're not using something like Pandas or Numpy, writing C is actually pretty hard for the average Python dev, and writing memory-safe, secure, portable, cross-platform C is hard for lots of above-average C developers. There are definitely cases where "just write it in C" is a reasonable thing to do, but even being able to identify those cases takes a certain amount of expertise that your average Python developer doesn't have. Lastly, Go compiles everything to a static binary. Python finally got pipenv, which solves some of the same problems, but it's still a pain and every issue seems to take a full afternoon to debug. Go binaries just run out of the box on pretty much any Linux. I don't want to give the impression that I write Go 10X better than Python; it's probably closer to 1.2-1.5X, and there are some times where Go is the clear loser. Some libraries just don't exist or aren't yet mature in Go, and any sort of magic is far easier in Python (although this is also a misfeature since you get more people adding unnecessary and/or bug-ridden magic into their APIs). Hopefully this wall-o-text answers your question. As always, YMMV.