81–90 of 142 posts
Earlier quoted context omitted.
You forgot to mention CUDA, which is trouncing Fortran, C, and C++ in performance and being adopted at a fast rate. Now, one could argue that CUDA is a dialect of C++, but it is much more than that.
CUDA is a special purpose language, the same way that, e.g., VHDL or Verilog are special purpose languages.
Sometimes we get so invested in a language that we forget that it's just a tool, and a good engineer/hacker should try to choose the best one for the problem at hand. Go is just another tool in our toolbox: as the author says it sacrifices some of Python's friendliness and ease of use (but not as much as other compiled/statically typed languages) and features for performance and a solid concurrency model. It's up to…
First of all - yes they're "just tools" and that's pretty much what I said - Go is for servers and it won't "rule them all", and I wouldn't write the obvious if it weren't for the massive Go hype. Another angle though - a language comes at a massive cost of vocabulary (builtins and libraries) which dwarfs the cost of learning a new grammar (easy compared to natural languages though a cost in itself). A language suite…
http://blog.paralleluniverse.co/2013/05/02/quasar-pulsar/
"We’ll start at the end: Quasar and Pulsar are two new open-source libraries in Java and Clojure respectively that add Erlang-like actor-model (and Go-like coroutine/channel) programs to the JVM."
In the beginning i missed repl, but i've realised using repl in the first place was a mistake.. Now i rely on docs(godoc is awesome) and when i need to test something i use go playground.
Despite it being created for Go, I got quite fond of the approach. Nowadays I also use it for Python, C, etc.
Did he say that people looking for faster build times than C++ went to java? They may not have found what they were looking for, in that case... Go does lack a quality [IMO] IDE [re: REPL use is for development], but that can still come with time. Quality GUI bindings can also come with time [how often do you actually use Python for GUI stuff, though...but still nice to have, just not its major use I doubt] Another t…
Another thing you'll miss from Python is accidentally typo'ing variable names and having to discover that only at runtime :) python -m compileall . :)
a = 3 if true: a2 = 4 # lame I know--but beginners like me do it
--Python lets discover your failure at runtime...[as a good dynamic typed language does--Go doesn't FWIW]. It was just from an experience I had with learning Python recently. Now it makes me wonder what his blog post would look like saying things he'd miss going from Go to Python, or "what I wouldn't miss from Python..."
Towards the end of the article there seems to be a confusion between servers and web servers. Yes, Go is nice for writing servers, no, web servers aren't the only things out there doing 'serving' in systems-land. Three examples from CloudFlare all written in Go: 1. Our Internet compression/optimization technology called Railgun 2. Our DNS server 3. Our CA infrastructure All are networked, all are highly concurrent. A…
Is the Lua stuff going away? What are your opinions of Go vs Lua?
> No exceptions [...] If I want higher-level error context I need to propagate the error upwards, with an if at every function call along the way. This is flat out false. Go has fairly standard exceptions (panics), though instead of using try/catch/finally blocks it uses deferred functions that perform a hybrid of the "catch" (if they use "recover") and "finally" functionality. It is a go convention that library code…
So Go has panics and they are _just like exceptions_ in Python? Because to accuse the writer of being "flat out false" these have to be exactly the same and he as to be ignorant to not see the obvious.
Let's say you have some step in your function and you might raise an exception. In Python you'd surround it with try...catch
try:
dosomething()
catch SomeException:
handle_exception()
> there is absolutely no reason, aside from sheer ignorance and not reading even the most basic Go documentation
ignorance? have you read the basic Python documentation, sounds like you haven't
When I read go specs or go vs python comparison, nearly every diff is a specific pain point of our big python code base. No keyword argument? to hell with them. Strict formatting? That should be in python interpreter. No unused import: would have saved our lives. No cyclic dependencies? No inheritance? No exceptions? Great, all of them are maintenance nightmares.
I think the author misses the point. The number one reason Go was created was to build maintainable softwares , the kind Google uses at large. The easiest way to build these are: - Automatic memory management -> GC - Bug catching before the software is run -> Static typing - Overall simplicity -> few features, added only if it is extremely needed The thing is, when you start using Go, you already know its features. T…
Why do I miss the point if, like me , you think Go is the new Java? :-) I think it's exactly that, it works and that's fine, and why the JVM doesn't do cheap concurrency I don't know. If it did Java might have been the new Java :-)
It's ironic that the author dismisses C++ to a small niche: > Those who still stick to C++, after all these years, either really can't live with the "overheads" (real time apps - those are waiting for Rust to mature), or think they can't (and nothing will convince them except a competitor eventually forcing their employer out of business). Yet later he gives a good example for an important area where C++ is still unb…
But it is not used _as_ much as in the past for core business logic. There are legacy system that will run for many years. A lot of web backends are not not in C++ when in the past they were. It was the language to rule them all, but now in some areas others have taken over.
Sometimes we get so invested in a language that we forget that it's just a tool, and a good engineer/hacker should try to choose the best one for the problem at hand. Go is just another tool in our toolbox: as the author says it sacrifices some of Python's friendliness and ease of use (but not as much as other compiled/statically typed languages) and features for performance and a solid concurrency model. It's up to…
I try to advocate polyglot programming - using the best tool for the job - everywhere I go, but unfortunately people are largely allergic to the idea. Most programmers don't want to learn new tools, much less new paradigms or methodologies. Even worse, the management agrees - the upside of building better systems isn't convincing enough to justify a temporary drop in performance while learning. More to the point, I d…