Earlier quoted context omitted.
> without having to think about threads or synchronization. Just pipe data through the channel! I mostly agree with what you're saying, but note having a channel doesn't mean one stops worrying about synchronization. If two goroutines both started waiting for data from a channel they'd be deadlocked.
True, on the other hand, go will take care of that to some extend and terminate if all go routines have been deadlocked. Which means well-designed services will remain available even if only with degraded performance.
Ask HN: Why is everything in JavaScript changing so fast?
151–160 of 303 posts
Re: Ask HN: Why is everything in JavaScript changing so fast?
#152Imagine that you have a furniture factory. There is one room where one guy who works for you produces tables. In next room there is another who produces sofas. And then another one who makes chairs. The demand is great, so routinely you hire more people to produce more things. As you walk, you realise that each of them uses selection of screws and chisels and screws and wheels, and types of wood and door handles and…
> Java had its Sun, Python had BDFL Guido, JS has no such thing. For JavaScript the TC39 is responsible for its improvement and standardisation. Thats were ES6 was developed. ES2016 aka ES6 took a fair amount of time, but the TC39 switched to "rolling releases". ES2017 aka ES 7 is already in the works and is going to be released 2017. https://github.com/tc39
Re: Ask HN: Why is everything in JavaScript changing so fast?
#153The open-source-JavaScript community right now is just the largest, most active open source community that has ever existed. Check out the stats that GitHub recently announced: https://octoverse.github.com/ Open source JavaScript activity as measured by pull requests has doubled (!!) in the past year. It's more than the next two languages (Java and Python) combined. Most of the top repositories on GitHub are JavaScri…
To a large extent this is true because the javascript community is busy with the re-invention of all of computer history, only without applying all of the lessons learned. Activity does not equate quality.
It's definitely frustrating to see. And it's also frustrating to see the vitriolic reactions to anyone who criticizes the current culture of the JavaScript community.
I use React and all of its associated tools and ecosystem, and while I find them productive and useful, the whole situation is a bigger mess than it needs to be. I don't think it's necessarily anyone's fault; I don't see a willful desire to ignore the hard-won computing knowledge we'e accumulated. It just seems as though the JS community's enthusiasm has, at least recently, has exceeded the rate at which good tooling can be developed.
I think that's changing, though. From what I've seen, in the past year there has been more of a push toward building mature, reliable, maintainable JS applications. I've also seen more interest in optimization. The Closure Compiler has been around for a long time, and at least in the Angular 2 community I've noticed jump in the number of people looking to use Closure and other tools like Rollup to optimize everything and deliver the smallest possible code bundle to the browser. And ES2015's statically analyzable modules go a long way toward making more optimization possible.
So I agree, things are a bit crazy. And I agree that activity does not equal quality. But there's a lot of activity, and some of it is of high quality. I can't guarantee that the high quality work that brings more of those lessons learned to the JS world will become popular, but I'm at least seeing a positive trend in that direction.
Re: Ask HN: Why is everything in JavaScript changing so fast?
#154The problem is that everything in JS exploded during just few years (Node was published in 2009), and it took few years to build tooling around Node to start utilising all this power. And then everyone started to build "rich" web applications (it is called differently every year), with the "best" tool existing. I personally see two major problems – usually cool startups who can afford using the bleeding edge will die…
I'm not a huge fan of the "Javascript programmers are novices" myth. It's quite damaging.
Javascript is a kitchen-sink language these days in the ES6+ world. You've got the functional programming features... monads, functors, applicative and even immutable data structures are just a library. You have classes, interfaces, protocols and of course event-driven programming, prototypes, etc, etc, etc. It's not a small spec these days.
The point is that there are smart people who use the language to great effect. Enough with the "unwashed masses," story please.
Personally I'll take an ML or Lisp based language anyway... but thankfully I can have my cake and eat it too by compiling to Javascript.
Re: Ask HN: Why is everything in JavaScript changing so fast?
#155Earlier quoted context omitted.
It's easy to sit back and critisize JavaScript and the web with dismissive comments like this. I have heard variations on these same memes for many years. But something that I almost never hear: critics offering a candid explanation for why their platform / language / framework - which maybe wasn't perfect but CERTAINLY compared to JavaScript was awesome - did not become the de facto tool across as diverse a spectrum…
> But something that I almost never hear: critics offering a candid explanation for why their platform / language / framework - which maybe wasn't perfect but CERTAINLY compared to JavaScript was awesome - did not become the de facto tool across as diverse a spectrum for delivering features / products / tools to users. Because JavaScript was, and basically still is, the only option for client-side web development - t…
People trying to use Javascript as a surrogate C++^H^H^H Java will be sorely disappointed.
People trying to use Javascript as something that blends Scheme and Smalltalk will be using it as its creator intended. While this won't make the extreme purists happy, for many of us, Javascript is an acceptable Lisp.
I have come to prefer Javascript to Java (or C#), but most of my coworkers still think in Java, so that's another issue :-)
Re: Ask HN: Why is everything in JavaScript changing so fast?
#156The problem is that everything in JS exploded during just few years (Node was published in 2009), and it took few years to build tooling around Node to start utilising all this power. And then everyone started to build "rich" web applications (it is called differently every year), with the "best" tool existing. I personally see two major problems – usually cool startups who can afford using the bleeding edge will die…
Soon we'll have trouble hiring Angular 1 devs to maintain legacy code, like COBOL. Except COBOL started in 1959, not 2009.
Re: Ask HN: Why is everything in JavaScript changing so fast?
#157The open-source-JavaScript community right now is just the largest, most active open source community that has ever existed. Check out the stats that GitHub recently announced: https://octoverse.github.com/ Open source JavaScript activity as measured by pull requests has doubled (!!) in the past year. It's more than the next two languages (Java and Python) combined. Most of the top repositories on GitHub are JavaScri…
These stats prove the hype, not that it is good quality code, with good quality documentation, with a friendly and safe community, and a reliable archiving system for it's dependencies.
I have nothing against JS in particular, but there is a bit too much hype about it.
Re: Ask HN: Why is everything in JavaScript changing so fast?
#158Earlier quoted context omitted.
True, on the other hand, go will take care of that to some extend and terminate if all go routines have been deadlocked. Which means well-designed services will remain available even if only with degraded performance.
I didn't know go can do deadlock detection. Thanks for this, I learned something new today.
If all go routines are deadlocked, the runtime will terminate the service.
It's a kind of graceful and somewhat safe degradation.
Re: Ask HN: Why is everything in JavaScript changing so fast?
#159Earlier quoted context omitted.
There is a (perhaps apocryphal) story about the art class which was separated into 2 groups - one group worked on a single project all semester and the other group worked on a new project every day. People in the group that worked on a project every day produced better work than people in the "single project" group. My google-fu is weak, so I cannot find the reference. I'm not suggesting that the Javascript ecosystem…
This is the running premise behind the book Art and Fear, which basically concludes that iteration with quality feedback is the best way to develop your abilities and produce your best work. That is, quantity is the best path to quality. https://www.amazon.com/Art-Fear-Observations-Rewards-Artmaki...
Re: Ask HN: Why is everything in JavaScript changing so fast?
#160The problem is that everything in JS exploded during just few years (Node was published in 2009), and it took few years to build tooling around Node to start utilising all this power. And then everyone started to build "rich" web applications (it is called differently every year), with the "best" tool existing. I personally see two major problems – usually cool startups who can afford using the bleeding edge will die…
JS development will probably go on like if nothing changed, but people that don't like it will be able to opt-out.