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

181–190 of 217 posts

Re: The March Towards Go

#181

Post by realrocker »

skrebbel wrote: post #179
realrocker wrote: post #67

Earlier quoted context omitted.

What part of the article did you read as "Go is a silver bullet? I read it as a list of articles about people/companies who are switching to Go with each giving their reasons for adoption.

No part in particular - I don't disagree with Zef or the people he quotes. But the entire article does have this "look, all these smart and influential people are ditching $THING for Go, you should too!" feel to it. They're ditching stuff for Go for the particular kinds of problems that Go is good at . This is a subtle but important distinction that Zef isn't making, so I figured it was a useful addition to the debat…

In my opinion, this comment is a better addition to the debate.

Re: The March Towards Go

#182

Post by pjmlp »

Dewie wrote: post #139
rdtsc wrote: post #134

Earlier quoted context omitted.

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.

Java happened. Sun took the JIT from SELF and everyone went JIT, repeating the VM everywhere from the P-Code days. Forgetting the native wave that followed.

However Java and C# do have quite a few native compilers available. They just tend to be forgotten on discussions about them.

Re: The March Towards Go

#183

Post by randallsquared »

DCKing wrote: post #178
randallsquared wrote: post #165

Earlier quoted context omitted.

I meant only that if you want to use Scala, you'll inevitably have to also know Java. It's two languages for the benefit of one. The JVM comes with its own issues: which JDK do I use[1]? What happens when one library I want to use recommends a different JDK than another library I want to use? Build tools questions: ant, maven, gradle? Oh, I need to learn Groovy, too? Three languages for the benefit of one. Yay. There…

Now I don't know if it's intentional or not, but many things you are saying are just FUD. 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. That is far from the truth, as any tutorial for Spray, Play or Akka could tell you. > Which JDK do I use[1]? The Oracle JDK (which is the same as OpenJDK FYI). > What happens…

> 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 to be infeasible, due to ES and the CMS (which was started in 2006ish) being unwilling to share any specific JDK without a lot of code changes to the CMS. We ended up building a system involving RabbitMQ and a thousand lines of PHP, as the easiest solution. :(

So, yeah, I recognize that a lot of my bad feelings about JVM languages are not particularly relevant to green-field development, whether in Java or Scala. I just got ranty. Sorry.

Re: The March Towards Go

#185

Post by bpicolo »

lumpypua wrote: post #135
rdtsc wrote: post #121

Earlier quoted context omitted.

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

Yeah, there are tradeoffs. SqlAlchemy is by far the most pleasant and thorough ORM to work with, for example. For any language. Full transactional support + every other feature you can dream of.

Re: The March Towards Go

#186

Post by nawitus »

adamors wrote: post #154
nawitus wrote: post #84

Earlier quoted context omitted.

TypeScript solves JavaScript's type problems pretty well, it's worth a look.

Does it play nice with Javascript frameworks like Angular?

Yes, there are type definitions for most popular JavaScript libraries.

https://github.com/borisyankov/DefinitelyTyped

Re: The March Towards Go

#187

Post by Dewie »

pjmlp wrote: post #182
Dewie wrote: post #139

Earlier quoted context omitted.

> 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.

Java happened. Sun took the JIT from SELF and everyone went JIT, repeating the VM everywhere from the P-Code days. Forgetting the native wave that followed. However Java and C# do have quite a few native compilers available. They just tend to be forgotten on discussions about them.

> However Java and C# do have quite a few native compilers available. They just tend to be forgotten on discussions about them.

Are there any viable ones for java? It would be pretty cool if one could leverage some of the java ecosystem without having to include a vm. EDIT: I'm guessing that making command line utilities would be more viable, for example.

Re: The March Towards Go

#188

Post by saryant »

randallsquared wrote: post #183
DCKing wrote: post #178

Earlier quoted context omitted.

Now I don't know if it's intentional or not, but many things you are saying are just FUD. 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. That is far from the truth, as any tutorial for Spray, Play or Akka could tell you. > Which JDK do I use[1]? The Oracle JDK (which is the same as OpenJDK FYI). > What happens…

> 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.

Re: The March Towards Go

#189

Post by tokenizerrr »

Karunamon wrote: post #157
rdtsc wrote: post #151

Earlier quoted context omitted.

Because it hides errors instead of helping the developer find them

Are JS developers often adding empty arrays and empty objects together? This seems more like a corner case than a real issue. (Not snarky - I don't know JS)

No. You generally only add numbers and strings together.

Re: The March Towards Go

#190

Post by tete »

I agree. JavaScript is weird. I think ECMAScript will make a lot things better, but it will still be a couple of months and it still won't fix it all - still a huge step of making it a really usable language for many things.

Node.js is becoming mature, less trendy. I really find it weird how people compare it age wise with Go. JavaScript is way old than Go or other languages. V8 is also older than Node of course. ECMAScript didn't have breaking changes in a really long time. There are many, many implementations. SpiderMonkey has been used on the server side for over a decade now.

Go looks great. There are some rough edges though and whether really good solutions will build up for these things is a really interesting thing to look at.

It is really nice to see Node.js, Go and Rust emerging in amazing ways, all of them fixing problems in amazing ways. I love how great concepts, like node.js streams and pipes are copied to Go and Rust in ways that match their styles, not just blindly.

All these things even influence languages like Java and C++. Who would have known only a couple of years ago that things would emerge in such ways and that it needs some projects with the idea of yet another programming language. What is even more interesting is that a lot of concepts actually stem from Perl... well, not necessarily the language itself, but libraries, modules or Perl6, which arguably was/is a really ambitious research project. It's a bit how many concepts took ages to be ported from Plan 9 to other operating systems.

Anyway. It is great to see how people nowadays look at other projects and don't judge by first impression anymore.

At least it seems like it. Node.js looked extremely awful to me in the beginning and turned out to actually not be (despite its shortcomings and JavaScript, which also turned out to be nicer). On the other hand projects, like Meteor that looked at least okay in the beginning turned out to be way more awful than they looked when I first heard that they don't even support proper REST.

I know, my opinion on this might not be really popular, but it's amazing to see how so many new concepts emerge, even when they seem crazy, sometimes turn out to be crazy, sometimes turn out to be amazing. It's hard to know where we will stand in a couple of years. However, I don't think only one of Rust, Go or Node.js will make the race and I think none of them will look like they do today in one or two years, especially when it comes to their ecosystems. Just because all of them are too young to be judged upon and all of them are changing too rapidly (or new standards are upcoming, as with ECMAScript), so that nobody really has or can develop a deep understanding of the language/framework yet, not even its developers.

What I really hope though is that there will soon be more big projects than just Docker and a bigger ecosystem.

Post reply on HN