1. 2

    hishamhm (of LuaRocks fame) is recently trying to develop his own take on a statically typed dialect of Lua: https://github.com/hishamhm/tl

    1. 1

      There are actually a couple of promising projects, some with common developers. See this issue on the tl repo:

      https://github.com/hishamhm/tl/issues/24

    1. 50

      I think most of the problems are ecosystem/people issues–in turn driving the language/framework problems.

      Selected short gripes on people (any one of which I could write volumes on):

      • Conflating standard library problems with language problems. ES5 was actually a pretty reasonable language–the problem came from having a standard lib so anemic (to this day!) that people feel the need to keep adding stuff. If TC39/W3C spent less time getting high on their own supply and more time fixing the standard library then so much of what I hate goes away.
      • Permanent neophilia and just an overwhelming lack of restraint and good taste. Nobody seems to acknowledge the costs to chasing new shiny.
      • Everybody uses solutions backed by Big Players without regard for whether it’s a good idea or not. Your blog doesn’t need React. Your E-commerce site probably doesn’t need Cognito. Staaaaaahp.
      • Everything has so many dependencies and this nests. Left-pad should’ve been a wake-up call, and yet apparently nobody is actually serious about fixing that.
      • Tooling is too complicated and takes too long to run. Why is setting up Webpack annoying? What is it hard to just run off a config off the top of one’s head?
      • Testing culture seems to have gone super far into unit testing and just really sucks for actual can-the-user-do-the-thing-that-makes-us-money testing. It should be easier to script UAT than to do the DI and other stuff around unit testing, but for some reason that’s not where we evolved.
      • Too much popularity-driven development. We could be forgiven for assuming that most technical decisions being made in Webland are the result of conference talks and Big Personalities posting online.

      Selected language gripes:

      • ES6+ is getting past what comfortably fits in a person’s head.
      • CSS really needs to just have nested scoping already.

      Select framework gripes:

      • React has made dumb decisions and devs won’t back down on them. className, full stop.
      • ThreeJS keeps carving out key stuff–say, orbit cameras–into the examples instead of core, keeps adding other shit into core, and somehow bungles packaging the ‘extras’ into friendly NPM modules. At least this was the case last winter when I ran into it, again.
      • D3 is super easy to make slow and awful, and just always looks like spaghetti code to me.
      • There is no good framework to do some of the Java computational geometry stuff we did two decades ago. This is likely because making a holey concave polygon from other smaller holey concave polygons and triangulating it is Real People Hard but making another vdom knockoff is Frontend Engineer Hard.

      I could go on, but why close the year on a negative note?

      1. 11

        lack of restraint and good taste.

        This sounds like the root cause of everything else here.

        1. 3

          ES6+ is getting past what comfortably fits in a person’s head.

          I agree. If you took generators out of ES6 I think you’d have a reasonably comprehensible version of JS. I can get behind optional chaining to kill _.get(myObject, 'some.path.where.any.of.these.could.be.undefined.or.null)… but the trend of just adding more things to the language is a bit concerning.

          1. 3
            1. Incredibly poor library quality.

            Basically, a JavaScript library consists of

            • gnarly spaghetti code
            • without comments
            • inside a single file
            • with some constructor that takes a config object
            • where roughly 80% of the properties are undocumented
            • and 90% of the config options are not tested with each other
            • and break hilariously when used together
            • with no existing tests, and no actual testing being done between releases,
            • which means things randomly breaking in minor releases,
            • and the project is “active”, but the authors aren’t really acknowledging any bugs.
            2. Really bad build times.

            At my work a project has somewhat above 1.5m lines of Java code, and probably less than 50.000 lines of JavaScript.

            The 1.5 million lines of Java build faster than the 50.000 lines of JavaScript.

            3. Don’t even bother using libraries. They simply won’t last for the life-time of a commercial project.
            1. 3

              Implying frontend engineers aren’t “real people” seems really unpleasant and stupid and seeing it upvoted a lot makes me less inclined to visit and recommend this website

              1. 7

                I read this in the way of “this stuff is hard because it’s genuinely hard for people in general, versus this other stuff is made hard for frontend developers because of random yak shaving reasons in JavaScript that don’t exist in Java”

                1. 3

                  It really reads more like “real engineers work on actually challenging problems involving polygons whereas dumb frontend people just mess around with stupid vdom knockoffs.”

                  1. 1

                    Well tbf, one of my pet peeves is arbitrary job titles. When did we all become engineers?

                2. 4

                  Where in the comment can you point to @friendlysock stating the frontend engineers aren’t “real people”?

                  I’m genuinely curious. I don’t read it like that at all. I read his comment as stating that a lot of the ecosystem issues around frontend development are driven by short-term fads and ideas churn. This isn’t a reflection on people as individuals, rather on the group as a whole.

                  1. 2

                    it’s probably this part

                    This is likely because making a holey concave polygon from other smaller holey concave polygons and triangulating it is Real People Hard but making another vdom knockoff is Frontend Engineer Hard.

                    though I interpreted it differently. I understood the message as both things being hard, though the vdom knockoff would get more credit from frontend developers than the computational geometry stuff.

                    edit: didn’t see @mbrock’s comment:)

                    1. 1

                      making a holey concave polygon from other smaller holey concave polygons and triangulating it is Real People Hard but making another vdom knockoff is Frontend Engineer Hard.

                      Maybe I’m misreading or just grumpy but it’s pretty common for Smart People Online to imply some kind of subhuman status for programmers who work on frontend…

                      1. 6

                        Last job I had was at least half frontend engineering, job before that 3/4. There was some genuinely tricky frontend work–98% of it though was not. I’m not some Real People engineer shitting on FE work without any idea what it’s like. Honestly, I’m unsure the work I do mostly qualifies as Real People technical work at all anymore. That said…

                        In my experience the types of problems solved and praised in frontend circles–frequently in the web in general–tend to be either:

                        • dealing with self-inflicted complications (“grunt was too old so we used gulp but I didn’t like it so we switched to we webpack but now we’re trying parcel!”)
                        • reinventing the wheel yet again (“kachow folks here’s your boy friendlysock coming at you with yet another grid system that uses the same class names as bootstrap but handles floats slightly differently”)
                        • fighting problems in the wrong part of the stack (“we have to use an SPA because our Rails backend is SO SLOW serving just normal pages”)
                        • dealing with stupid browser behavior (“that webworker messaging worked great until IE11 decided to fuck up transferable objects and just spew memory everywhere”)
                        • dealing with org dysfunction (“look I know you want it pixel for pixel to match the cut up but like you never explained the animation states of this button”)
                        • dealing with stupid business constraints (“our customers want our app to load faster but you need to pull in 15 megabytes of 3rd party analytics scripts via GTM, one of which is apparently hosted on a Raspberry Pi with a 2G connection in Antarctica”)

                        And look, I’ve made my money solving all of those problems. And it can be a thousand times more frustrating to deal with any of those things than a Real People algorithm.

                        But, like, let’s be real here: the things people go to conferences about and get Github stars on and tweet about are different orders of technical difficulty compared to what many people do in undergrad CS.

                        (And no, before you get annoyed at that, I don’t have a CS degree either.)

                        1. 2

                          I dunno, couldn’t you make such a list about backend programmers, game developers, like everyone except actual researchers and probably most of those too? “Wow, I’m a backend developer, I’ll spend two years switching back and forth between Postgres and some weird novel big data thing and fuck around with different message queues that never seem to work reliably and then rewrite all our Go micro services into Rust”, etc.

                          1. 1

                            I’ll spend two years switching back and forth between Postgres and some weird novel big data thing and fuck around with different message queues that never seem to work reliably and then rewrite all our Go micro services into Rust

                            That seems more like what a frontend-dev-tasked-with-backend-work would do, not what a real backend programmer would do.

                            1. 1

                              ugh

                            2. 1

                              I certainly could, and I believe the same about backend devs in most cases. OP specifically asked about frontend stuff.

                              (Also, game devs get a little bit of a pass from me since they deal with a much more varied problem domain–provided they aren’t just reselling Unity assets.)

                      2. 1

                        I think he meant “real software developers”.

                      1. 3

                        I’m really confused, does the author have any merit in any of these arguments?

                        He added an addendum to the post recognizing the rebuttal but it leaves me even more confused.

                        1. 9

                          Brave had intended to do a lot of stuff. There are plenty of reddit/hacker news threads with outraged users up in arms related to them. He might be correct that Brave never did some of those things, but only because the internet at large was pretty pissed.

                          Replacing ads

                          Accepting tips on users behalf and scraping profile data to misrepresent site owns as registered users

                          There’s a couple Brave people in that thread, brandnewlow and i think brendoneich adamantly defending this and trying to pass it off as a “UI problem”. IMO seems like they try to tip toe on the line of how much they can get away with.

                      1. 2

                        I believe Cowboy is what Heroku runs on if my DevTools aren’t lying to me. I’d consider that a fair endorsement.

                        1. 1

                          Hermes was written as a cowboy middleware. I’m not sure how many of those authors would make that particular decision again, given the chance.

                        1. 3
                          Main Changes
                          * new generational mode for garbage collection
                          * to-be-closed variables
                          * const variables
                          * userdata can have multiple user values
                          * new implementation for math.random
                          * warning system
                          * debug information about function arguments and returns
                          * new semantics for the integer 'for' loop
                          * optional 'init' argument to 'string.gmatch'
                          * new functions 'lua_resetthread' and 'coroutine.close'
                          * coersions string-to-number moved to the string library
                          * allocation function allowed to fail when shrinking a memory block
                          * new format '%p' in 'string.format'
                          * utf8 library accepts codepoints up to 2^31 
                          

                          Source

                          1. 1

                            Thank you for posting this :) It looks like a worthy upgrade, I wonder if the code is still able to be compiled on DOS? :O