Ha, anyone remember Microsoft's Tay?

That kind of makes sense for a lowest common denominator.

Then what is it good for? Just simple apps?

it's good for apps that don't have _that_ much platform specific parts, but have lots of application logic. Such as games.

It's an OK language for backend server - esp. if you also have a frontend client in the same language (such as the game and the multiplayer server backend).

Does it have WASM support yet? That might be a good fit.

not natively, but because haxe compiles into C++, you can setup a wasm pipeline from that (presumably). Probably not something commonly done so there's no premade tooling for it.

Edit: it seems someone has setup a hello world example of using emscripten to compile haxe into wasm: https://gist.github.com/MatthijsKamstra/cbae06ae1dc3561621e4... - it's not that difficult apparently!? Color me surprised.

> Then what is it good for? Just simple apps?

It fits the niche of people who have legacy applications written in Flash, and want to rewrite them in a modern stack. There's a battle tested, free, cross-platform implementation of the Flash API called OpenFL. For people who were familiar with that stack, Haxe offers a natural path to migrate.

So, tl;dr its typical use cases are game development and making legacy Flash projects maintainable.

The C++, JS and Hashlink VM targets are generally well maintained. The situation with libraries is meh, mostly due to being a not-so-mainstream programming language that is almost 20 years old. So, there are a lot of libraries that weren't updated in a decade. Some of them may work on new Haxe versions, some won't. Some have been consistently maintained for very long, but are a one man show and the documentation is often subpar. Ceramic is one of such libraries, although the documentation for it is better than the usual for Haxe, IMO.

Overall I find the language itself amazing and pleasant to use. Kinda wish the C# target was still a thing with first-class support, so we could enjoy their hot reloading.

Besides OpenFL, there is also HaxeUI. Any experience with that? Thanks.

I have played with it a bit on side-projects. TL;DR: would not recommend it unless you're building a game or is in unique circumstances. Pick something with a faster feedback loop for development GUIs.

While HaxeUI is usable, you'll be on your own a lot: * Documentation is scarce * You'll likely run into bugs the moment you try to go beyond hello world examples * No promises of regular releases or API stability whatsoever. You're expected to run versions directly from GitHub * wxWidgets backend sometimes segfaults with the examples from its HaxeUI's website * tooling is subpar for GUI apps in Haxe; forget having anything as good as any modern frontend framework with Vite. Hot-reload somewhat works on HashLink, but there's almost no documentation on how to use it.

It's maintained by a very nice dude, who does a good job considering the coverage of his libraries, the fact that he does that by himself, and the fact that the OpenFL-based backends work well. HaxeUI is used in production by a few people who work with the HaxeUI developer.

FeathersUI is another option, with much, much better documentation (probably one of the best for Haxe libraries), but smaller component coverage than HaxeUI. I ran into less bugs with it in general, and the dev seems more focused on consistent, well-tested releases. Also a really nice guy from my experience, just like the HaxeUI dev.

But overall, iteration times of GUI applications is just not good with Haxe. You'll suffer if you are used to modern frontend tooling. The accessibility story is nonexistent. And I'm not sure the performance would even be better than just opening a WebView. Definitely not on mobile.

I would only recommend using those two libraries in three circumstances: * You are building a one-off GUI tool that has a simple interface. Think something like LunarIPS. In that case, you can get something usable pretty quickly which will look good if you don't care about following the native toolkit (don't go the hxWidgets path, it's guaranteed suffering). * You are building some interface which will be used inside a game made with Haxe. Say, a login form inside your multiplayer game. In that case, it makes perfect sense to use one of those two libraries. * Your application, for whatever reason (personal taste included), will have a more game-y UI, and it makes more sense to code it in a game engine than the DOM or Qt or whatever.

A fourth reason that is valid for anything is if you're in a Haxe shop, and want to maintain a single language for all projects. Those places do exist (like Shiro Games).

I think that if I __had__ to build a GUI program in Haxe these days, I'd build a prototype with vanilla JS or React first, iterate on it, and only start a HaxeUI/FeathersUI version later.

Thanks for a detailed note sharing your experience. Very informative.

I remember using pip and venv back in like 2009. Last time I checked, maybe 5 or 10 years ago, the recommendation of the community was generally to just use Docker instead of all these tools. Did that not catch on?

