141–150 of 281 posts
Earlier quoted context omitted.
In cloud time performance is simply a matter of cost saving. No matter what your needs are, if you're able to serve more request per cpu cycle or Mo of memory, then you'll save on server costs.
And yet we see web applications written in Python
Perhaps it's characteristic of all language discussions, but Go articles seem to generate an extremely polarized set of comments. My other favored languages (Common Lisp, Nim, Rust, Smalltalk) tend to do the same thing, but in Go's case the passion seems so... misguided. In my opinion, Go is just such a bland-in-a-good-way language. And I enjoy writing it, for the record. Came back to it after a while not writing it…
This. At least this is easily added.
But why there is "nil" in Go I find less excusable, mainly because this "feature" is not easily (impossibly) removed.
I know this is about the weakest critique possible, but currently using Go, I know my next project won't be in it, simply for the impossibility to put an opening curly brace on its own line. Other languages that don't require semicolons at the end of a line have it, and even if they didn't, I'd rather have to put semicolons manually.. Go is "opinionated" I guess, but so am I. Whatever their target audience is, I'm no…
Earlier quoted context omitted.
Which other languages? Turbo Pascal compilation speed, in MS-DOS, using 90’s hardware was already faster than Go. There are lots of languages with modules support, with static linking and native compilation to choose from.
>Turbo Pascal compilation speed, in MS-DOS, using 90’s hardware was already faster than Go. What relevance does this have on the compiler landscape today ? If you have to use a compiler from ~30 years ago to find a comparison supporting your claim, it sounds very much like Go is indeed much faster than what it competes against today.
If you want the 2017 version of it, it is called Delphi. Beats Go in language features and compilation speed.
Go's compilation speed only surprises those developers that never used anything else beyond C and C++.
Not strictly about Go, but how is it supposed to impress that 'big company X' uses language Y (in this case the author uses Uber as if that's some kind of + for Go); I would be far more interested in the language + framework used to solve what level of complexity and scale problem with how many servers + people. If you can build & run something with less people and servers than your competitor and which makes you mak…
I know this is about the weakest critique possible, but currently using Go, I know my next project won't be in it, simply for the impossibility to put an opening curly brace on its own line. Other languages that don't require semicolons at the end of a line have it, and even if they didn't, I'd rather have to put semicolons manually.. Go is "opinionated" I guess, but so am I. Whatever their target audience is, I'm no…
... curly brackets on new lines do work perfectly fine in case you're writing code on your own. As soon as you start working in a team and each team member starts to use their own formatting, it becomes super messy and unreadable. Either you inforce a clear style guide which leaves you to explain the team why your style is the best, or you leave this task to the language itself and never ever have to start arguing ab…
To me, even with super short lines, braces at the end of the line are messy, and consistently messy is still messy.
> Either you inforce a clear style guide which leaves you to explain the team why your style is the best, or you leave this task to the language itself
Which then leaves the language to explain why that style is best. Did Google ever do that?
I know this is about the weakest critique possible, but currently using Go, I know my next project won't be in it, simply for the impossibility to put an opening curly brace on its own line. Other languages that don't require semicolons at the end of a line have it, and even if they didn't, I'd rather have to put semicolons manually.. Go is "opinionated" I guess, but so am I. Whatever their target audience is, I'm no…
This is great for a lot of code but it's probably my biggest complaint about the language these days. PHP supports first-class functions, which is great until you realize all your functions stored in variables have $ at the front. So now, not only can't you use $ to distinguish variables from functions (because sometimes they're both) but you have to remember if something is a Closure* or not.
* another minor pet peeve is that you have to explicitly tell a function what variables it can see from the surrounding scope, but all anonymous functions inherit from a class called Closure whether they can see anything outside their own scope (a closure) or not.
I know this is about the weakest critique possible, but currently using Go, I know my next project won't be in it, simply for the impossibility to put an opening curly brace on its own line. Other languages that don't require semicolons at the end of a line have it, and even if they didn't, I'd rather have to put semicolons manually.. Go is "opinionated" I guess, but so am I. Whatever their target audience is, I'm no…
... curly brackets on new lines do work perfectly fine in case you're writing code on your own. As soon as you start working in a team and each team member starts to use their own formatting, it becomes super messy and unreadable. Either you inforce a clear style guide which leaves you to explain the team why your style is the best, or you leave this task to the language itself and never ever have to start arguing ab…
A large part of what makes me stick to Ruby over Python for example, is that I can't stand languages with significant indentation. It may seem minor, but it isn't to me, to the extent where I avoid Python whenever I can.
When your language enforces formatting like that, people will choose or choose away the language over the formatting.
It's that important. Especially with so many languages to choose for that you can often pick one that is sufficiently similar.
At my job, before I joined, I was told we were torn between using Go and Rails and ended up with both. Now we have a Rails frontend (for web requests / authentication) and a Go backend (for business logic), which communicate over Thrift RPC. I don't think it was a very wise decision because not only are you doing things twice, you're doing it three times, because you have to serialize/deserialize to/from Thrift for e…
Hard to debug binary-based RPC? You have picked the wrong technology for communication, having forgotten that you'd need to build the necessary tools in order to debug it. There's literally nothing wrong with binary protocols, except developers forgetting about the necessary overhead of re-parsing the passed data in the debugger. But it's not an overly expensive overhead, if the architect had taken this into account.
Having heard this point absolutely not for the first time, the only question that remains is: who and why did make a decision to have it this way?
From my point of view PHP 7.2 is a great choice for startups and with a small team, so build the product, make it run. If required then do some R&D to switch to go, jumping straight into go should cause some issue.