wrl

This looks really cool, but it'd be nice to not need a Google account (which I do not have) to sign in.

> It's objectively not perfect, but then most languages have problems.

Let me be clear here: JS is not really any better or any worse than any other interpreted languages. Yeah, I can name a few language-level problems (whoever decided that Promises should silently eat exceptions was wrong), but the big problems are not unique. Things like awful numeric performance (I've done crypto in JS), horrible multithreading support (Python and Ruby have GILs so it's roughly the same thing), etc etc.

The difference is that JS/web programmers seem to be the only ones saying that things written in their language and platform of choice (JS/HTML/CSS webapps, inside or outside of Electron) are the future everybody wants. Like the ego-stroking whenever somebody posts a new Node or Electron tool that had no reason to be written in JS except that the developer just didn't want to use another language isn't weird. Like 123mb for a terminal emulator isn't ridiculous.

Javascript brings nothing to the table except that it's the only language you can use for web programming. Nothing.

The execution model is awful as well, since apparently in order to get any sort of decent performance in a webapp these days you need to maintain a shadow copy of the DOM just so you can hack around the browser's layout engine.

> JavaScript has some of the most advanced features of languages available today, including lambdas, closures, and asynchronous coding patterns that make it faster at dealing with IO than naive C implementations.

30 years programming experience and you want to compare an interpreted language to a naïve C implementation? Come on. Did you see the Python libuv asyncio implementation that is 2x faster than the equivalent code running in Node [0]? Python, using Node's own supporting libraries (http-parser also) is better than Node at Node's own game.

[0]: http://magic.io/blog/uvloop-blazing-fast-python-networking/

> So you prefer one written in ... C? Because C is secure by design? <rim shot> > Coding a terminal in Rust or even Go would be awesome, I admit...

So, if Javascript hate is "so 2010," is C hate all the fashion now? If you're going to get on somebody's case for trashing a programming language than you might as well practice what you preach.

C certainly isn't secure by design, but there are plenty of demonstrably secure projects developed in C and C++ (and it's not like Node is self-bootstrapped, either). To answer your question, yes, I would prefer one written in C. Any day of the week.

> Point is to use them to do other cool things client-side. It's a Really Big Toolbox. The CSS/HTML part can potentially provide interesting options as well.

Dragging along such a massive runtime environment is such a heavy cost for that, though. And, again...in a terminal? I'm not judging every since Electron app, right now, I'm just judging HyperTerm.

> The latter quote is from the comment I was replying to. It is not a "salient point," but simple JavaScript hate. His other points were that, in the past, he had written a JavaScript terminal as a school project that he ended up hating, it took him thousands of lines of code, and he'd done it before Node existed to provide the batteries. What salient points do you actually refer to?

Honestly? Parent didn't make any. I'm just tired of people defending programming languages like they're more than just tools. It's fine to hate tools. Obviously this person's JS hate is coming from an informed place, because they've written a fair chunk of it.

Hey, I have a few issues with your attitude.

Firstly, if there is one piece of software that I want to be fast, lightweight, and most importantly secure, it's my terminal emulator. The hard part isn't drawing characters to the screen (which is what HTML and CSS would help with), it's the VT100 parsing and logic, which can be written in...well, anything, really.

I would first like to point out that the HyperTerm OSX zip is 43mb, and the unzipped HyperTerm.app is 123mb.

Supporting exactly one OS: again, the OS specific bits aren't the hard part. Blitting characters to the screen is easy, and platform independence certainly isn't worth 123mb of overhead.

250k+ Node modules: The number of packages in a package repository is a poor metric for determining anything except the number of packages in the package repository. npm has tons of redundant or ill-maintained packages, and that's even before we discuss whether having a bunch of available packages makes a terminal better at all. In my opinion, it doesn't, and this circles back around to the fact that a terminal needs to be secure. I sure as hell don't want random unaudited code running in the same application that I use to administer systems.

Standardised plugins: what standardised plugins? npm modules? Not sure what you mean here.

Can't open web pages locally: Why should a terminal do that? As a party trick? I don't want to stand in the way of improvement, here, but I also have no problem opening a separate web browser to browse the web.

Javascript hate: It's not hate when people bring up salient points. Just because the web platform is open and everybody is using it right now doesn't mean that it's perfect or above criticism.

How are they two separate issues? If you don't go as fast as possible, you can get less work done before your deadline. Even with today's CPUs and the kind of parallelisation that a good DAW program will do, I still routinely see producers (myself included) hit CPU usage limits. In audio DSP, programmers have responded to the increase in CPU capacity not with higher-level languages but instead with more computationally expensive algorithms (modern filters, for example, use techniques derived from circuit simulators for solving nonlinear equations).

Besides, actually writing the DSP code makes up a comparatively tiny portion of the development time. Tuning and tweaking the DSP algorithms takes far more, and designing the user interface dwarfs both. I know multiple audio products which use Lua for their UI layer because the productivity increase is so significant. And there, you don't have to worry about performance to anywhere the degree you need to in the DSP.