The advice seems to change every year. For a while it was venv, then pipenv, poetry, docker, and now uv. Maybe the ecosystem will settle on that but who knows.

I mean docker is orthogonal to package manager. It makes it easier to deploy but none of the other thing also have managers do are relevant.

Docker was always a workaround to Python not having a non-awful dependency manager. uv is that non-awful dependency manager, and I expect in the long term it will reduce the use of Docker.

Docker solves a different problem. Docker is a way to basically ship your whole OS off to another machine. You still have to have a way to install the right version of python and all the python libraries you need inside the Docker container, and uv is great for this.

Secondly Docker only solves a subset of problems. It's fine if you're developing a server that you will be deploying somewhere. It's inconvenient if you're developing an end user application, and it's completely useless if you're developing a library you want people to be able to install.

For the nested if-let mess, I'd probably do something like this:

    (let-every [x (foo)     err "foo failed"
                y (bar x)   err (format "bar %s failed" x)
                z (goo x y) err (format "goo %s %s failed" x y)]
      (qux x y z)
      (handle-error err))

Where `let-every` is a macro that works like let, but stops short on the first nil/false variable, runs only the next symbol binding expression, and then runs the else-clause.

There'd be nothing special about the "err" symbol on each line. It's just the next symbol binding, but on the same line as a convenience, and this means it can reference any previously valid symbol bindings.

Here's a quick & dirty implementation of that macro. I don't have a Clojure interpreter installed, so I don't know if it works.

    (defmacro let-every [bindings if-body else-body]
      (let [pairs      (partition 2 bindings)
            quad-pairs (partition 2 pairs)]
        (loop [quad-pairs quad-pairs]
          (if quad-pairs
            (let [[quad-pair]         quad-pairs
                  [try-pair err-pair] quad-pair
                  [try-sym try-expr]  try-pair
                  [err-sym err-expr]  err-pair]
              `(if-let [~try-sym ~try-expr]
                 (recur (next quad-pairs))
                 `(let [~err-sym ~err-expr]
                    ~else-body)))
            if-body))))

Given the above example, it should expand to this:

    (if-let [x (foo)]
      (if-let [y (bar x)]
        (if-let [z (goo x y)]
          (qux x y z)
          (let [err (format "goo %s %s failed" x y)]
            (handle-error err)))
        (let [err (format "bar %s failed" x)]
          (handle-error err)))
      (let [err "foo failed"]
        (handle-error err)))

Given the existence of exception handling, I would rather apply the pattern:

   ;; Plain old ANSI Lisp

   (let* ((x (or (foo) (error "..."))))
          (y (or (bar x) (error "bar ..."))
          ...)
     body)

I mean, if, in the end, we are going to "error out", rather than just forward-propagate `nil`.

