71–80 of 102 posts
Earlier quoted context omitted.
A Wordpress alternative in Go would be pretty cool. Is anyone working on such a thing?
How would you handle plugins? Some kind of cheap local RPC would probably be fine from both the complexity and the performance POVs.
I actually think that in the long run Rust and Go will have a similar relationship between Ember and React. They'll have fundamentally different approaches, but they'll steal the best ideas from each other (for example, Glimmer is heavily influenced from React) and they'll both end up serving their domains better and maybe overlapping a bit more here and there.
Earlier quoted context omitted.
Coming from a scripting language background Go was like moving into the future: concurrency primitives, static linking, channels, fast compile times, awesome standard lib. Not to mention the fact that go fmt makes everyone’s code look exactly the same. No more weird, personal styles being brought into into source code or pointless discussions of naming conventions or indentation.
Concurrency primitives maybe (though languages had those for 20 years too). But what about static linking, fast compile times and awesome standard lib is like "stepping into the feature"?
Standard lib is just plain awesome. You can build most things right out of the box without searching the web for competing versions of the same thing. Web apps are a great example.
Fast compile times was a feature built into Go from the beginning. Presumably from people frustrated by compile times of large C/C++ codebases [1]. It’s about developer productivity.
1. https://golang.org/doc/faq#What_compiler_technology_is_used_...
Earlier quoted context omitted.
I saw a tweetstorm by a longtime Go user who listed all the flaws and inconsistencies of the language. In the end it didn't look much better than PHP to me. Which is surprising, since PHP is a "grown" language and go has been "designed" by some longtime languages pros.
A lot of complaints usually affect niche or rare use cases in the language (or you learn them fast). Though I guess the same applies to PHP. It's a lot nicer to write webapps in Go though since you have control over global state and not the per-request state of PHP, which makes for some easier solutions to problems (work-queues are easy to implement/use on the server-side unlike in PHP) Also the stricter type system…
Earlier quoted context omitted.
A lot of complaints usually affect niche or rare use cases in the language (or you learn them fast). Though I guess the same applies to PHP. It's a lot nicer to write webapps in Go though since you have control over global state and not the per-request state of PHP, which makes for some easier solutions to problems (work-queues are easy to implement/use on the server-side unlike in PHP) Also the stricter type system…
Comparing PHP with Go it's a bit too much, don't you think? Type system, standard library, concurrency, compilation, packing ... I hardly find similarities.
"For that reason, Some smart Google engineers decided that it’s time to address the limitations of C and C++ by designing a new programming language: Go. [...] Go is based on the C programming family, one of the most widely used programming language trees in the world [...] Go attempts to combine the development speed of working in a dynamic language like Python with the performance and safety of a compiled language like C or C++.We’re hoping Go turns out to be a great language for systems programming with support for multi-processing and object-oriented design, with some cool features like true closures and reflection.”
I was there when it happened, so regardless of the way go is being used and what it's being touted for now, in 2009-2011 it was all about Google's new systems programming language, set to replace both C and C++. And it was very clear that by "systems programming" Pike et. al meant any kind of job that was traditionally relegated to C/C++: http://www.informit.com/articles/article.aspx?p=1623555
Rust came out only slightly later and was also touted as a system programming language. From the the rivalry sprang out.
It turns out that Go's trade-offs and focuses (implementation simplicity, relative familiarity, static compilation, solid tooling, solid stdlib and easy concurrency) fit well for its eventual target demographics of web servers, networking and command line tools. These are all places where C/C++ had some foothold, but more often than not Go was replacing (or competing with) Ruby, Python or Node.
Rust, on the other hand, took over most of C++'s trade-offs and focuses (Zero-cost abstraction, expressive power and full control over memory management) while relatively neglecting I/O, tooling, ergonomics and the stdlib in the beginning. This attracted a very different crowd that looked to solve very different problems.
Earlier quoted context omitted.
A Wordpress alternative in Go would be pretty cool. Is anyone working on such a thing?
Perhaps this: https://gohugo.io/ There are bunch of comparisons Hugo vs Wordpress on internet.
Good static site generators are many. The point of a product might be near-zero transition friction.
Earlier quoted context omitted.
Many controllers are not hard-realtime. Think e.g. of microwave ovens or smart locks. Often you might be willing to trade a 10ms GC pause of Go for much lower chances of memory corruption or crashing compared to C.
I’m developing software for WiFi routers. I would have liked to use Go but the binaries are simply too large and compilation is sketchy for ARM.
Earlier quoted context omitted.
Comparing PHP with Go it's a bit too much, don't you think? Type system, standard library, concurrency, compilation, packing ... I hardly find similarities.
Some don't mind: https://news.ycombinator.com/item?id=13430612
Earlier quoted context omitted.
Many controllers are not hard-realtime. Think e.g. of microwave ovens or smart locks. Often you might be willing to trade a 10ms GC pause of Go for much lower chances of memory corruption or crashing compared to C.
Many controllers have almost zero memory headroom meaning your GC pauses get an order of magnitude slower if not more as you have less than 2x your working set. Also, most of the applications never allocate because they can't even afford the overhead of pooling/freelists that come with a stock malloc implementation.