Writing everything in C/C++ has its own host of problems, but it's roughly the name of the game in anything realtime. It's easy enough to think about writing one effect or synth in a slower language, but keep in mind that modern digital audio workstation software is expected to run up to hundreds of plug-ins to produce one block of audio, and that's just not possible without being directly on top of the metal. Even vanilla C/C++ often isn't enough; generally, there's a necessity to drop down into assembler or at the very least use SSE intrinsics.

So, I mostly use C (not C++) for my audio code. I won't touch anything garbage collected for realtime DSP at all, so Go is right out.

Rust, on the other hand, I am very keen to explore, especially with some of the SIMD work that's been brewing. Somebody made bindings for the VST2.4 API/SDK already, and I've been mulling over putting together a brief proof-of-concept with it: https://github.com/overdrivenpotato/rust-vst2

If your plan for speeding up a slow user HTML/JS interface is to rewrite parts using WebGL, you're severely underestimating the amount of support code you'd need in order to make that happen. Coming from somebody who has developed and maintains OpenGL user interfaces, you're better off just writing the native app.

WASM isn't even ready for day-to-day use yet, and while ASM.js is mature, V8 has no special optimisations for it.

Furthermore, you're still running the code on the Javascript VM/interpreter, so it's unlikely to give much of a speed boost. The motivation behind WASM and ASM.js both is to cross-compile code from other non-JS languages (generally, C/C++) into code usable from JS.

You're right on the second point and the third, though I reckon the fragmentation isn't appreciably worse than in a regular wrap-around circular buffer. Same goes for the first point. I'm keen to see examples where bip buffers exhibit particular issues relative to circular/ring buffers, however, and if you've got any then please send them along.

The chief use-case for my bip buffer implementation is using a shared memory segment for inter-process communication, and adding mmap() for address mirroring on top of that just seems like a can of worms I'm not particularly interested in opening.

For a similar end result (a circular buffer from which all returned ranges are contiguous) but without OS support for mmap()ing, there's also Bip Buffers[0]. I did an implementation in C [1] designed to be used for zero-copy IPC over shared memory (by way of having a structure with a flexible array member for the actual data).

[0]: http://www.codeproject.com/Articles/3479/The-Bip-Buffer-The-...

[1]: https://github.com/wrl/wwrl/blob/master/src/bip_buffer.c

Also worth a watch is Conspiracy's close runner-up, "Darkness Lay Your Eyes Upon Me"[0].

[0] https://www.youtube.com/watch?v=0Py1PdrLORQ

We've got all the crypto-related code available at https://github.com/wireapp.

It's also an unavoidable part of writing graphical code on OS X, so, for all intents and purposes, it is the OS.

A big reason why multithreaded UI doesn't work is that the platform code (win32, cocoa) generally has poor support for interacting with OS objects from multiple threads. For instance, NSView instances can only be operated on from the main thread (https://developer.apple.com/library/mac/documentation/Cocoa/...).

Handling OpenGL context access from multiple threads is terrible, too. I'm quite excited about the additional threading niceties that we're getting in Vulkan, which should allow separate threads to re-render parts of the UI and then send the command buffers back to the main thread.

It would be excellent to have a non-LinkedIn login method for applicants.

Is there any schedule for when that'll be worked on? It's a big thing I'm waiting on for porting some UI toolkit work to Rust.

And it's not like putting "tiny" before anything differentiates it to any significant degree. I mostly thought the coincedence was funny. ;)

Oh hey! Funny to see an OSC implementation called "tinyosc" that isn't the one I wrote in Rust a month or so ago [0]. ;)

In all seriousness, you could also look at fundamental's rtosc[1], which is fairly minimal as well but has been around for a while and is being used in the ZynAddSubFX synth.

[0]: https://github.com/wrl/tinyosc

[1]: https://github.com/fundamental/rtosc

Do you have a source for "no plans on adopting Vulkan"? Apple is definitely on the Vullkan working group (logo is part of the image at the bottom of https://www.khronos.org/vulkan).

> Any audio issue where the paradigm is "give the API a callback and it will get called once in a while with samples" is terrible for multiple reasons

This is, actually, how most professional audio APIs are designed and they generally work quite well. ASIO, VST, JACK, PortAudio, CoreAudio, etc.

Would be nice if the tab key inserted a tab instead of jumping to the next field (for writing code, etc).

This is the big one I'm waiting on before betting the farm on Rust, and I suspect I'm not the only one.

Hey, no problem, thanks for taking care of that. Sorry about my acerbic tone!

Really enjoying this "Please sign in to save view settings" modal box that pops up when I try to move the divider between the post and the source code. Who thought that was a good idea?

Still having difficulties registering here.

> Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.matterhorn.io/users.json. This can be fixed by moving the resource to the same domain or enabling CORS.

ConcurrencyKit[0] also has an implementation of epoch-based reclamation, which I've been experimenting with lately (with good results).

[0]: http://concurrencykit.org/

This actually looks really cool, but seems to have no support for concurrent modification or access. I'm presuming that in order to make this thread-safe you'd just need to lock the whole database.

Anybody aware of any thread-safe model layer for C?

Developer edition doesn't seem to respect the setting for default profile. It always opens its `dev-edition-default` profile instead.

The funny thing is that we reported this sometime in 2009 (might have been 2010), they "fixed it" and released a new version, but the new version only crashed somewhat less often.