[RcouF1uZ4gsC]

Language success is in large parts driven by what system adopts that language.

Objective-C’s success was driven by iOS.

C’s success was driven by Unix.

C++’s early success was driven in large part by 90’s GUI frameworks ( MDC, OWL, Qt, etc.

I think Wasm is shaping up to be huge in that you can safely run, high performance code across multiple operating systems/CPU’s. Of all the languages, I think Rust has the best WASM tooling, and the 2020’s may end up being the WASM/Rust decade.

[ummonk]

On the one hand the proliferation of features such as WebGL, WebRTC, WASM, etc. greatly increases browser attack surfaces. On the other hand, it allows a single relatively constrained system to focus on for security hardening / sandboxing.

Regardless, being open standards, not obnoxiously object oriented, and better designed to interoperate with normal HTML content, the modern HTML5 ecosystem is certainly way more promising than Java applets / Flash / Silverlight.

[nojito]

> I think Rust has the best WASM tooling, and the 2020’s may end up being the WASM/Rust decade.

Still pales in comparison to .NET

[miohtama]

Look to the future, not to the past.

[easton]

I mean, Microsoft seems to be making it clear that the replacement for old-school ASP.NET formsy apps to be Blazor, which is C# you write that runs in the browser via WASM. Makes making SPAs easier if that’s your stack.

https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...

[avgDev]

I'm rewriting an MVC 5 app in Blazor as we speak. I'm "full-stack" but my JS skills are pretty low compared to C#, which I am extremely comfortable with. It is actually extremely fun to work with. Havin ability to inject a service directly into a page is amazing.

I'm hoping Blazor gets more popular. However, I will see how this project goes and if I hit any major road blocks, so my opinion my shift. So far it seems like a great option.

[rafale]

What I would really love is to see XAML-like layout in the browser. CSS is a mess I can never wrap my mind around even with the flex model. Whereas the XAML model is much simpler (a measure pass to size components, an arrange pass to lay them).

[mmis1000]

I think css is mostly a sane low level layout system (which allow you to produce whatever pixel you want, like opengl or whatever) instead of a predefined component system. It will never have those nicely designed components buildin (because it is not its goal). And the complexity price comes from the flexibility it demands.

[wvenable]

XAML's layout components are much easier than HTML/CSS but styling XAML components is way over-complicated compared to CSS.

[exdsq]

Look to what’s being used in prod, not HN hype.

[Shadonototra]

> I think Rust has the best WASM

Nope, C/C++ has, emscripten remains undefeated

You don't just put a name and expect things to skyroket

C++/Go/C# has more chance to become the standard toolkit for WASM than rust

rust problem, is people promotes more the "rust"™ rather than their project, the crabs definitely shadows them, it's unfortunate

[the_duke]

Your comment seems to rooted in your dislike of Rust, rather than provide any technical arguments.

The Rust tooling certainly was the best, no question. As the Mozilla WASM devs have moved on the WASM tooling has stagnated, sadly, and The C++ tooling has caught up.

Languages like C# and Go are inherently worse for WASM because they require GC and have big runtimes they have to bring along.

[Ha_Mei__33]

>> Languages like C# and Go are inherently worse for WASM because they require GC and have big runtimes they have to bring along.

People are streaming GBs of content with their devices. At startup most of the social media apps or websites are downloading tens of MBs. Users don't care or notice.

I don't know the size of the C# runtime in WASM, but the Go runtime is compressed at about 0.5 MB. Downloading this at startup is unnoticeable unless you are deep in the wild. With TinyGo (https://tinygo.org/) it's less than 50 KB (don't know the exact number, I think around 30 KB). So really small.

The weight of a runtime is not a convincing argument against C# or Go.

On the other hand, GC and runtime make development of memory safe and concurrent code much easier than C/C++/Rust. Also, performance of C# and Go is so very close to C/C++/Rust, that for most use cases they are fast enough.

Bottom line: C# or Go are not *inherently* worse for WASM. You still need to develop your app. With both C# and Go you can do it with much less mental overhead compared to C/C++/Rust. You have more time and energy to focus on your problem to solve than to manually manage memory. If you really need the absolute cutting edge performance, not WASM but native would be more appropriate anyway.

[pjmlp]

Looking forward to a Rust framework than can actually compete with Blazor, nope Yew isn't it.

[gk1256]

I can dislike Rust too, but the facts are facts. Emscripten is the leader of WASM world and lot of its code is based on C++.

[pacificat0r]

Emscriptem is targeted at browsers and for that rust does have the target wasm32-unknown-emscripten

However, when targeting wasm outside browsers wasm32-wasi is usually a better option.

[jedisct1]

When targeting WASI or for standalone (no wasi, no emscripten) WebAssembly, Zig is currently the best option, IMHO.

Modules are small and fast, virtually all existing code is compatible out of the box and the standard library comes with full WASI support. And enabling runtime-specific optimizations such as SIMD is as simple as adding a compilation target flag.

While I maintain quite a few Rust crates specifically designed for WebAssembly/WASI usage, my personal experience is that Zig is often better, even from a performance perspective.

TinyGo is also amazing at producing optimized modules, and a lot of existing Go code can be compiled with it without any changes.

[pjmlp]

I already have wasm outside browsers, it is called JVM and CLR bytecode.

> More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET.

https://news.microsoft.com/2001/10/22/massive-industry-and-d...

[gk1256]

"Emscripten" can target platform outside browsers. You have STANDALONE_WASM flag for that.

[astrange]

> Objective-C’s success was driven by iOS.

Well, Objective-C is from 1984 and its major success was being cloned to make a programming language called Java.

[DonHopkins]

Java was a direct reaction to C++, not Objective C.

James Gosling's earlier object oriented PostScript based NeWS interpreter was a lot more like Objective C and Smalltalk than his later Java language was. (But I'm not going to mention the earlier abomination that was Gosling Emacs MockLisp. Oops!)

https://medium.com/@donhopkins/bill-joys-law-2-year-1984-mil...

>Bill Joy’s Law: 2^(Year-1984) Million Instructions per Second

>The peak computer speed doubles each year and thus is given by a simple function of time. Specifically, S = 2^(Year-1984), in which S is the peak computer speed attained during each year, expressed in MIPS. -Wikipedia, Joy’s law (computing)

>Introduction: These are some highlights from a prescient talk by Bill Joy in February of 1991.

>“It’s vintage wnj. When assessing wnj-speak, remember Eric Schmidt’s comment that Bill is almost always qualitatively right, but the time scale is sometimes wrong.” -David Hough

>C++++-=: “C++++-= is the new language that is a little more than C++ and a lot less.” -Bill Joy

>In this talk from 1991, Bill Joy predicts a new hypothetical language that he calls “C++++-=”, which adds some things to C++, and takes away some other things.

>Oak: It’s no co-incidence that in 1991, James Gosling started developing a programming language called Oak, which later evolved into Java.

>“Java is C++ without the guns, knives, and clubs.” -James Gosling

>Fortunately James had the sense to name his language after the tree growing outside his office window, instead of calling it “C++++-=”. (Bill and James also have very different tastes in text editors, too!)

>[...]

[pjmlp]

You missed these ones,

"Java Was Strongly Influenced by Objective-C ...and not C++... A while back, the following posting was made by Patrick Naughton who, along with James Gosling, was responsible for much of the design of . Objective-C is an object-oriented mutant of C used NeXTSTEP and MacOS X, and also available with gcc."

https://cs.gmu.edu/~sean/stuff/java-objc.html

"In order to supply a comprehensive and flexible object programming solution, Sun turned to NeXT and the two developed OpenStep. The idea was to have OpenStep programs calling DOE objects on Sun servers, providing a backoffice-to-frontoffice solution on Sun machines. OpenStep was not released until 1993, further delaying the project.

By the time DOE, now known as NEO, was released in 1995,[1] Sun had already moved on to Java as their next big thing. Java was now the GUI of choice for client-side applications, and Sun's OpenStep plans were quietly dropped (see Lighthouse Design). NEO was re-positioned as a Java system with the introduction of the "Joe" framework,[2] but it saw little use. Components of NEO and Joe were eventually subsumed into Enterprise JavaBeans.[3]"

https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere

[xxs]

While Obj-C had a massive influence to java, I'd not call it clone - even Java 0.9 is a lot better language than Obj-C of 2010 (or so). The saving grace of Obj-C - it could include normal C just like that.

[pjmlp]

Well, https://cs.gmu.edu/~sean/stuff/java-objc.html

And Java EE started as an Objective-C project, https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere

[astrange]

Swing also seems to be heavily inspired by AppKit.

Although leaving out messaging and leaving in both int and Integer are weird choices if their language was supposedly inspired by Smalltalk/ObjC.

[xxs]

>Although leaving out messaging and leaving in both int and Integer

Both are great choices... from performance point of view. Java is still modeled after plain C 1st and foremost. int should be the default and Integer(and Long) should be avoided. Up to java1.5, it took a manual operation (Integer.valueOf/intValue) to convert, so it was not abused as much. Marked integers have been in the works and they take a significant engineering effort for a nice to have feature.

When collection framework was introduced, it should have had primitive Maps/Lists - there was a regret (around java8 times) not including them initially - Streams attempted to amend the damage. The primitive types map directly to the hardware. Wrapped ones - they are pointer to an immutatable primitive and enjoy little optimization from the JIT.

As for swing, beans and properties - I'd say Delphi would have the most similarities.

[pjmlp]

Performance mostly.