471–480 of 502 posts
Go is a well designed language that is productive, has a very tolerable learning curve, good documentation and does not need a JavaScript facade.
If kids in the 80s without the Internet could learn programming, you can learn Go in 2018.
Expect another video in 10 years: Things I regret about Deno, probably having advice very similar to this.
Earlier quoted context omitted.
> those that insist on throwing shade at npm on HN should be corrected. Preferrably by giving them better ammunition, since I do see NPM as substandard in quite a few ways, which is inexcusable when there do exist examples to learn from (whether it be a positive or negative influence). First, it helps to clarify whether we are talking about npm the client or NPM the repository and ecosystem . Client issues are genera…
> Sure, NPM isn't all that bad compared to some of the examples that were put forth, but the problem is that those examples are a limited subset of what exists. That was all I was responding to. I definitely learned some cool stuff from your comment, and appreciate that, but my point was simply that the all the drive-by FUD that npm gets on HN is unwarranted. > I frankly find the current situation somewhat disgusting…
What I find somewhat disgusting is the massive amount of mistakes they've made over the years, and the time they've had to take to fix them, that could have been mitigated or entirely avoided by surveying best practices from other package management systems that have gone through the same pains.
2018-05-28 - ERR! 418 I'm a teapot (this is not a joke)
https://github.com/npm/npm/issues/20791
https://news.ycombinator.com/item?id=17175960
2018-02-21 - Critical Linux filesystem permissions are being changed by latest version
https://github.com/npm/npm/issues/19883
https://news.ycombinator.com/item?id=16435305
2017-08-01 - Typosquatting package names
https://twitter.com/o_cee/status/892306836199800836
https://news.ycombinator.com/item?id=14905675
(a little obtuse, but moderated package namespaces with
trusted maintainers can mitigate this, and spread load
from levenshtein distance checks.)
2017-11-03 - Visual Studio Code 1.7 overloaded npmjs.org, release reverted
https://news.ycombinator.com/item?id=12860806
(10% increase in NPM load, specifically to 404 pages,
causes NPM to fall over due to naive 404 handling and
apparently, poor ability to scale. Good thing they
caught it at 10% instead of the 200% it would have
reached...).
2016-03-29 - changes to npm’s unpublish policy
https://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy
https://news.ycombinator.com/item?id=11382885
2014-02-28 - npm’s Self-Signed Certificate is No More
https://blog.npmjs.org/post/78085451721/npms-self-signed-certificate-is-no-more
https://news.ycombinator.com/item?id=7320833
2012-03-08 - npm (Node's package manager) leaks all user password hashes and salts
https://gist.github.com/jashkenas/2001456
https://news.ycombinator.com/item?id=3679996
I mean, I would cut them a little slack if they seemed to have plans for making stuff better and a roadmap and it was just a matter of time, effort and resources they were lacking, but it seems to continuously be a case of them waiting until the shit hits the fan and they're forced to first take a look and see how to fix this new problem they've never envisioned, and then figure out their solution. Sure, it can sound hyperbolic initially, but I think that's just because people haven't really stopped to take stock of what's really going on here, and how it's not really getting better in any useful way. In the midst of emergency fixes is not how you should plan your new features. :/
Earlier quoted context omitted.
That's a good example of the Innovator's Dilemma: the enterprise incumbent is unseated by some "crappy" lightweight solution that is easier to get up to speed and solves enough of the problem. The complexity, accidental and essential, comes later.
Nevertheless, people who need a lightweight language are always able to find one because there is always a new language at that point in its lifecycle. Further, there are languages like Go which seem to be determined to remain easy to get up and running, and don't seem likely to change anytime soon (for better or worse).
(Amusingly, my iPhone autocorrect replaced "roots" with "Russ". Russ Cox is an engineer who works on Go. :)
Earlier quoted context omitted.
Yes, arguably the .NET Framework almost did it and is still one of the most productive frameworks available, but .NET Core has definitely improved things substantially. It's fast, well-designed, and full-featured and I expect usage to pick up greatly.
What I don't like in Microsoft's frameworks is that they've made lots of things multiple times in slightly different variations, like they always do with all their software (10 variations of each type of programs which were outdated before they were finished). Mostly it exists due to historical reasons, but it only underlines the problem of a multi-billion corporation having design skills of a sophomore. They redo an…
Earlier quoted context omitted.
The biggest problem i see is the weird hole circa 2006 that arranges with Sun selling to Oracle, that kind of still-birthed Java as the next great language. That hole I can credit as giving C# the advantage in that tight niche, and stilling the development of the JVM platform in general. By the time that the rust on JVM improvements were dusted off, all initiative was lost. Java was playing catchup to the competition…
As we're seeing with WhatsApp, guardianship and supporting the direction of a project isn't easy. I'm not sure where Java would have ended up if someone else took it.
Earlier quoted context omitted.
> I'm also a fan of using env vars for configuration and locating dependencies O please just let things be configured by a single JSON value, built from smaller JSON values if necessary.
Sure thing. How do you get such a JSON value into an application though? What I'm saying is to use env vars. You could put your JSON straight into an env var, or if you want a persistent JSON file on disk then put the path to that file in an env var.
I think it's quite interesting to see that originally node.js was presented as a bloat-free alternative to "enterprise languages" like Java, C# or even Python or Ruby. A lot of complexity was subsequently added in an ad-hoc way which has resulted in (for example) a package management system that's wildly out of control. It's very popular of course, so I'm definitely not arguing that metric. However, the stuff that wa…
I think this is a story that gets repeated lots of times in our world of open source software dev. 1. X is SO bloated and poorly engineered full of bad legacy decisions. 2. We can totally do better let's invent a new thing, Y! 3. Wow, Y is so clean and fast and understandable. 4. But it doesn't do this thing a bunch of people reasonably really need... let's add it. (repeat 3 and 4 a few hundred times) 5. Y is so bloa…
Earlier quoted context omitted.
C# is very verbose and tedious compared to more expressive languages - having to deal with CLR types/API at runtime while using a language with very limited expressiveness (C#) is not very productive. It's better than Java if that's what you're aiming at - but JVM has an incredible ecosystem of stuff that works - much larger than .NET core which is not very mature in many areas (recently had to revert to .NET 4.7 bec…
Yes Typescript (also from Microsoft) is fascinating and fantastic at combining the strengths of static typing while still maintaining all the flexibility of dynamic types if necessary, however it's pretty much the only realistic non-academic of such a thing, so basically everything else is pales in comparison if that's what you're looking for. Why is C# not expressive? It has the DLR and `dynamic` keyword which behav…
I agree it makes JS better. I agree it's a good tool for its purpose.
But "fascinating" ?
It's hardly the most elegant scripting language down there (Ruby, Python, Kotlin and Dart doesn't have to live with the JS legacy cruft).
It has a very small ecosystem outside of the web.
The syntax is quite verbose for scripting.
It has very few data structures (and an all-in-one one).
Very poor stdlib.
Still inherits of important JS warts like a schizophrenic "this".
Almost no runtime support if you don't transpile it (which means hard to debug and need specific tooling to build).
And it's by no mean the only scripting language having good support for typing (e.g: VSCode has great support for Python, including intellisens and type checking).
What's so fascinating about ?
What's fascinates me is that we are still stuck with a monopoly on JS for the most important platform in the world.
I think it's quite interesting to see that originally node.js was presented as a bloat-free alternative to "enterprise languages" like Java, C# or even Python or Ruby. A lot of complexity was subsequently added in an ad-hoc way which has resulted in (for example) a package management system that's wildly out of control. It's very popular of course, so I'm definitely not arguing that metric. However, the stuff that wa…
I think this is a story that gets repeated lots of times in our world of open source software dev. 1. X is SO bloated and poorly engineered full of bad legacy decisions. 2. We can totally do better let's invent a new thing, Y! 3. Wow, Y is so clean and fast and understandable. 4. But it doesn't do this thing a bunch of people reasonably really need... let's add it. (repeat 3 and 4 a few hundred times) 5. Y is so bloa…
Earlier quoted context omitted.
It's interesting that you mention gulp and webpack when those tools too are now considered too complex and set to be usurped by something like Brunch. It's a shame these tools keep being rewritten because there are definitely good ideas in all of them, but for some reason they can't seem to be unified.
> usurped by something like Brunch I've been out of Node for like 6 months, wth happened! I give up!!