So what comes after Go? I only ask because I figure if I start learning that now, by the time they switch again I will have a fair chance of being competent at it by then...
The March Towards Go
131–140 of 217 posts
Re: The March Towards Go
#132Re: The March Towards Go
#133Earlier quoted context omitted.
Go could be improved in many ways. It lacks facilities that what we consider modern programming languages have, e.g. object-oriented programming, generics. The existing Goland solution to the generics problem is to have an almost duck typing approach of doing everything via interface{}. These are the cons. The pros are of such value that they more than compensate for the cons: first class facilities for building conc…
> The existing Goland solution to the generics problem is to have an almost duck typing approach of doing everything via interface{}. I see this repeated again and again. It's wrong. The "solution" to the generics problem is to not try to do anything that is generic, but do it specific: re-write that sort every time you need it for a new type. People who have some experience in Go seem to tell that when you go this p…
I knew about this solution. It's just that my inner Ruby dev screams "DRY!". Obviously it's so repetitive that it would be a bad sign in other languages.
I like more the solution used by the sort package. You can write generic code that delegates specific type code to a few well-defined functions, like ones that sort.Interface defines.
More here: https://code.google.com/p/go-wiki/wiki/GoVsGenerics
Re: The March Towards Go
#134Go may well be better for many apps than js or C++, but there are other languages out there. If you're looking for a new language it's worth considering more possibilities, e.g. see http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r...
This blog post misses a very good Python replacement, namely Nimrod ( http://nimrod-lang.org ).
I do like Nimrod. It has been around for a while. Has good syntax, good semantics (things it operates with). Very fast.
Sadly it doesn't have the advocacy and hoard of developers supporting it and writing libraries for it. Certainly no big company with billions of dollars of revenue. It is unfortunate.
I feel like Google should have just taken it and used it as Go back then. I would have been a good choice.
There is also GNOME's Vala language. More focused on GLib but the idea is the same. C# like language compiles to C. Good performance. But again kind of fringe.
This "fringe-ness" in longer term translates in less libraries/frameworks. With Python if I am starting on something new, I know I can probably find someone that wrote a library related to it. Scientific computing, AI learning, graphics, GUI bindings, http parsing, WSGI middleware, strange protocol parsers, libraries on top of C libs (parse .pcap files) and so on. All are just one search and download away.
With Nimrod (or any new language) I am afraid I would be writing those by hand.
Re: The March Towards Go
#135Earlier quoted context omitted.
Python is also slow.
No, pretty fast. Having used it for 10 years. Never had problems with its speed.
No seriously, also having used it for 10 years it's an issue for python. Three quick personal examples, though I've dealt with a number more:
1. Python web frameworks
http://www.techempower.com/benchmarks/#section=data-r9&hw=i7...
Carefully configured Flask can get up to 1/3rd the speed of other web frameworks. But misconfigure it, use an ORM, or if you're on django, you're serving 1/10th as many requests/sec with significantly higher latency than other languages.
2. Templating
https://stackoverflow.com/questions/1324238/what-is-the-fast...
Template rendering takes an appreciable amount of time. I had to replace django's (slow as shit) stock templates with jinja2 on a project because it was taking tens of seconds to render a very large page. Jinja is far faster, but it's still slow enough that I had to add a caching layer to a website that shouldn't need one.
3. Numerical shit
I implemented a video processing algorithm from a paper for a computer vision class. Python's scientific and numeric libraries were sick and made prototyping delightfully easy--then the final runs on the full dataset took forever. What I re-implemented in C++ was >10x faster. Vectorization and other tweaks can make python numerics go faster, but it's a pain in the ass. One of the goals of the Julia scientific programming language is to make loops fast enough that code doesn't have to be manually vectorized.
Re: The March Towards Go
#136I don't understand why people like go. It seems to be missing a lot of features and be pretty ugly and painful. I guess compared to javascript I can see the advantages though
I tried to like Go. I was allured by the native compilation and quite low memory footprint while still being quite high level, but I just can't. I can't stand it forces you to use K&R style. I can't stand the verbose error handling. I can't stand the inconsistency in the built-in types and libraries. I hate that unused variables and imports are a compile error which is just stupid and kills all the fun in programming…
Have you looked or tried Erlang? I like its error handling the best (isolate the fault). At least it handled and manages issues with large concurrent backends well.
Re: The March Towards Go
#137Earlier quoted context omitted.
Go could be improved in many ways. It lacks facilities that what we consider modern programming languages have, e.g. object-oriented programming, generics. The existing Goland solution to the generics problem is to have an almost duck typing approach of doing everything via interface{}. These are the cons. The pros are of such value that they more than compensate for the cons: first class facilities for building conc…
> My personal dream endgame would be a dynamic language, such as Python or Ruby, that includes the concurrency features such as goroutines and channels. Directly as language features. AFAIK, the existing GIL in the reference Python and Ruby interpreters makes adding true goroutines impossible. Have you had a look at Erlang and Elixir? The former is not as dynamic as Ruby (not much is), but it's a nice environment, an…
I second this recommendation: I've started a project with Elixir two weeks ago, and so far I really love it. As far as syntax goes nothing beats the elegance of Python, but in terms of overall application architecture OTP [1] is just miles ahead.
That said I can definitely imagine picking up Elixir for a purely imperative/OOP programmer being quite an undertaking. But definitely worth it.
[1] http://www.erlang.org/doc/design_principles/users_guide.html
Re: The March Towards Go
#138Earlier quoted context omitted.
> missing a lot of features Not a lot of them - just some. And the missing ones, a lot of people don't miss anyway. It also has things others languages don't - fast compilation, a big company behind it (while staying opensource), and simplicity. > be pretty ugly and painful Subjective. I like how it looks and have no pain. > compared to javascript I can see the advantages though It is not just "better than javascript…
> has things others languages don't - fast compilation Never understood this talking point. What language other than C++ (and C to some extent) doesn't have fast compilation? And compared to these languages Go gets most of its compile speed simply by doing a really poor job optimizing. Compare times for -O0 and -O3 on other languages to see most compile time is dominated by optimizations. Is this supposed to convince…
I think this depends strongly on your development style.
If you come from the world of scripting languages, a common style is "write between one and twenty lines of code; run tests; edit three lines; run tests...", where "run tests" might literally be that, or might just be running the code to sanity check that things are not too broken. In this style, even a twenty second delay would become very painful.
I think people who learned on C, C++ or Java tend to write much larger pieces of code in between run attempts, simply because it takes (or took) a while to check your work, instead of being effectively instantaneous. I know at a previous position where I did some Java development, the "tomcat stop; ant remove; ant clean; ant install; tomcat start... okay, NOW you can test" was quite difficult to develop against iteratively, sometimes being measured in minutes instead of seconds.
Re: The March Towards Go
#139Earlier quoted context omitted.
This blog post misses a very good Python replacement, namely Nimrod ( http://nimrod-lang.org ).
I do like Nimrod. It has been around for a while. Has good syntax, good semantics (things it operates with). Very fast. Sadly it doesn't have the advocacy and hoard of developers supporting it and writing libraries for it. Certainly no big company with billions of dollars of revenue. It is unfortunate. I feel like Google should have just taken it and used it as Go back then. I would have been a good choice. There is…
> There is also GNOME's Vala language. More focused on GLib but the idea is the same. C# like language compiles to C. Good performance. But again kind of fringe.
It seems like native imperative languages with automatic memory management has just fallen by the wayside as history has progressed, or have been relegated to niches. I wonder why that is.
Re: The March Towards Go
#140Go may well be better for many apps than js or C++, but there are other languages out there. If you're looking for a new language it's worth considering more possibilities, e.g. see http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r...
Incidentally, your link includes a great example of Go's error handling - which is inevitably what actually happens in languages without exceptions: errors are silenced and the program marches on, each step making less sense than the previous. It's a good talking point that you can always check error values - but it never really happens, in part because library designers try to avoid putting the burden on themselves…
>It seems that having exceptions in the language is a great predictor for libraries/built-ins barfing upon bad input vs silently producing garbage
Maybe so, but having exceptions in a language is also a good predictor for the misuse of exceptions for purposes other than error handling. For instance, Python has the StopIteration exception to signal the end of an iteration.
Exceptions force API designers to decide whether or not a situation is exceptional enough to force a stack unwind on the caller's end. That's not something that's necessarily decidable from the point of view of the library.
For instance, say you have a function http.get(url). Should a 404 response automatically raise an exception? What about a 301? A network issue? Surely, for a crawler, a 404 is not exceptional enough to merit a hidden goto that unwinds the stack frame (by default). The designer of the http library cannot decide which status code is exceptional in every application.
It's similar with the results of SQL statements, file system access and all sorts of other IO related stuff.
It seems to me that the more complex a system is, the more it needs a very specific error handling strategy anyway and doesn't benefit from library designers' opinions about what is and isn't worth a stack unwind.
That said, I do hate seeing
if err != nil {
return nil, err
}