91–100 of 207 posts
The stages of go enlightenment: 1. Holy crap, this is like coding in early Java days, what the heck were the language designers smoking?! They just ignored everything! Where's my testing framework! DI?! Build system, dependency management?! WTF. 2. Holy crap, this is like coding in the early Java days! This is awesome! I can understand all golang code I read! Everything is so simple and easy. I finally get "less is m…
The stages of go enlightenment: 1. Holy crap, this is like coding in early Java days, what the heck were the language designers smoking?! They just ignored everything! Where's my testing framework! DI?! Build system, dependency management?! WTF. 2. Holy crap, this is like coding in the early Java days! This is awesome! I can understand all golang code I read! Everything is so simple and easy. I finally get "less is m…
1. Wow, this program runs on any platform!
2. Wow, no need to free memory!
3. Wow, threads and locks are so easy to do!
Then many years later
4. Who really cares about cross-platform code if all I do is on Linux?
5. Why does this program require 4GB of ram?
6. Must I really download and install the JVM all the time, and what is it good for anyway?
Go:
1. Wow, I can write stuff that previously could only be done in C/C++, and I can do it almost as easily as writing Python or Ruby.
2. Wow, I don't need anything installed for my program to run, it just runs!
Earlier quoted context omitted.
Surprises me it doesn't have syntax highlighting.
Possibly because Rob Pike is not a fan of syntax highlighting, calling it juvenile. https://groups.google.com/forum/#!msg/golang-nuts/hJHCAaiL0s...
Earlier quoted context omitted.
RoR is an awesome framework that has (almost) everything you need to build monolithic web apps. Go is a different story. You need to join the pieces together to make something functional. You will probably need: - A router like [Gin]( https://github.com/gin-gonic/gin ) - A [XSRF token generator and validator]( https://github.com/golang/net/blob/master/xsrftoken/xsrf.go ) - An ORM like [Gorm]( https://github.com/jinzh…
err... RoR is a full-size framework. Ruby is the language. Go is a language. Go has frameworks. You are comparing apples to oranges. With go you can then select what functionality, libraries, toolkits or frameworks you want to use with your system. ps. why would you mention node? would you use node with a php site?
I don't know nothing monolithic like Rails for Go, do you? What I was trying to say is that you have to use libs, instead of a big monolithic framework like Rails, that do not exists for Go (AFAIK).
I don't like Node and NPM, but it would be the alternative to Asset Pipeline (e.g. for concatenating and minifying JS and CSS, etc).
Earlier quoted context omitted.
RoR is an awesome framework that has (almost) everything you need to build monolithic web apps. Go is a different story. You need to join the pieces together to make something functional. You will probably need: - A router like [Gin]( https://github.com/gin-gonic/gin ) - A [XSRF token generator and validator]( https://github.com/golang/net/blob/master/xsrftoken/xsrf.go ) - An ORM like [Gorm]( https://github.com/jinzh…
Can you explain more about using Node for the front end? Do you mean you use `npm` for front-end package management, or are you running a Node server process along side your Go process on the backend?
The stages of go enlightenment: 1. Holy crap, this is like coding in early Java days, what the heck were the language designers smoking?! They just ignored everything! Where's my testing framework! DI?! Build system, dependency management?! WTF. 2. Holy crap, this is like coding in the early Java days! This is awesome! I can understand all golang code I read! Everything is so simple and easy. I finally get "less is m…
Appreciate it was written as tongue in cheek, but I am glad that today a developer can start with Go, test, write code, build, deploy all with Go, whereas nearly every other ecosystem requires additional tools, often external competing tools. Then life becomes about having to learn whole new toolbekt before even coding. Go still keeps it lean, and is great. The fact it does not have hipster dev approved status is als…
Huh? In my experience Go is the most hipster dev language around at the moment.
Earlier quoted context omitted.
Median latency is a completely useless number. There is literally no use for it, ever. Satan invented median latency to confuse people, because it lies to you and whispers sweet nothings in your ear. Averaging latencies in your monitoring leaves the outliers out in the cold because you will never see them, and tail latency is way more important for user experience. Quantile your latency. I suspect you'll find 99th te…
> Average latency is unimportant That feels like an overly-bold claim. Improving your 99th percentile latency from 2 seconds to 1 second may not be worth it if you bring your average latency up from 0.05 seconds to 0.99 seconds. > It's that 1% of clients sitting there for 2sec that impacts perception of your UX. Well, surely that depends on what endpoints those are and what people are expecting from them. A 2s wait f…
| ==== p99
|=================
ms |+++++++++++++++++++++ p95
|..................... p75
|````````````````````` p50
|---------------------
t ->
You gain a lot from this. Visually, you can see how tight your distribution is as the rainbow squeezes together. Narrower the better. Every time. In fact, very often the Y axis is irrelevant, and here's why:
Reining in your p99 that far at the expense of a higher average is, oddly, a win. That might surprise you but it is borne out in practice, because at scale only the long tail of latency matters. A wide latency distribution is problematic, both for scaling and for perception. A very narrow latency distribution is actually better. If you can trade off a bit higher latency for less variance/deviation, it will be a win every time. Weird, I know. User perception is weird and, as you point out, the rules change per-endpoint. Perception tends to evolve, too. As a rule of thumb, though, tighter distribution of latency is always better and how far you can push median to get there is your business decision and user study environment.
To borrow one of Coda Hale's terms[0], the scenario you presented demonstrates the cognitive hazard of average and is actually my root point. The average came up, yes. That is not necessarily bad (at all!), but "average" intuitively tells you that it maybe should be. In this case, it is misleading you, because the exact scenario you presented might be a strong win depending on other factors. A 99th of 1000ms with a 990ms average is a really tight latency distribution so it is fairly close to ideal for capacity planning purposes. It blew my mind when I discovered that Google actually teaches this to SREs because, like you, how unintuitive it is threw me off.
It's hard to swallow that a 990ms average might be better than 50ms. Might be. Average doesn't tell you. That's why it sucks. Not just for computing, either; average is pretty much the worst of the aggregations for cognitive reasons and is really only useful for describing the estimated average number of times you fart in a day to friends, because it is quite overloaded mentally for many people without experience in statistics.
Earlier quoted context omitted.
err... RoR is a full-size framework. Ruby is the language. Go is a language. Go has frameworks. You are comparing apples to oranges. With go you can then select what functionality, libraries, toolkits or frameworks you want to use with your system. ps. why would you mention node? would you use node with a php site?
> Go has frameworks I don't know nothing monolithic like Rails for Go, do you? What I was trying to say is that you have to use libs, instead of a big monolithic framework like Rails, that do not exists for Go (AFAIK). I don't like Node and NPM, but it would be the alternative to Asset Pipeline (e.g. for concatenating and minifying JS and CSS, etc).
Revel is pretty monolithic: https://revel.github.io/
I've used it to build a web application, and here are some of the problems it addresses (this is just the table of contents from their manual):
- Controllers
- URL Routing
- Request Parameters
- Validation
- Session & Flash
- Results & Response
- Templates
- Interceptors
- Filters
- Websockets
- Internationalization
- Cache
- Database
- DebuggingThe stages of go enlightenment: 1. Holy crap, this is like coding in early Java days, what the heck were the language designers smoking?! They just ignored everything! Where's my testing framework! DI?! Build system, dependency management?! WTF. 2. Holy crap, this is like coding in the early Java days! This is awesome! I can understand all golang code I read! Everything is so simple and easy. I finally get "less is m…
Java was: 1. Wow, this program runs on any platform! 2. Wow, no need to free memory! 3. Wow, threads and locks are so easy to do! Then many years later 4. Who really cares about cross-platform code if all I do is on Linux? 5. Why does this program require 4GB of ram? 6. Must I really download and install the JVM all the time, and what is it good for anyway? Go: 1. Wow, I can write stuff that previously could only be…