81–90 of 125 posts
Earlier quoted context omitted.
Redis has transactions as well.
yes and if you set appendonly yes appendfsync always you will get about +/- PG write performance without all the features Now I know 0 production projects using these Redis settings and I would argue it's not intended use of Redis same way as running PG with fsync = off is not generally what you want to use
Earlier quoted context omitted.
C is hard. You're right though, why not use C? It's a good language, and it's hard to beat for it's low level powers, portability and speed. What go gives you is high level productivity, testing, a solution for package management (abit a rubbish one), and a good ecosystem of 3rd party libraries for things like AWS. The things that suck about C: - It's hard to do right. There's a great book called 'Deep C Secrets' on…
>Have a look at this excellent highly portable IPC library: https://github.com/saprykin/plibsys >[...] >...but for a web service or web framework? >nah. >Go was written specifically for those purposes, with high throughput performance as its goal, and a significant amount of effort devoted to optimizing that. >It's not suitable for something like plibsys either. I found this part of your comment difficult to understa…
The point I was making is:
Don't pick go. Or C. Or Rust. ...unless it's the right tool for the job. Or at least the right sort of tool; there's plenty of cross over.
In this case (web framework), C isn't the right tool for the job. ...but, to be fair, C is the right tool for some jobs.
Earlier quoted context omitted.
> Not only is this page riddled with typos I'd argue that at least the author tried to write a real documentation, which 95% of Go library authors don't do. > the concept of a framework is fundamentally complex and at odds with the goals of Go The famous "You don't need that with Go ™ ". It's more like Gophers hate the word "framework","dependency injection" and "orm". It's hardly a framework, it's a router and a mid…
I didn't mean to hate, shame, or mock anyone. I would rather that programmers who create complex antipatterns stay in other languages that encourage them, and if light critique has that side effect, so be it.
https://github.com/iris-contrib/website
I just submitted a PR to fix a few minor issues. In general, the grammar issues here are really minimal and the page seems to communicate the project and its goals very clearly without being too distracting.
I didn't find any explicit typos, like misspelled words, but I didn't look that hard either, hopefully you can help out!
Earlier quoted context omitted.
I didn't mean to hate, shame, or mock anyone. I would rather that programmers who create complex antipatterns stay in other languages that encourage them, and if light critique has that side effect, so be it.
I'm sure the author would love your help fixing up the typos: https://github.com/iris-contrib/website I just submitted a PR to fix a few minor issues. In general, the grammar issues here are really minimal and the page seems to communicate the project and its goals very clearly without being too distracting. I didn't find any explicit typos, like misspelled words, but I didn't look that hard either, hopefully you can…
I mainly take issue with the proliferation of Go frameworks, especially HTTP frameworks. Frameworks are an antipattern and there are already a huge number of HTTP frameworks that are all incompatible and reimplement the same functionality. I don't think this is useful for the language and in fact think it hurts it.
Earlier quoted context omitted.
Wouldn't trust programmers, who make illogical graphs like that one :D
I wouldn't trust any web framework that isn't yet on https://www.techempower.com/benchmarks It might not be perfect, but it's common ground.
Earlier quoted context omitted.
I'm sure the author would love your help fixing up the typos: https://github.com/iris-contrib/website I just submitted a PR to fix a few minor issues. In general, the grammar issues here are really minimal and the page seems to communicate the project and its goals very clearly without being too distracting. I didn't find any explicit typos, like misspelled words, but I didn't look that hard either, hopefully you can…
Really, the typo thing was not the main point of my original comment, it was just an aside. I'm sorry to anyone I have offended. I mainly take issue with the proliferation of Go frameworks, especially HTTP frameworks. Frameworks are an antipattern and there are already a huge number of HTTP frameworks that are all incompatible and reimplement the same functionality. I don't think this is useful for the language and i…
What is fundamentally wrong with creating a framework with specific goals around performance and API?
If Go's stdlib were so comprehensive such that frameworks were not necessary, I would get your point, but it's my understanding Go exists as a simple language on which to build larger programs, not as a "one true way" language with everything included.
Earlier quoted context omitted.
Really, the typo thing was not the main point of my original comment, it was just an aside. I'm sorry to anyone I have offended. I mainly take issue with the proliferation of Go frameworks, especially HTTP frameworks. Frameworks are an antipattern and there are already a huge number of HTTP frameworks that are all incompatible and reimplement the same functionality. I don't think this is useful for the language and i…
I'm curious, what makes you think frameworks are an antipattern in Go? What is fundamentally wrong with creating a framework with specific goals around performance and API? If Go's stdlib were so comprehensive such that frameworks were not necessary, I would get your point, but it's my understanding Go exists as a simple language on which to build larger programs, not as a "one true way" language with everything incl…
I agree. However, there is a big difference between libraries and frameworks. I believe frameworks are an antipattern in any language, not just Go, but Go's emphasis on simplicity makes frameworks for it especially grating to me.
Rather than poorly summarize, I'll link two of my favorite articles criticizing frameworks; one is humorous [1] and the other is more serious [2].
Earlier quoted context omitted.
You are mostly correctly. There are some things that Go can do to perform better than Java. Go arrays have one less step of indirection compared to Java arrays. And Go allows for more control about the memory layout of structs/classes and arrays.
But it also doesn't perform as well with large data sets and has less compiler optimizations and no JIT. Saying Go is much faster than Java is nonsense.
A JIT is not a performance feature per-se, either. It can be used for runtime code-optimization and -specialization which can improve performance. Some JVM implementations try and do this as well as they can automatically. The stuff they optimize, though, is exactly the kind of indirection that doesn't exist in Go in the first place.
The optimizations `javac` does are one of the few things that allows Java code to run at a competitive speed. And they're mostly trading space for performance, hence the unusually large memory footprint of Java applications.
Earlier quoted context omitted.
Alex Gaynor had an interesting take on this - https://speakerdeck.com/alex/why-python-ruby-and-javascript-... From what I remember - even leaving aside core language speed - the idioms of certain languages lead people to write slow data structures and algorithms. You can write (much) faster Python but it might start to look un-Pythonic. But of course there is the counter-argument - if your web framework is your bottl…
There are tons of blog posts about companies that have switched from Ruby or Python to Go and have been able to massively scale down their amount of servers while handling the same load. Here's one example: https://www.iron.io/how-we-went-from-30-servers-to-2-go/ I don't think it's weird that the web server could be a bottleneck in a web application (even if it is a database-driven app, as most are). Of course, if yo…
FWIW, these cases don't come down to raw rq/s performance, but are more due to RAM usage.
Earlier quoted context omitted.
I'm curious, what makes you think frameworks are an antipattern in Go? What is fundamentally wrong with creating a framework with specific goals around performance and API? If Go's stdlib were so comprehensive such that frameworks were not necessary, I would get your point, but it's my understanding Go exists as a simple language on which to build larger programs, not as a "one true way" language with everything incl…
> it's my understanding Go exists as a simple language on which to build larger programs, not as a "one true way" language with everything included. I agree. However, there is a big difference between libraries and frameworks. I believe frameworks are an antipattern in any language, not just Go, but Go's emphasis on simplicity makes frameworks for it especially grating to me. Rather than poorly summarize, I'll link t…