Sweet, I'll stick to learning Elixir with some (Erlang)!
A year with Go
151–160 of 235 posts
Re: A year with Go
#152It's amazing how Go caught on. It's not well designed -- lots of special cases reserved just for the compiler, some bizarro decisions, etc. It's not modern (with the possitive associates of modern, not fadish, and modern being "the last 30 years of experience" which is still like a millenium in IT years). It's implementation is not great either. Not a very good compiler, not a very good GC, not good tooling. My theor…
> It's easy to get started with, and made converts from scripting languages feel empowered, as if they were "real programmers" writing C, what with "pointers" and static types.
What is wrong with this? Exposing people to pointers and static types might give them confidence when writing or reading in "real programmers" code in C
I find the level of sneery nose turning in this thread quite abhorrent to be honest.
Re: A year with Go
#153I think the author gets closest to the mark in the Conclusion, but still falls short. Go is very attractive as an "upgrade" from Ruby/Python or Java. It's a good replacement for the interpreted languages when speed/performance matters and it makes the async paradigm feel much more accessible. And compared to Java, the fact that Go compiles to a native binary is a huge benefit. It's not a replacement for C or a good "…
> And compared to Java, the fact that Go compiles to a native binary is a huge benefit. I'm baffled by this. I've been deploying Java applications for years, and this has literally never been a problem. You build a WAR (or EAR, or uberjar, or distzip, or whatever). You install a JRE on the machine. You deploy. You're done. It's never been a problem for me, and it's not something that's talked about as a problem in th…
I suspect this comes from classic Java setup of using an application container like weblogic, websphere, JBOSS or web containers like Tomcat.
Re: A year with Go
#154Earlier quoted context omitted.
> You install a JRE on the machine. You deploy. That's two steps. The first one can ruin your day.
How so ? It takes minutes to install it. Just download it, copy it and set JAVA_HOME to make it easier for other applications. I've done this on hundreds of servers during my lifetime and never once had an issue.
Oh, look, there's already an antique jre installed on my os, not compatible with the particular jre needed by this application, which I first need to uninstall. And then hope that it doesn't break anything else in the process, because I haven't been following the minutae of java development environments for the last n+1 years...
I think it falls solidly in the "easy if you know it, and a wasted q hours if you don't" category.
Re: A year with Go
#155Earlier quoted context omitted.
> If you were a strong C, C++, Java, Scala, Clojure etc > developer you could equally deliver a highly scalable > solution in 2 hours. I guess the point is, no, you couldn't. An equivalent solution would be less robust/reliable or take (much) longer. Or both.
With some of this languages it would have been much faster AND much more reliable.
> With some of this languages it would have been much
> faster AND much more reliable.
Re: A year with Go
#156I could be wrong, but I feel like when people talk about how great the Golang tooling is, what they're really saying is "the compiles are instantaneous". I'm sure he's right that the coverage tool isn't 100% perfect, or even 60% perfect. OK. Fine. The compiles are instantaneous . Write a better one! Golang is not an especially impressive programming language --- as a language. But it seems to me like it is an undenia…
> I'm sure he's right that the coverage tool isn't 100% perfect, or even 60% perfect. OK. Fine. The compiles are instantaneous. Since when was compile time an interesting aspect to judge a programming language? More in the "nice to have" category, especially if your program is not 1 million lines and/or your language's compiler doesn't provide some modularity in this regard.
Where do you think the Turbo in Turbo Pascal comes from?
Re: A year with Go
#157I could be wrong, but I feel like when people talk about how great the Golang tooling is, what they're really saying is "the compiles are instantaneous". I'm sure he's right that the coverage tool isn't 100% perfect, or even 60% perfect. OK. Fine. The compiles are instantaneous . Write a better one! Golang is not an especially impressive programming language --- as a language. But it seems to me like it is an undenia…
> I'm sure he's right that the coverage tool isn't 100% perfect, or even 60% perfect. OK. Fine. The compiles are instantaneous. Since when was compile time an interesting aspect to judge a programming language? More in the "nice to have" category, especially if your program is not 1 million lines and/or your language's compiler doesn't provide some modularity in this regard.
He is not talking about a "programming language", he is talking about "programming language tooling". So yes, compile time is an valid and interesting aspect to judge a programming language tooling ever since the beginning.
Re: A year with Go
#158Today, I got a request for a secure message passing service from our CTO. My group, which is a small team of 2 *nix geeks in a company with ~20 mostly c# developers, has become a bit of a skunkworks operation as we have been responding to external constraints and forced to move quickly. I was able to implement the service per the provided spec in 179 lines of Go in about ~2 hours. Stress tests passed. The job is done…
> I don't care for Haskell for anything remotely related to "work"
Why not? Haskell seems perfect for this task. It has fast, robust and safe concurrency and GHC's IO manager is highly optimized and insanely fast.
Re: A year with Go
#159Earlier quoted context omitted.
Why don't they just combine the JRE and JAR file? Then I can be sure it works when I download it.
For the same reason you don't deploy Windows, BSD and Mac OS X binaries of your Go program to a Linux server.
Yeah I use the Linux binary, I'm not sure what you're saying here.
Re: A year with Go
#160Earlier quoted context omitted.
One of the most unhelpful things about Go's pointer syntax is that it collides with HN's italics syntax. Hence, in your second paragraph, i see declarations which differ only in the slope of the type. Really, does nobody think of this when designing a language?
Are you seriously suggesting language designers should care about every sort of markdown syntax that exists when determining how a language looks syntactically? Take a step back and think about your statement...
Yes this was agreed on HN a few weeks ago. Maybe you missed the discussion "proposal for all new syntax to be HN markdown compatible"..?
Try adding /s in your head and read again...