Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hello Lua

haxe.org

Post reply on HN
Print view View original

61–70 of 74 posts

Re: Hello Lua

#61

Post by colbyAFTrustedK »

robocat wrote: post #36
colbyAFTrustedK wrote: post #35

Earlier quoted context omitted.

Is there a meaningful ? I.e., what does classical inheritance get you that prototypes-under-the-hood don't? For a programmer using classes, that ES's are implemented using prototypes should be as important has how the JVM works.

Classical inheritance enforces that a method can only be overridden by another method in a subclass. Prototypical "inheritance" allows different types of values to be assigned to the same symbol. E.g. if you have a method bob() on a prototype, you can set object.bob = 'astring'; and it isn't an error.

That has more to do with a language opting out of having fixed types than it does with class-based versus prototype-based inheritance.

Re: Hello Lua

#62

Post by Rusky »

choosername wrote: post #58
tomcam wrote: post #2

Haxe is one of the best kept secrets of the programming world. Created by none other than the author of curl, it's A C-ish, javascripty, but strictly typed language with almost infinite portability. It "compiles" to many different target languages, from PHP to Java to Python to C++ and more. It's fast, has a beefy standard library, well-documented system interfaces, and just feels fun. A remarkable accomplishment.

> "compiles" * transpiles

"A compiler is a computer program (or a set of programs) that transforms source code written in a programming language (the source language) into another computer language (the target language)" [0]

Haxe does everything a typical compiler does, right up until the very last step. Not much point in correcting people about the use of the term.

[0] https://en.wikipedia.org/wiki/Compiler

Re: Hello Lua

#63

Post by benologist »

greenspot wrote: post #5

From Haxe's introduction: > Its syntax largely follows the ECMAScript standard, but deviates where necessary. Anyone can tl;dr the main differences to JS?

Basic for loops:

    for(x in 0 ... 5) {
        // increment by +1 only
    }
More verbose JSON:

    var t = Json.parse("{ x: 1 }");
    var tx = t.x; // just might be undefined
    // vs working
    var tx2 = Reflect.getProperty(t, "x")
Tricky array sorts:

    myArr.sort(function(a, b) {
        // just might crash
    });

    // vs stable
    haxe.ds.ArraySort.sort(myArr, function(a, b) {
    });
More verbose everything:

    var v1 = 0;
    var v2 = 0;
    var v3 = 0;
    
    var v4 = function(a, b) {
        // also no 'arguments', that's more verbose too
    };
Different syntax for familiar libs (if supported):

    https://github.com/andyli/jQueryExternForHaxe

    new JQuery("li").hide(); // $("li").hide()
If you're not targeting JS your HTTP requests are probably going to be synchronous and block the main thread.

If your target is only JavaScript / NodeJS you can get a lot of the benefits of Haxe by using TypeScript, with a much larger ecosystem to help you achieve your goals quickly.

Re: Hello Lua

#64

Post by stcredzero »

nacs wrote: post #52
alexatkeplar wrote: post #22

If you have a piece of business logic that you want to make available in N languages/platforms, is Haxe a valid option? The only other alternative I know is to write a library in C/C++/Rust and use the FFIs in your target languages to call it.

Definitely. I use it for some game development projects and its able to compile and run code on all Windows/Mac/Linux/iOS/Android (all native code) and even Javascript+WebGL. Obviously the framework I use is targeted to games but there are other frameworks that target webdev (can target Node.js/PHP and lots of other things).

Obviously the framework I use is targeted to games

Which one is that, and how well does it do cross-platform?

Re: Hello Lua

#65

Post by mrcdk »

tluyben2 wrote: post #15

If Haxe had an interpreter (not hscript as it is far too limited) I would use it for a lot. Now compiling takes too long. The JS version is quite fast but not good for everything. It's a fantastic product though; in my experience it is write once - run anywhere. With some tweaks but that's to be expected. Please someone implement an interpreter in Haxe for Haxe.

Haxe has an interpreter mode if you use --interp as a target

I haven't used it so I'm not sure how powerful it is

Re: Hello Lua

#66

Post by mrcdk »

NicoJuicy wrote: post #32

Haxe seems an interesting alternative for mobile development ( cross platform) for my currently chosen way : Xamarin. Any tutorial for a crossplatform app on haxe with using native features ( eg. gps)?

Haxe is cross platform in the sense of being able to compile to different languages not in the sense of merging different platform features into one library.

For example, you can use Haxe to build a native Android application using the Java target as you would do with using Java in the first place. Same with iOS (but using the C++ target)

AFAIK, there isn't any active project that offer the same as Xamarin in Haxe. You could, in theory, use Haxe to target C# and Xamarin but I haven't tested it.

Re: Hello Lua

#67

Post by pierrec »

anifow wrote: post #34
tomcam wrote: post #2

Haxe is one of the best kept secrets of the programming world. Created by none other than the author of curl, it's A C-ish, javascripty, but strictly typed language with almost infinite portability. It "compiles" to many different target languages, from PHP to Java to Python to C++ and more. It's fast, has a beefy standard library, well-documented system interfaces, and just feels fun. A remarkable accomplishment.

