4 ms·

In the original article, he indicates Swift, Rust, and Go are tomorrow's languages. The issue really is that the level of support in the various frameworks, th

In the original article, he indicates Swift, Rust, and Go are tomorrow's languages. The issue really is that the level of support in the various frameworks, the eons of bug-crushing and feature additions, and the libraries available, are going to be behind for some time. This is why I'd still gladly pick Django today. What is "the future" isn't really so interesting as what is productive. Yes, performance matters a bit, but development time is usually much more expensive than adding a few nodes to an autoscaling group, and not worth the cost of using less fleshed out libraries.

weberc2 10y ago
In my experience as a professional Python dev and a hobbyist Gopher, Go's libraries are a lot less convoluted than Python libraries. In Python, you see a lot of libs that try to do everything for everyone (think long args lists and functions that try to guess the right thing to do based on arg types) whereas Go libraries just kind of snap together neatly. Go tends to be more productive for me than Python specifically because its philosophy values simplicity and orthogonality over complexity and scope breadth. > Yes, performance matters a bit, but development time is usually much more expensive than adding a few nodes to an autoscaling group, and not worth the cost of using less fleshed out libraries. Sequentially, Go outperforms Python and other interpreted languages by a wide margin (usually a factor of 10). Things get really interesting with Go because it can be massively concurrent without messing around with large async refactors. At work, we're hoping our first iteration (i.e., before any async refactors) of our Python application to handle something like 5-10 concurrent requests per machine (without degrading response times), but I'm confident a single Go process could handle at least 10X that load with better response times. This order-of-magnitude difference seems fundamentally different from the perspective of "throwing hardware at the problem". Further, Go's library story is fairly complete (for web services; GUIs and other domains are still lacking)--at least it's been a long while since I've lacked a complete library for some task.
- mpdehaan2 10y ago
  Again, performance isn't everything. Go has specialized a bit towards low-level operations, and I tend to strongly dislike what it does with exceptions and the way those involved veto language features. As for libraries, I'm talking about things on the level of, say, Django or ORMs.
  - weberc2 10y ago
    I don't disagree that there are other criteria besides performance, only that Go services will likely cost an order of magnitude less than Python services, and the development velocity is pretty much on par (and much better for concurrent tasks, since Go is much more expressive here). Go is heavily optimized toward performance and rapid development. Go also takes a hard philosophical bent against redundant features, like exceptions, under the "less is more" and "simple is better than complex" axioms; it's actually the same philosophy that Python's zen espouses, except Go actually adheres to it. Regarding libraries, there are numerous web frameworks and several ORMs. I'm unfamiliar with Django, but I will say that Go's standard HTTP library is a tremendous improvement over Flask. Also, I've not yet found an ORM that saves time or trouble over hand-coding SQL (in particular, SQLAlchemy is a real bear).

weberc2 10y ago

In my experience as a professional Python dev and a hobbyist Gopher, Go's libraries are a lot less convoluted than Python libraries. In Python, you see a lot of libs that try to do everything for everyone (think long args lists and functions that try to guess the right thing to do based on arg types) whereas Go libraries just kind of snap together neatly. Go tends to be more productive for me than Python specifically because its philosophy values simplicity and orthogonality over complexity and scope breadth. > Yes, performance matters a bit, but development time is usually much more expensive than adding a few nodes to an autoscaling group, and not worth the cost of using less fleshed out libraries. Sequentially, Go outperforms Python and other interpreted languages by a wide margin (usually a factor of 10). Things get really interesting with Go because it can be massively concurrent without messing around with large async refactors. At work, we're hoping our first iteration (i.e., before any async refactors) of our Python application to handle something like 5-10 concurrent requests per machine (without degrading response times), but I'm confident a single Go process could handle at least 10X that load with better response times. This order-of-magnitude difference seems fundamentally different from the perspective of "throwing hardware at the problem". Further, Go's library story is fairly complete (for web services; GUIs and other domains are still lacking)--at least it's been a long while since I've lacked a complete library for some task.

mpdehaan2 10y ago
Again, performance isn't everything. Go has specialized a bit towards low-level operations, and I tend to strongly dislike what it does with exceptions and the way those involved veto language features. As for libraries, I'm talking about things on the level of, say, Django or ORMs.
- weberc2 10y ago
  I don't disagree that there are other criteria besides performance, only that Go services will likely cost an order of magnitude less than Python services, and the development velocity is pretty much on par (and much better for concurrent tasks, since Go is much more expressive here). Go is heavily optimized toward performance and rapid development. Go also takes a hard philosophical bent against redundant features, like exceptions, under the "less is more" and "simple is better than complex" axioms; it's actually the same philosophy that Python's zen espouses, except Go actually adheres to it. Regarding libraries, there are numerous web frameworks and several ORMs. I'm unfamiliar with Django, but I will say that Go's standard HTTP library is a tremendous improvement over Flask. Also, I've not yet found an ORM that saves time or trouble over hand-coding SQL (in particular, SQLAlchemy is a real bear).