Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The March Towards Go

zef.me

Post reply on HN
Print view View original

191–200 of 217 posts

Re: The March Towards Go

#191

Post by randallsquared »

saryant wrote: post #188
randallsquared wrote: post #183

Earlier quoted context omitted.

> You seem to be assuming that the only way to do JVM stuff is considering all the difficulties that enterprise Java shops with legacy projects put up with. Ah, that's because that was the only place I've had much experience with Java and Scala. We wanted to use Elasticsearch (Java) from our CMS (Java), and the recommended way to do that (at the time: embedding ES in your application as a search-only node) turned out…

Why wouldn't you just run ES as a standalone server and use its REST API? ES is a core part of the stack at the startup I work at and it never would've occurred to us to run it as an embedded service.

You'd run the data nodes as standalone servers, but the recommended way to talk to ES from your Java app was, at the time, to embed ES as a non-data node in your app, which means that you could talk to ES in-process, and the local ES would be part of the cluster, just pass on queries and data to the data nodes. This was 2011 (0.18.x or 0.19.x, I think), so maybe that's not the recommended way any longer. The REST interface was also available, and recommended for anything that wasn't Java, and that's what we ended up using (but given the opportunity not to write the code that interfaced between database and ES in Java, we took it, and wrote that in PHP, with just a tiny bit in Java to push a job on the queue).

It looks like that's still what's happening in the Java API: http://www.elasticsearch.org/guide/en/elasticsearch/client/j... I'd like to reiterate that moving our app to a more recent JDK would have also been a good solution, except that we didn't have the dev and qa resources at the time to devote to that.

Re: The March Towards Go

#192

Post by jacques_chester »

Rapzid wrote: post #46
beck5 wrote: post #9

There are a couple of things which have stopped me getting into go which I am ignorant about. - Lack of decent IDE with intellisense/good refactoring support. - Libraries seem to be globally shared between projects like rvm rather than in the project like nvm. Am I wrong, misguided or out of date on these things?

I use LiteIDE to good effect. It has a few kinks to work out but is generally everything I need. The Go intellij plugin is supposed to be good too from what I hear. Packages are shared across projects in the same gopath, you could run separate gopaths for isolation.

I've found the Go plugin for IntelliJ to be flaky around the things I most want. Particularly refactoring. It would also be nice if it borrowed the behaviour of the sublime and vim plugins and fmt'd code on save.

Re: The March Towards Go

#193

Post by jacques_chester »

otikik wrote: post #91
cgag wrote: post #65

Earlier quoted context omitted.

Even if it were true that it were overly complicated, that wouldn't change the fact that it's much more powerful than Go's. “When I work at this system up to 12hrs a day, I’m profoundly uninterested in what user interface a novice user would prefer.” —Erik Naggum Are you using visual basic because you could pick it up in 2 days instead of taking a month to learn Go? It's easy to learn because it doesn't do anything i…

> visual basic Bringing The Language Which Shall not Be Named to the discussion is a low blow. But I deserve it. My phrase about overcomplication was flamebaity and uncalled for, and I apologize. > you're missing out on simple beautiful abstractions like map and filter The thing is, in Go, those take almost as much space as a plain for loop. I know, you will tell me "that's because Go's too verbose". I will grant tha…

interface{} doesn't give you generics. The point of generics is to give you two distinct things:

1. You can write code that performs identical logic for a range of different data types, without having to know what they are.

2. That code can be checked for type safety.

interface{} gives you half of 1. You can write code that performs common logic and takes an interface{}, but then that code has to manually switch on type, or convert type before running.

Which gives you trouble with 2. Once you don't have a distinct type, you can't check for safety. All the compiler can do is check that an interface{} is passed in; which is a pretty weak guarantee. Meanwhile, in languages with generics, the you can write a generic method that uses the + operator and the compiler can check whether it works for numbers (OK), strings (OK), HTTP servers (uh oh, stop the bus!)...

Re: The March Towards Go

#194

Post by [deleted] »

rakoo wrote: post #122
ovi256 wrote: post #6

Earlier 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…

[deleted]

Re: The March Towards Go

#195

Post by andrewvc »

stcredzero wrote: post #169
skrebbel wrote: post #33

Zef writes this as if it's completely amazing that people are leaving Node for Go. Node is based on JavaScript. There are arguably more things wrong with JavaScript than with any other popular programming language, as evidenced by book titles like "JavaScript, the good parts". This is common knowledge; we're all trying to do good work despite JavaScript, seldom because of it. So Node: it's fast, we can share code wit…

