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

181–190 of 371 posts

Re: Proposal: JavaScript Structs

#181

Post by pjmlp »

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…

Not keeping up with the language is quite common in traditional enterprises, that is why you get shops still doing Python 2, Java 8, .NET Framework (C# 7.x), C89, C++98,....

People get paid to keep running what already exists, not to write new stuff.

Usually new stuff only comes to be if there is a new product being added into the portfolio, and most of the time it comes via an aquisition or external contractors, not new development from scratch in a cooler version of the stuff they are using.

Re: Proposal: JavaScript Structs

#182

Post by branko_d »

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…

And here is the obligatory quote from Bjarne Stroustrup:

"There are only two kinds of languages: the ones people complain about and the ones nobody uses."

Re: Proposal: JavaScript Structs

#183

Post by pjmlp »

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.

Specially if one is ignorant on how to write proper .NET and Java code.

Re: Proposal: JavaScript Structs

#184

Post by pjmlp »

intothemild wrote: post #121
adamc wrote: post #25

Earlier quoted context omitted.

Java went through this too, although there, a lot of it is part of the ecosystem. See https://chrisdone.com/posts/tamagotchi-tooling/

The java tooling is the number one thing I hate about using the language. It's all just bad. Then. You get forced into using intelij because it seems to smooth over a lot of the toolings problems with "magic". It's horrible.

I use Eclipse and Netbeans of free will.

Re: Proposal: JavaScript Structs

#185

Post by bryanrasmussen »

Lerc wrote: post #117
girvo wrote: post #102

Earlier quoted context omitted.

In fact, Javascript is so complex that one of the seminal books on it was specifically "The Good Parts", cutting down the scope of it to just the parts of the language that were considered decent and useful.

I think the distinction with JavaScript compared to other 'complex' languages is that you don't have to go beyond "The Good Parts" to achieve significant functionality, and it has become idiomatic to use the good subset. In some respects I think if there were a well defined "Typescript, The Good Parts" I would happily migrate to that. I do wonder if there will, one day, be a breaking fork of JavaScript that only remo…

after the success of the Good Parts book there were a few other books with the "Good Parts" in the title - like HTML and CSS the Good Parts, and Java: The Good Parts. I seem to remember looking through PHP: the Good Parts and feeling that it was just a learn PHP book, that it did not really differentiate between any core good parts of the language, the parts you should really learn and use.

I sure would like a real "Good Parts" series of books.

Re: Proposal: JavaScript Structs

#187

Post by pjmlp »

whizzter wrote: post #2

Not sure this is a good idea or not, for one it'd be awesome for doing performance oriented and threaded code in JS/runtimes, the idea seems related to how C# struct's already work (and tuples under the hood). Interop with WASM code might also be simplified if struct-like access was a built-in. The bad is that people wouldn't necessarily be prepared for their semantics (are they value or reference based?), how to sha…

Note that the idea isn't unique to C# structs, other GC enabled languages have similar capabilities.

Re: Proposal: JavaScript Structs

#188

Post by wiseowise »

szastamasta wrote: post #66
tantalor wrote: post #48

Earlier quoted context omitted.

High performance applications are already being written that depend on features like shared memory, but because the language has poor support for them then developers have to use ugly workarounds. This proposal solves that with built-in support. >It should just stay this way Counterpoint: JS has been evolving significantly, look at ES6 and ES8 in particular if you need help finding examples.

I just mean you won’t write a video codec or a 3d renderer in JS. It will never get there. Just leave these things to WebAssembly where needed and leave JS as a slow, dynamic language we use for web apps.

> I just mean you won’t write a video codec or a 3d renderer in JS.

Not with the attitude, you don’t.

> Just leave these things to WebAssembly where needed and leave JS as a slow, dynamic language we use for web apps.

The ship has sailed when they made V8 and performance race has started.

Re: Proposal: JavaScript Structs

#190

Post by devjab »

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 think part of the reason C# has changed so much as far as the language goes, not the CLR is actually because they took so many good things from Typescript and mixed them into the language. I think part of the reason Typescript has become so cumbersome to work with is because it has similarly added a lot of the good things from C#. Which may sound like a contradiction, but I actually agree with you that plain JavaScript is often great. That being said, you don’t actually have to use all the features of Typescript and it’s still much better for larger project in my opinion. Mostly because it protects developers from ourselves in a less “config on organisational level” way.

We already use regular JS for some of our internal libraries, because keeping up with how TS transpires things into JS is just too annoying. Don’t get me wrong, it gets it right 98% of the time, but because it’s not every time we have to check. The disadvantage is that we actually need/want some form of types. We get them via JSDoc which can frankly do almost everything Typescript does for us, but with much poorer IDE support (for the most part). Also more cumbersome than simply having something like structs.

Post reply on HN