A lot of this complexity seems down to the way Windows works, though. As a Linux user, the amount of somewhat confusing/crufty stuff going on in a typical Windows install boggles the mind; it’s almost as bad as Emacs.

Shenzhen I/O is pretty rad too; bought the feelies for that one, and get asked about the binder routinely :D

If verilog/VHDL is your kink, MHRD is a lot of fun.

Agreed, this is absolutely brilliant. Well done diamonomid!

Anyone know of a place in the US where I can buy a pair of u2f-zeroes? The website links to amazon but they’re sold out.

Awesome! I didn’t know this existed. I’m a huge fan of Netlify and use it for a lot of projects. Didn’t realize y’all have a CMS that works like that – I will investigate this fully.

Your service is fantastic. Super clean + useful.

I’ve believe Gatsby also supports this via its WordPress plugin. I don’t know how well it works, but lot of people (especially non-developers) are comfortable with the WordPress UI, so it could be a nice combo.

Slowly. You sponsor it slowly.

In Bitcoin.

Might place more requirements on both lang and lib than you were asking for, but I’ve been messing with a reterr (return error) keyword in my language Tiko that works alot like Rust’s try! macro/? operator.

Tiko uses an Option instead of null, so

func doThing(x Option<T>) {
    reterr x
    fmt.Println("only reached if not null!")
}

desugars into

func doThing(x Option<T>) {
    match x {
      None => return
    }

    fmt.Println("only reached if not null")
}

reterr returns on any falsey expression, any Result<T, E> that is an Error, and any empty Option<T>. Anything else continues through. It will also pass the error up from Result iff the func’s type signature returns an Error.

I like it alot. It makes for some VERY clean code that reads declaratively but doesn’t seem out of place in the imperative style. Preconditions and Go-like if err != nil { return err } handling are readable but don’t take up the majority of visual space on screen.

I worry because it does quite alot of things. It blesses Result and Option, plus it just happens to work with falsey expressions which aren’t necessarily errors. It’s got utility, but not exactly the greatest in terms of aesthetics from a language design standpoint. reterr and return are also super similar visually and might be confused/missed. Since this is mainly a toy language it’s mostly just me having fun and I haven’t had much issue with it so maybe I’m just too hesitant to commit ;)

It’s definitely not a new idea (mostly ripped off from rejected ideas in the Rust ? operator RFC) but given your comment I thought it might be interesting enough to merit a reply.

Some languages (like lisps/schemes) have when and unless. (when foo bar ...) is similar to if (foo) { bar ... }, (unless foo bar ...) is like if (foo) {} else { bar ... }.

ensure is probably one of the better terms to use for this. I might steal this!

I personally like unless keyword, though unfortunately it’s not present in Java. Also one I really liked (maybe most) is a pattern-matching-like approach I saw in Erlang:

execute_timer(entity) when entity /= null ->
    sound_alarm(entity);
execute_timer(_) ->
    do_nothing.

Swift has the guard statement.

Here is a rough translation of the function in the linked article.

func run(timer : Timer) throws
{
    guard timer.enabled else {
        return
    }
    guard timer.valid else {
        throw InvalidTimerException()
    }
    timer.run()
}

What’s the Xi plan for things like VCS integration? Reading the README and Roadmap, it looks like there’s no plan for UI-level extensions? I see https://github.com/google/xi-editor/issues/160 which makes it seem like xi-editor is going to punt extensions to the front-end for things that aren’t language features, do you think that’s a fair description?

I think that’s something that atom (and presumably whatever this turns into) has going for it; it’s extension story is really strong, and being tied to Electron (rather than being front-end agnostic) is a big piece of that. I wish Emacs had a UI library built in, rather than a bunch of TUI stuff.

EDIT:

also, not sure if this was you, but: Comparison to Xi #4 :D

Why not a GUI using nvim server as the base?

And as a UI layer, I think javascript + dom + css has a lot going for it

Is performance one of those things?

there’s a lot more to a text editor than the editing area though, right? Just because the text editing component is rendered outside the DOM doesn’t mean the settings dialongs, or VCS integration, or sidebars, or embedded help browser, or popups, etc. aren’t. And in terms of extensibility, those are the things that should have an easy interface that many, many, many developers are used to, since that’s where the grand majority of useful extensions seem like they could end up.

I think it’d be rad to see people get past “if it’s Electron is has to be 100% DOM + Javascript”, which will help with the anti-electron stance I’ve seen a lot. It’s a tool with strengths and weaknesses, and using it only for it’s strengths seems like a pretty good idea…

I think people are just tired of seeing posts like Electron is cancer every other day. Electron is here, people use it, and it solves a real problem. It would be much more productive to talk about how it can be improved in terms of performance and resource usage at this point.

It’s tragic that desktop platforms are utterly non-interoperable and require near-complete duplication of every app.

It’s a necessarily sacrifice if you want apps that are and feel truly native that belong on the platform; a cross-platform Qt or (worse) Swing app is better than Electron, but still inferior to the app with a UI designed specifically for the platform and its ideals, HIG, etc.

It’s tragic that desktop platforms are utterly non-interoperable and require near-complete duplication of every app.

There is a huge middle ground between shipping a web browser and duplicating code. Unfortunately that requires people to acknowledge something they’ve spent alot of time working to ignore.

Basically c is very cross platform. This is heresy but true. I’m actually curious: can anyone name a platform where python or javascript run where c doesn’t run?

UI libraries don’t need to be 100% of your app. If you hire a couple software engineers they can show you how to create business logic interfaces that are separate from the core services provided by the app. Most of your app does not have to be UI toolkit specific logic for displaying buttons and windows.

Source: was on a team that shipped cross platform caching/network filesystem. It was a few years back, but the portion of our code that had to vary between linux/osx/windows was not that big. Also writing in c opened the door for shared business logic (api client code) on osx/linux/windows/ios/android.

Electron works because the web technologies have a low bar to entry. That’s not always a bad thing. I’m not trying to be a troll and say web developers aren’t real developers, but in my experience, as someone who started out as a web developer, there’s alot of really bad ones because you start your path with a bit of html and some copy-pasted javascript from the web.

It’s tragic that desktop platforms are utterly non-interoperable and require near-complete duplication of every app.

++ Yes!

Try comparing a high quality native macOS app like Fantastical with literally any other approach to calendar software: electron, web, java, whatever. Native works great, everything else is unbearable.

Wait, what? I think there’s two different things here. Is Fantastical a great app because it’s written in native Cocoa and ObjC (or Swift), or is it great because it’s been well designed, well implemented, meets your specific user needs, etc? Are those things orthoganal?

I think it’s easy to shit on poorly made Electron apps, but I think the promise of crossplatform UI - especially for tools like Atom or Hyper, where “native feeling” UI is less of a goal - is much too great to allow us to be thrown back to “only Windows users get this”, even if it is “only OS X users get this” now.

It’s a tricky balancing act, but as a desktop Linux user with no plans to go back, I hope that we don’t give up on it just because it takes more work.

Cheers!

PS: Thanks for the invite, cross posted my email response if that’s ok :)