The one big substantive point was about callback hell. Coroutines and channels are exactly what's needed to solve that. Add in a minimalist language design focus on programming in the large, and you have a prescription for what ails Javascript on large projects. This doesn't make Go a silver bullet. (So don't make that mistake, please!) It just happens to be the right kind of tool for two of the more salient problems…

I agree that callback hell sucks, and promises are a vast improvement, but still shitty. Coroutines and channels are not obviously 'just what's needed' in my opinion however.

I think they're part of a larger picture. Mature languages should have multiple concurrency models available for different tasks. Clojure, for instance, supports coroutines, threads, and multiple other flavors of concurrent programming.

There is no silver bullet, polyglot concurrency is the future most likely.

Re: The March Towards Go

#196

Post by sergiotapia »

teacup50 wrote: post #149
thomseddon wrote: post #50

Earlier quoted context omitted.

You obviously don't know TJ... https://github.com/visionmedia http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-...

What am I supposed to take away from these links, other than the technical culture's self-defeating tendency to lionize individuals to fit a hero narrative?

If you read the second link, it's presented that that guy is actually a group of people working under a phony name, to give the cult a "hero". Drum up hype, etc.

It's been done before too! http://en.wikipedia.org/wiki/Nicolas_Bourbaki

---

Nicolas Bourbaki is the collective pseudonym under which a group of (mainly French) 20th-century mathematicians wrote a series of books presenting an exposition of modern advanced mathematics, beginning in 1935. With the goal of founding all of mathematics on set theory, the group strove for rigour and generality. Their work led to the discovery of several concepts and terminologies still discussed.

Re: The March Towards Go

#197

Post by pyotrgalois »

davidw wrote: post #72
ovi256 wrote: post #6

Earlier 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 would like to mention LFE. Lisp Flavored Erlang (http://lfe.io/) is a great addition to the Erlang/Elixir world/ecosystem. Go on, test it out!

I work as an Erlang dev. It is really awesome. It has a simple and consistent syntax (even if don't like the comma, semicolon and period terminators), the most powerful native concurrency semantics I know, the best error detection and handling semantics, pattern matching (you make the compiler work for you), an awesome virtual machine that took correct design choices (gc per process, iolists for concatenating strings), incredible tracing support, good support for connecting with other programming languages, a good optional type system (Dialyzer, http://learnyousomeerlang.com/dialyzer) for detecting type errors and good patterns as supervisor, gen_server and gen_event . It also has a vibrant community that has created good libraries like Proper (QuickCheck-inspired property-based testing tool for Erlang) and Cowboy (simple http server).

I have worked with C, C++, Java, Ruby, Python and Javascript/NodeJs. I really like Python and Ruby as general programming language and for creating prototypes, but I would definitely use Erlang for any real backend project.

Re: The March Towards Go

#198

Post by adamlett »

flaie wrote: post #123
adamlett wrote: post #77

Earlier quoted context omitted.

> There are minor details wrong with JavaScript. Normally you don't encounter them in daily use. If you really believe that, I can only assume that you either don't have very much experience with Javascript and haven't yet been burned (or haven't yet discovered that you've already been burned), or that you don't have any experience outside of Javascript and therefore are not aware that languages exist that have all t…

> Yes, there are languages that are worse than Javascript to work in (I'm looking at you Java and PHP) Java has an enormous ecosystem, is fast, is stable, has static typing, has more tooling than anything else, is easier to learn, does not have all the gotchas that Javascript has. I don't consider Java a worse language at all. I use Java since a decade, and frankly I don't understand that rage against it while it is…

I agree that Java has relatively few WTF-level language design flaws. So on that count it wins against Javascript. But Java also doesn't have the expressive power of Javascript that comes from having 1st-order functions. Static typing is nice in principle, but the verbosity of Java's type system makes programming in Java feel like running in wet cement. I respect that there is a humongous ecosystem surrounding Java, but that doesn't really speak to whether the language is pleasant to work with or not.

Re: The March Towards Go

#199

Post by stcredzero »

andrewvc wrote: post #195
stcredzero wrote: post #169

Earlier quoted context omitted.

The one big substantive point was about callback hell. Coroutines and channels are exactly what's needed to solve that. Add in a minimalist language design focus on programming in the large, and you have a prescription for what ails Javascript on large projects. This doesn't make Go a silver bullet. (So don't make that mistake, please!) It just happens to be the right kind of tool for two of the more salient problems…

I agree that callback hell sucks, and promises are a vast improvement, but still shitty. Coroutines and channels are not obviously 'just what's needed' in my opinion however. I think they're part of a larger picture. Mature languages should have multiple concurrency models available for different tasks. Clojure, for instance, supports coroutines, threads, and multiple other flavors of concurrent programming. There is…

> polyglot concurrency is the future most likely.

One kind of "polyglot concurrency" was the precisely problem of the past! In fact Rich Hickey says himself: You can do concurrency in Java with semaphores and such, but you end up doing some sentinel-thing that's somewhat specialized for your particular subsystem. Then you have to interface with this other subsystem...implement this new feature...then several months later you have a bug introduced because these weren't put together correctly.

In a large Clojure project, you should pick a particular way of doing things, then maybe allow a wrinkle or two, then be consistent about it throughout your project, or at least in that subsystem. Maybe you make your entire model an Atom and have a few FIFO queues for information coming in and going out? What you don't want to do then is to mix in transactional memory or Agents. Otherwise you can find yourself back in the "polyglot" mode of Java. With Go, you have a few flexible primitives from which to produce concurrent systems, but the same thing goes here too. You need to pick a few patterns and stick with them. Otherwise you can make your life much harder.

However, when you start going parallel, whatever you have chosen can go pear-shaped for some hard to fathom reason. Go is no better in this regard.

Re: The March Towards Go

#200

Post by stcredzero »

adamlett wrote: post #198
flaie wrote: post #123

Earlier quoted context omitted.

> Yes, there are languages that are worse than Javascript to work in (I'm looking at you Java and PHP) Java has an enormous ecosystem, is fast, is stable, has static typing, has more tooling than anything else, is easier to learn, does not have all the gotchas that Javascript has. I don't consider Java a worse language at all. I use Java since a decade, and frankly I don't understand that rage against it while it is…

I agree that Java has relatively few WTF-level language design flaws. So on that count it wins against Javascript. But Java also doesn't have the expressive power of Javascript that comes from having 1st-order functions. Static typing is nice in principle, but the verbosity of Java's type system makes programming in Java feel like running in wet cement. I respect that there is a humongous ecosystem surrounding Java,…

Static typing is nice in principle, but the verbosity of Java's type system makes programming in Java feel like running in wet cement.

So then programming in Java with a powerful IDE is like running in wet cement with bionic stilts? I think this is actually an apt analogy, especially for when things don't work quite right or when things get a bit laggy.

Post reply on HN