If we are going to just propagate `nil`, then if we have an `iflet` that tests the last variable, we can do:

  (iflet ((x (expr))
          (y (if x (bar x))
          (z (if y (foo x y))) ;; z is tested by iflet
    ...)

it's just a bit verbose. That can be condensed with a simpler macro that doesn't have the err stuff.

Your solution doesn't short-circuit when any of the calls fail. It relies on (error) throwing some kind of exception to interrupt control flow and prevent the following lines from executing.

Yes; I'm using ANSI CL syntax/semantics. error denotes cl:error which can in fact be relied upon to throw. That's what I mean by "given the existence of exception handling ...".

Substitute your favorite dialect's error thrower.

I wrote something like that several years ago: https://github.com/egamble/let-else

I really like `:delay`. It will allow efficiencies in my already Haskell-esque "define all possible values used in a single big let" style I program in. My code all handles nil safely and returns nil when appropriate but it would be even better to avoid evaluating things unless used in the body of the else (or a later binding).

Really cool! May have to borrow this some day.

OP already conceded if these funcs return nil the solution is easy; the case considered was when the funcs return heterogeneous data

Or when you want to do logging. That's the part I was working at.

>Given the above example, it should expand to this:

I don't think that your expansion is correct at all. Maybe you have a misplaced quote somewhere, but this one is not making sense.

After spending 50 months with Clojure, I can safely say it's my favorite server-side programming language (with Datomic as my favorite database), and the tooling (CIDER + Paredit + Emacs) is really downright amazing in terms of productivity.

Although the tooling is great, I found it super frustrating that you basically have to use the entire suite of prescribed tools to feel productive. Basically everything except emacs sucks with clojure, especially if you're a vim user. I found that pretty frustrating. Vim fireplace sucks. Then if you want to use a gui editor with a vim plugin you have to abandon the vim world and use editor-esque paredit plugins (since no one is developing vim-style paredit for vim-editor-plugins) gasps for air.

Then finally there's emacs which I really don't want to get started with.

I switched to IntelliJ + Cursive, and haven't looked back since.

Yes! 1000 times, yes!

I was a long-time vim use, and I found slimv to work pretty well with Common Lisp, but at the time I was never very interested in Clojure. Since then, I've switched to emacs using evil-mode to provide a vim editing experience: and, I have to say, evil-mode is almost better than vim itself. I've used evil-mode+cider to develop a couple clojure web apps and, I've been very happy with my setup.

http://paste.lisp.org/display/340427

(and, yes, I have tried spacemacs, but found it unpleasant)

Atom + ProtoREPL[1] + Parinfer[2] is surprisingly good for clojure, without having to learn a swath of form manipulation keybindings. I haven't tried combining those with vim bindings. This (https://gist.github.com/jasongilman/d1f70507bed021b48625) is more or less how I have it set up.

1: https://github.com/jasongilman/proto-repl

2: https://github.com/oakmac/atom-parinfer

For what it's worth, I'm a pretty happy vim-fireplace user for evaluating files and forms. I also happily use standard vim brace matching, text-objects, etc instead of paredit or similar.

For JVM development, I only bother with NREPL because vim-fireplace needs it. For library development, `lein repl` gets the job done. For application development, I copy/paste around just enough code to launch an nrepl server and run the Clojure jar directly with a vendored directory of jar files. No other tools needed really.

Yeah it's a very real form of lock-in, nothing else really compares to Emacs + Paredit + Cider for productivity. And Emacs isn't great. But when I did Clojure full time for 5 years, I just sucked it up and learned Emacs and got really good at using it. Customizing my init file little bits at a time probably added up to a month's worth of lost productivity. But out of 50 months, 1 month lost to environment setup isn't bad. That's like 2% of the whole time. Or about 48 minutes per week. And the learning curve for me (as a long-time vim user) wasn't as hard as I thought it'd be, especially since knowing bash shortcuts really helped prepare me for the Emacs way. In fact I even took some Emacs knowledge back to the shell, such as how Ctrl-underscore is "undo the last edit to the current command".

I am using https://cursive-ide.com/ since early public versions and nothing from vim or emacs world compares to this for Clojure.

I wrote a post detailing a couple of possible editor choices (but focusing on first-timers and people who only occasionally need to edit Clojure code while working on something else - I think Nightcode is a good choice in this case - so probably not directly applicable to you): https://klibert.pl/posts/tools_for_lisp_syntax.html

Still, the two screenshots there (of my Emacs config) may help convince you to give Emacs a try.

It's definitely not as integrated into Vim as in Emacs, but I use Vim exclusively with Clojure and have no real issues with it. For ClojureScript, Figwheel automatically hot reloads on file save, so there's no interaction with the editor at all. With Clojure, either lein-ring automatically reloads as needed, or I can eval the changed file in an open REPL with Fireplace.

I have gone down the same road. I settle with Intellij, Cursive is quite good and as a Vim user, I have vimidea which is pretty ok. Background: I find Vim or Emacs really slow when you develop big projects, Intellij is much more responsive which is exactly what I needs to get things done.

I use whatever editor at any given moment and then use (use 'my.testing.namespace :reload) in a repl in a terminal window. I have to watch for namespace collisions in the repl when refactoring into other namespaces and reloading those, but works really simply.

Just to keep piling on, intellij + cursive is pretty incredible.

I couldn't be happier with vim-fireplace, vim-sexp, and vim-sexp-mappings-for-regular-people. What about vim-fireplace is frustrating for you?

Highly recommend LightTable. its perfect for clojure.

Isn't it abandoned by it's author?

Then what about ChromeOS? Do you think they're trying to build a "full-fledged" OS for the modern era, with safety and security in mind, but not as lightweight as ChromeOS?

It's likely to be lighter than ChromeOS.

ChromeOS was a locked down userspace on top of Linux. Fuchsia gets rid of the Linux.

Linux was the only remotely useful, sane, and lightweight part of ChromeOS.

It was also the primary vector for security vulnerabilities.

Linux may be hacky, but it isn't exactly heavy.

I think this is a symptom of internal rivalries at Google. Seems like a combination of Dart (arch-rival to Go) and ChromeOS (arch-rival to Android).

That's not necessarily a bad thing -- Google's M.O. has always been to try lots of different things at once. But it may mean they literally don't have a solid long-term plan for it yet.

"arch-rivals"? That's overly dramatic. Go and Dart are hardly competing with each other, as are ChromeOS and Android.

I was being a little tongue-in-cheek, sure, but only slightly. They're both fairly recent languages, both representing a vision of how to fix the mistakes of the past. I'm sure the leaders of the teams see each other as rivals.

The memory mapping model is really interesting, since it moves a lot of that out of the kernel and into user-space, but it seems like it has more disadvantages than advantages. What am I missing?

Are you asking about VMOs or VMARs?

In general: it gives a process a huge amount of flexibility in terms of how it sets up its own address space, communicates with other processes, and in how it can communicate with the kernel.

Big advantage is better security.

And it can be a lot faster. Jumping in and out of the kernel is slow, shared memory is relatively fast.

This is pretty terrifying. So many "arbitrary code execution with root privileges" exploits! They may be fixed, but how many more are still only known to malicious third parties?

And without even needing to install anything! "Processing maliciously crafted web content may lead to arbitrary code execution."

I can't recall so many (80?) security fixes in a recent iOS update. A malicious font, audio file, image file or website can cause arbitrary execution?! When a file parser or Safari is vulnerable, why doesn't the iOS sandbox block device/root modifications?

What happens if your device is already infected? Does the update process replace all OS files or could an infected device still contain malware after upgrade to 10.3?

Are there tools or apps that can report system level logs, e.g. could iOS 10.3 detect and report if known-malicious files are present on a device?

"may lead to arbitrary code execution" often means they didn't take the time to detect whether it does.

Reason is that it isn't worthwhile to spend time on that. Firstly, it is typically impossible to prove that a vulnerability cannot lead to arbitrary code execution (to do so, you would likely have to know _all_ vulnerabilities in your code), and secondly, defense in depth still requires plugging all holes, even if you can _now_ prove they just lead to an impregnable barrier.

And already infected devices very, very likely are safe after a reboot (the OS will only run signed code, and the malware isn't signed, or even considered code), but still may carry files that could infect systems running older iOS versions.

The sandbox does block such modification, but a useful exploit would combine the arbitrary code execution vulnerability with a sandbox escape, using e.g. some arbitrary read/write vulnerability in the kernel or similar.

In that case, would the list of iOS 10.3 security fixes mention at least one sandbox escape or kernel vulnerability? Since it does not, can we assume that most (all?) of the listed "arbitrary code executions" would be isolated by the iOS application sandbox?

Or should we assume that competent attackers are hoarding sandbox escapes and thus most app vulnerabilities can be escalated to device compromise?

No, you can't make any such assumptions from the text of the update. But you can probably assume there's localhost sandbox escape (or kernel RCE) available to serious attackers.

The list does include several kernel vulnerabilities anyway so the question is moot.

Perhaps a scanner could be run on an iPhone backup directory (on disk on your Mac/PC).

You're following security updates for flaws in an entire operating system and an entire browser. This is pretty much par for the course. Chromium has one of the best security teams and one of the best SDLC processes in the whole industry, and you'll see similar update stats for them if you watch closely.

This is the opposite of terrifying for me.

My presumption with any technology is that there are security risks and issues. What is more concerning to me is the absence of information about these risks and issues.

Apple had a nice time for years while Microsoft acted as a honeypot for crackers. The absence of published problems for Apple products was merely an indication that crackers and researchers were not attempting to poke holes into the Apple ecosystem.

Sometimes Safari on iOS will freeze and I wonder what's happening.

This is pretty silly. If your Linux machine gets owned up through an RCE flaw, you aren't going to be able to rely on the "transparency" of Linux to detect the attacker. Just like with Linux, iOS KRCE is game-over for casual detection.

One of my favorite skills & challenges is do things as efficiency as possible, and using Electron for an app like this just strikes me as super-duper wasteful, especially for an app that'll be running all the time. That said, it's probably not going to make that huge of a dent in daily battery life.