Hacker News new | comments | show | ask | jobs | submit | kc5tja's comments login

Goodness, I'm confused. I'm going to need a lot of time to digest this. That said, much discussion about ideal way of writing Gophercloud happened on the #go-nuts IRC channel, and nobody objected to what I have now as being unidiomatic. You're the first!

Deeply nested closures are definitely a problem, but I usually solve that by factoring closures out into top-level functions of their own.

That said, one of Gophercloud's goals is to be as idiomatic as possible. Are you available on #go-nuts if I have questions? I'd like to play with this technique some more and get a feel for it before applying it to (and risk breaking) gophercloud's existing API.

-----


Oh, I'm thick! I see what's happening now!

The problem is it doesn't produce any gain in clarity for the purposes I'm using it for. I think for the acceptance tests, it's use is fine.

I can see if it were part of the public API, there's an argument that an interface could be used, but even there, I'm not sure it'd aid readability.

Semantically, however, they're of course identical.

-----


yeah, to be honest, it may have been eggregious of me to call how I did it idiomatic. There's a lot we just don't have idioms for. Anyway, callback chains tend to be uncommon; that's just one way to avoid it. There's a handful of ways you could write this. Generally if you can expose functionality through methods, things tend to work out better in the end since you can transition into interfaces more readily. I'm jordanorelli in #go-nuts.

-----


Both Erlang and Go's concurrency models are strongly influenced by Hoare's work in Communicating Sequential Processes. That certainly qualifies. You appear to be interpreting "some attributes" as a deep-dive analysis into the unique traits of what makes Erlang, well, Erlang. That was never the intention, and I'm not sure what motivated this.

Actor model libraries exist in various states of maturity for Go, as well.

-----


Both Erlang and Go's concurrency models are strongly influenced by Hoare's work in Communicating Sequential Processes. That certainly qualifies.

Erlang uses the actor model, while Go uses (a modified version of) CSP. Earlier versions of CSP were more like the actor model in that they did not introduce a level of indirection (the channel). But it's not the same concurrency model.

You appear to be interpreting "some attributes" as a deep-dive analysis into the unique traits of what makes Erlang,

What else am I supposed to do? Otherwise, it would be a statement as meaningless as 'Haskell shares some properties with Algol 68'. I am pretty sure it does.

That was never the intention, and I'm not sure what motivated this.

Erlang is well-known for its concurrency features and the reliability provided by the actor model (including supervision, etc.) (e.g. in telephone systems). It is quite easy to read the quoted sentence as an attempt to give a good reputation to Go by comparing it to Erlang. I only question if such a comparison is warranted.

Actor model libraries exist in various states of maturity for Go, as well.

Well, if they are available in various states of maturity, I am interested to know which one is the most mature. Does it cover most of the functionality of Erlang and Akka?

(The most interesting package that I found some time ago was a binding against the Erlang C nodes functionality.)

-----


I'd also like to point out that having a base-line level of functionality often allows for domain-specific extensions to be written, either as adjunct libraries (c.f., libcloud and rackspace-monitoring libraries for Python), or as integrated extensions in succeeding versions (how Emacs evolved over time).

You're right to think it's impossible to keep up; even getting this far, I've heard rumors and tremors about up-coming V3 APIs in several areas. I'm sure by the time V3 support is contributed, V4 will be on the drawing board. Thankfully, the general availability of a V3 API does not usually preclude the continuing support for V2.

All we can do is deliver value to our users in a consumable format while trying to remain aware of any changes in our ecosystem.

-----


I reached out to the gcloud team by opening a Github issue making them aware of Gophercloud's URL. I'd love to see more contributors to Gophercloud. So far, though, haven't heard anything back.

We're currently ahead of gcloud in that we have working code for server creation and actions. Much yet remains to be finished/implemented, however.

-----


That's a positive for Ruby only when you're not running on a cloud server, or when you are cost-conscious about the amount of electricity you're sucking in a data center somewhere.

That being said, that Ruby is 10x slower than Go isn't that much of a surprise. It's not a string-interpreted language like the BASICs of old. It's interpreting byte-codes, and anyone who's ever written a 6502 or Z-80 emulator (essentially the same thing) can tell you, on average, most byte-codes take 10x as long to run as the corresponding function written in in-line C.

Computer science -- it works!

-----


If I may ask, how long ago was this? Thanks.

-----


While Gorax isn't on the "official" list of bindings supported, I'm taking it upon myself, as a Racker and Go enthusiast, to maintain the Gorax project.

Please see the project page at github.com/racker/gorax. Thanks!

-----


Hello; Sam Falvo here, a Rackspace quality engineer. I'm working on the Gorax project to offer Go bindings to Rackspace's APIs. I encourage you to watch the github.com/racker/gorax project to remain informed of updates.

Progress is kind of slow at the moment, but is proceeding more or less steadily. It's also the newest language binding, so it will of course not be as feature complete as, say, the Python or Node bindings.

-----


Thanks, Sam! I'll watch github project for updates.

BTW, Mark Internate is an old friend. Tell him I said Hi.

-----


I have to go through several levels to do that, but I'll try. :)

Just a head's up though -- I'm considering migrating the repository to the github.com/rackerlabs organization within a week or so, for consistency with other, more officially supported, API bindings.

-----


salim! It's great to hear from you, how are things? We are making great strides at Rackspace.

-----


Ahh, remember back in the good old days when programs had .PRG extensions or file-types? Nobody cared what language a program was written in back then either, as long as it just worked.

Computers and programming don't have to be so complicated. People make them complicated.

-----


Correct definition of 'cat' -- a tool to concatenate one or more files sequentially into a single output stream. E.g., cat file1 file2 file3 >output-file

what is wrong with... -- "grep word file" takes fewer keys to type and uses fewer resources (important on a heavily loaded server with tons of processes which may well prove compromised and you're trying to peruse the logs for evidence. Been there, done that, got the t-shirt, and donated it to the local shelter).

-----


People nag me about cat'ing stuff to grep, and I explain that it's just easier to edit the pattern when it is the last argument to the command. Also it of course fits better in the toolchain when I need to replace the input or the grep with something else.

-----

More

Applications are open for YC Summer 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: