Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proposal: JavaScript Structs

github.com

Post reply on HN
Print view View original

211–220 of 371 posts

Re: Proposal: JavaScript Structs

#211

Post by BoppreH »

totallykvothe wrote: post #170
leetharris wrote: post #67

Earlier quoted context omitted.

This is easily the most appealing thing to me about Go. I learned Go through the "Learn Go with Tests" way and I had a ton of fun. It is hard for me to recommend using Go internally since .NET/Java are just as performant and have such a mature ecosystem, but I crave simplicity in the core libraries. Here's the link for anyone considering learning Go: https://quii.gitbook.io/learn-go-with-tests

.NET/Java are only as performant as Go if you completely ignore memory usage and focus only on time.

And startup time. JIT languages are a bad match for command line applications, for example.

Re: Proposal: JavaScript Structs

#212

Post by wruza »

afavour wrote: post #129
nsonha wrote: post #128

Earlier quoted context omitted.

I can think of a few when hoisting is nice, stylistically: if (...) var x = ... else x = ... ///// try { var x = ...} catch (error) { x = ... } ///// for (...) { var x: NodeJS.Dict = {} x[key] = ... } return x

All of those feel like anti patterns to me. Much more difficult to read.

The worst anti-pattern here is the catch- and finally-blocks living in a different scope.

Really, who thought it was a good idea that finalization and error handling blocks must have no access to their subject scope? Every damn language copies that nonsense, except for js and its `var` hoisting.

Re: Proposal: JavaScript Structs

#214

Post by wruza »

zanethomas wrote: post #130

I don't understand the need for the ever-growing list of "enhancements" to JS. Take Class for example. Class is entirely unnecessary and, essentially, tries to turn JS into a class-oriented language from its core which is object-oriented. I never create classes. I always create factory functions which, when appropriate, can accept other objects for composition. And I don't use prototypes, because they are unnecessary…

Otoh, I create classes, use prototypes and it’s natural and useful in many of my cases.

In my dreams those who want to turn JS into c# or Java should just create a language they like and stop piling on to JS.

We could even share this dream if browser vendors weren’t such whos the boss iam da boss when it comes to extensions and alternatives. So we have to live in a common denominator, which surprisingly isn’t as bad as it could be, really.

Re: Proposal: JavaScript Structs

#215

Post by dingi »

wiseowise wrote: post #179
BigJono wrote: post #161

Earlier quoted context omitted.

It would have worked out fine if we managed to lose the prototypes without ramming classes into the language and baiting all the Java dickheads over to the web ecosystem. Javascript breathed it's last breath the moment someone saw NestJS and said "wow that's a good idea".

> Javascript breathed it's last breath the moment someone saw NestJS and said "wow that's a good idea". I still don’t understand how someone looked at Spring and thought “Wow, that’s pretty good! I’ll bring it to platform that has worse performance than Java, to language that was designed with dynamicity in mind and has no native static typing”.

Asking out of curiosity. What's your rationale behind Spring is slower? Worked on couple of greenfield and existing Spring Boot applications and we never had any performance issues caused by Spring. Spring has its own bad parts but calling that it has worse performance than Java is not one of them. Its not even a valid comparison. Java is crazy fast for a VM based runtime AFAIK.

Re: Proposal: JavaScript Structs

#216

Post by edem »

leetharris wrote: post #18

I am not sure how to really refine this thought I have had, but I have this fear that every language eventually gets so bloated and complicated that it has a huge barrier to entry. The ones that stand out the most to me are C# and Typescript. Microsoft has a large team dedicated towards improving these languages constantly and instead of exclusively focusing on making them easier to use or more performant, they are c…

just use haxe

Re: Proposal: JavaScript Structs

#217

Post by dingi »

klysm wrote: post #160
BigJono wrote: post #157

Earlier quoted context omitted.

Yep and TS has all of that plus a gigantic layer of bullshit on top. The web development community has created the perfect environment for nobody to ever get any work done while still feeling like they're being productive because they're constantly learning minutiae.

Typescript is the best thing to happen to JavaScript since ES6

If only it had a sound type system.

Re: Proposal: JavaScript Structs

#218

Post by wruza »

szastamasta wrote: post #41

Please stop. What a nonsense. JS is a dynamic language where everything is a Hashtable. It will never be really fast as your structs won’t be in single cacheline, you won’t be able to calculate field address during compile time by pointer offsets. There’s no simd, no multithreading, no real arrays. JS is such a simple, dynamic language. It should just stay this way. Please stop bloating it with every feature that’s t…

Javascript implementations do not use hash tables for objects.

Yes, it is surprising. https://stackoverflow.com/questions/6586670/how-does-javascr...

And when jit kicks in, it does all the usual calculate-the-offset things in generated code.

Re: Proposal: JavaScript Structs

#219

Post by pjc50 »

munificent wrote: post #76
leetharris wrote: post #18

I am not sure how to really refine this thought I have had, but I have this fear that every language eventually gets so bloated and complicated that it has a huge barrier to entry. The ones that stand out the most to me are C# and Typescript. Microsoft has a large team dedicated towards improving these languages constantly and instead of exclusively focusing on making them easier to use or more performant, they are c…

I've been meaning to write a longer essay on this for years, but I believe the reason for this observation is different cohorts. Imagine you are a C# programmer just as C# 1.0 is released. C# is a fairly simple language at that time (and similar to other languages you already know), so you can get caught up on it fairly easily and quickly. A few years later, C# 2.0 comes out. It's got a handful of features, but not t…

Speaking as a long time C# developer (and before that, C and C++), every time I try to touch javascript I get that kind of allergic reaction - not because of the language features itself, but the ecosystem. In theory npm and nuget are the same kind of complexity; in practice, all the complexity of C# building disappears into Visual Studio.

A lot of people seem to think that the overall size and "complexity" of the language (and only the language) matters? Personally I don't think it matters how long the spec is if you and your team aren't using those features. The ecosystem matters more. "What should I use to write a GUI in C#?" is a complicated question with tradeoffs, but none of them have anything to do with the language per se.

Nothing is going to compete with C++'s template system for complexity, though.

Re: Proposal: JavaScript Structs

#220

Post by pjc50 »

spease wrote: post #89
munificent wrote: post #76

Earlier quoted context omitted.

I've been meaning to write a longer essay on this for years, but I believe the reason for this observation is different cohorts. Imagine you are a C# programmer just as C# 1.0 is released. C# is a fairly simple language at that time (and similar to other languages you already know), so you can get caught up on it fairly easily and quickly. A few years later, C# 2.0 comes out. It's got a handful of features, but not t…

I can't speak for how C#; but in C++'s case, the issue is that there's a lot of programmers who don't keep up with the language that they're using. As a result, you get a few people pushing the language ahead, who are deeply involved in its future. And then the vast majority of people are still using C++03, and it's still taught the same way as it was ~20 years ago. I think the only way to address what you're alludin…

> continually deprecate small parts of the language

Did you see https://news.ycombinator.com/item?id=41788026 ?

"My concern, and IMO what should be the overwhelming concern of the maintainers, is not the code that is being written, or the code that will be written, but all the code that has been written, and will never be touched again. A break like this will force lots of python users to avoid upgrading to 3.17, jettison packages they may want to keep using, or deal with the hassle of patching unmaintained dependencies on their own.

For those Python users for whom writing python is the core of their work that might be fine. For all the other users for whom python is an foreign, incidental, but indispensable part of their work (scientists, analysts, ...) the choice is untenable. While python can and should strive to be a more 'serious', 'professional' language, it _must_ have respect and empathy for the latter camp. Elevating something that should be a linter rule to a language change ain't that."

Strongly phrased, but planned obsolescence in a language is really expensive. You're basically quietly rotting the work of your users, and they will hate you for it.

I note that C# basically hasn't deprecated any of the language itself, the dotnet core transition was a big change to the runtime. And that was expensive enough, again due to dropping a lot of old libraries.

Post reply on HN