Also, HaXe is the only viable technology which enables a high-quality canvas-based applications which mirror native applications (while also permitting compilation to those native applications).

I suppose you're not counting the likes of NW.js and Electron because the native version isn't really native - though from the user's perspective, it can feel as native as a Haxe application, assuming they don't look at the ridiculous distributable size and RAM usage of the NW version.

Even then, this still leaves C/emscripten which can also fulfill those requirements, and with similar output sizes (I've tested both and compared the sizes of the resulting web versions, seems that both have an overhead of 1-2 MB for a small graphical application). It depends on what you're planning to do, but one problem I found with Haxe is that it's lacking a good general-purpose UI library that also works well on the web target. Only lower-level graphics libraries.

Re: Hello Lua

#68

Post by zem »

daurnimator wrote: post #8
PeCaN wrote: post #6

Earlier quoted context omitted.

Haxe is what ActionScript should have been. However (imo), it's hard to find a niche for it now. What does it get me that Perl and OCaml don't? I've been drawn to Haxe several times over the years, but have never really thought of a project, "huh, Haxe would be a great fit here". Maybe if I wrote a mobile game or something.

The reason we started using it at work was we could target both Javascript and Flash from the one codebase. However, we finally don't need to support flash anymore... so now there's no reason to not just write in javascript.

from what little i've seen of haxe (used it for a few toy projects), it seems a lot more pleasant to program in and to maintain than javascript.

Re: Hello Lua

#69

Post by i336_ »

signa11 wrote: post #59
delroth wrote: post #43

Earlier quoted context omitted.

> CloudFlare's firewall system uses LuaJIT to analyse approximately 4 million GET requests per second. While I agree with your premise (LuaJIT is a pretty awesome project), this example means nothing in terms of performance. — "analyse" doesn't give an indication of the workload -- it could vary from "matching against a precompiled regexp" to running advanced statistical models. — 4 millions requests per second does…

> While I agree with your premise (LuaJIT is a pretty awesome project), this example means nothing in terms of performance. Yup, without knowing deployment details etc this number doesn't really mean much. perhaps you might have heard of the snabb-switch project ? which does line rate 10gbps forwarding of 64b packets on a single x86 core. entire thing is written in lua including the user land 'drivers' for Intel 10g…

Wait, wait. Lua or LuaJIT? That's amazing!

Re: Hello Lua

#70

Post by jestar_jokin »

sspiff wrote: post #17
jestar_jokin wrote: post #4

Earlier quoted context omitted.

cURL was created by Daniel Stenberg, Haxe was created by Nicolas Cannasse. (EDIT: beaten) My favourite Haxe feature is compile-time macros. This leads to massive meta-programming and language extension capabilities. My least favourite aspect is that it does not strictly unify or abstract every target language & runtime, so you end up writing in that language's semantics but using Haxe as syntax sugar. (Good for C++,…

Can you explain what you mean by "not strictly unify or abstract every language & runtime"? In day-to-day use, how would you notice this problem? Can you give an example of what problems or hurdles this can cause? I've only used Haxe briefly for a few small game demos, and loved it, but I've only used the JS backend.

Some targets will have different behaviours regarding null[1], mostly for static language targets; e.g. basic types that are represented by primitives cannot be null when targeting C#, Java, Flash, or C++. Dynamic language targets don't have this issue. (Can be avoided by wrapping your values in Null).

Overflow is normally not handled consistently[2]; it's left up to the target platform to define the overflow behaviour. E.g, JS only has one numeric type (a 64-bit floating point), and can't represent integers over 52-bits. Can be avoided by using Int32 and Int64 classes, but this reduces the code interop if you want to export a library (consumers would need to make use of the Haxe representation of a 64-bit integer).

Arrays aren't fixed sized; if you want this, you need to use Vectors[3], which aren't interface-compatible with Arrays, so you can't use them as a drop-in replacement. (Compare this to Java's Collections API.)

File system access isn't available on every platform, e.g. JS, Flash. If you target Node.js you can use the file system, you just can't use the normal file API, so you need to write stuff specific to each target.

Dates are, as always, a pain to deal with. Timezones aren't supported by the Date class[4]. DateTools.makeUtc() is not available on some platforms[5].

The built-in database API is only accessible on C++, Neko (Haxe-specific bytecode/runtime), and PHP[6]. AND it only seems to support MySQL. This has stymied my ideas about a cross-language multi-DB ORM.

Basically, you have to intimately know the gotchas of every language you target, and if you already know them you may as well write in that language.

Having said all that, Haxe seems to be greatly improving these abstractions with every release; I think given enough time, it will become an amazing tool. I'm starting to use it in place of Python as my "go to" language. For most purposes you can just use a single target; Neko works well for most functionality, but you can always target C++ for "true" cross-platform compatibility and performance, and JS for the browser.

[1] http://haxe.org/manual/types-nullability.html

[2] http://haxe.org/manual/types-overflow.html

[3] http://api.haxe.org/haxe/ds/Vector.html

[4] http://api.haxe.org/Date.html

[5] http://api.haxe.org/DateTools.html

[6] http://api.haxe.org/sys/db/Mysql.html

Post reply on HN