411–420 of 511 posts
Earlier quoted context omitted.
> But I've used a lot of languages and I never seen concurrency done as easily as shown in that video. So I take it you never used Erlang.
Erlang is big and complicated compared to Go. It's not easy, and besides it is functional (not easy) which already makes it unusable by 90% of people.
Last month I picked NodeJS and build couple of sites with it. This month, I want to pick up something new. I was hesitating between Python and Go. Can you answer couple of questions about Go from someone coming from NodeJS: 1- What is the state of the external Go libraries, especially DB (MySql), caching libraries (memcached), protocol libraries (Oauth). Are they stable 100% 2- How easy is logging and tracing in go?…
Earlier quoted context omitted.
So what, the lack of a mainstream ORM implies "So there is really nothing to learn besides the language itself"? I don't think so. And there's probably more to a lack of an ORM other than "Go is immature." It's a fairly common opinion among the Go community that ORMs are not worth their complexity. I tend to share that opinion myself, after having worked with a few in a couple different languages.
If the language is strictly OO (as Java and C# are) then an ORM is pretty much required. What is the preferred solution in Go? And please don't say writing out raw SQL.
Earlier quoted context omitted.
Mostly because I can't stand Javascript. It makes me cringe just thinking about it. Go is much nicer to work with.
Hey OP! I appreciate your sharing. Since you came from ruby and we're on the topic of the language itself, I'd appreciate your impression of how well Go supports collections. Is there or could one write something like http://underscorejs.org/ ? Can you do this kind of thing? [1, 2, 3, 4, 5].reject {|i| i I did the go tutorial the other day and I became a little worried that one would not be able to do this kind of th…
Earlier quoted context omitted.
The test is in the interpreter, not the compiler to byte-code. Every time the + is evaluated, the interpreter checks for the common case before resorting to finding the first object's method.
Okay, I think I get it now. The check you refer to is done inside the BINARY_ADD implementation. That's why the bytecode is the same for both cases. Am I right?
Earlier quoted context omitted.
If the language is strictly OO (as Java and C# are) then an ORM is pretty much required. What is the preferred solution in Go? And please don't say writing out raw SQL.
I've moved away from ORMs in Java because they don't really solve the problem faced. Hibernate could be a really good solution to providing a blanket system for SQL interaction except for the performance issues. If one was really using Domain objects (not pojos, or dumb DTOs) the typing ability of Hibernate would be great. Unfortunately for simple CRUD apps the issues presented by Hibernate (like loading it in an EAR…
In C# the session management is no big deal: you access everything via the Repository pattern, turn on trait injection and just make sure any repository method that will need a session has a transaction attribute. If you need to do a series of read/writes in one transaction you throw that whole method into the repository class and put a transaction trait on that method.
Earlier quoted context omitted.
Not Invented Here syndrome goes away with general experience. It doesn't come back every time you switch to a new language. Just because I've never written Erlang doesn't mean that I will automatically try to write a random-number generator (say) the first time I need one in Erlang. I have enough experience to look for a library function first. Empirically, NIH tends to be more common in single-language developers, n…
I wasn't talking about NIH syndrome, I was talking about "I don't know that a common library exists for this standard use-case so I'm going to write my own one-off because I have a job to do". I mean, you can google for libraries but sometimes you just don't find them and then find out a few weeks later what you should have used.
Earlier quoted context omitted.
from a testing point of view this looks pretty week. I would not bet my business on something that has not a testing culture.
What makes you say it doesn't have a testing culture? I think you're just trying to justify not using Go and sticking to your choice. I haven't came across any Go libraries without tests.
* gospec seems to be dead/not widely used
* I don't see projects measuring their code coverage
* As pointed out in my first comment, I couldn't find high level testing tools and none of the repliers could name one, too.
If you don't have tests to measure function and performance, any new technology is just playing another round of Roulette and/or "bike-shedding". Most projects and companies — to my knowledge — don't fail because of 30 servers for Rails but in the inability to iterate (to find a profitable business segment) without investing/burning bulkloads of money re-engineering. Therefore any serious business use requires a deep evaluation and comparision with existing methods, especially in the quality of service sector.
The Agile/XP/TDD/BDD-movement was not created because of "bad and slow" programming languages. It's because failure happens all the time if you like or not. It's about dealing with the omnipresent risc and changing specs.
Earlier quoted context omitted.
Updated to generalise a bit more. If this ever came up in code review, I'd probably facepalm pretty hard. http://play.golang.org/p/YUQSZgFx_b
Ha. Yeah, the map() and reject() function defs are fine but the actual usage is a little eye-bleed inducing :)
I went briefly to through the comments, it seems that no-one is bothered with lack of details in this post, things are not logical at all, almost like it was written by PR agency in charge of promoting Go. Except it is established business so I would assume things are true, but real motives are hidden. Go is obviously good language for some specific things, but it's not like ruby is pure trash, how come you did 'ever…
> but real motives are hidden Could you elaborate on this please? Are you referring to the OP's motives of publishing the article? Or of switching to Go? > Go and Rails are so different that there is almost no point in comparing them. Except when one solves the same problem better than the other.