Bogdanp

> And yet I'm still too stupid to understand the macro system. Oh well.

This talk[0] by Robby Findler helped me a ton when I was first learning about macros in Racket. I've found that the best way to learn, though, is by doing: when you find a use case for a macro, figure out how to do that particular thing and, slowly but surely, things will start to click.

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

Racket does tick some of those boxes:

* it has support for OS-level threads via places[0]

* it can produce binary distributions via `raco distribute`[1] by packing together the interpreter and your compiled code into a single executable

* while the current implementation is based on a bytecode-compiler and VM, I believe the Chez implementation actually compiles to native code (although the whole process is transparent to the user)

* it is possible to run Racket on ARM devices, in fact there was a recent thread[2] about that on the mailing list

I realize this isn't 100% what you're looking for, but Racket does come with many nice features. Alternatively, you might also want to take a look at CHICKEN Scheme[3].

[0]: https://docs.racket-lang.org/guide/parallelism.html#%28part....

[1]: https://docs.racket-lang.org/raco/exe-dist.html

[2]: https://groups.google.com/forum/#!topic/racket-users/YEajWJe...

[3]: https://call-cc.org/

timestamptz does store the timestamps in UTC. The difference between timestamptz and timestamp is that the former understands that time value represents a particular instant in time, whereas timestamp does not, the value of a timestamp field is essentially opaque because those values can be in any timezone and the system has no way of knowing.

    [postgres] # create table test(ts timestamp);
    CREATE TABLE
    Time: 29.807 ms

    [postgres] # insert into test values('2019-05-03 17:51:00');
    INSERT 0 1
    Time: 6.637 ms

    [postgres] # select * from test;
             ts          
    ---------------------
     2019-05-03 17:51:00
    (1 row)

    [postgres] # select ts at time zone 'utc' from test;
            timezone        
    ------------------------
     2019-05-03 20:51:00+03
    (1 row)
    
    Time: 17.506 ms

    [postgres] # select cast(ts as timestamptz)  from test;
               ts           
    ------------------------
     2019-05-03 17:51:00+03
    (1 row)
    
    Time: 0.428 ms

    [postgres] # select cast(ts as timestamptz) at time zone 'utc' from test;
          timezone       
    ---------------------
     2019-05-03 14:51:00
    (1 row)
    
    Time: 0.329 ms

    [postgres] # alter table test alter column ts type timestamptz;
    ALTER TABLE
    Time: 14.477 ms

    [postgres] # select * from test;
               ts           
    ------------------------
     2019-05-03 17:51:00+03
    (1 row)
    
    Time: 0.399 ms

    [postgres] # set timezone = 'America/Los_Angeles';
    SET
    Time: 9.281 ms
    
    [postgres] # select * from test;
               ts           
    ------------------------
     2019-05-03 07:51:00-07
    (1 row)
    
    Time: 0.364 ms

All that said, I think it's unfortunate that timestamptz stores values as UTC and I think it would be better for it to store the actual timezone for reasons others have already mentioned in this thread.

Syntax is different from semantics. To give a concrete example, say you want a part of a program to use lazy constructs. In racket, you could use `#lang lazy` for that one module and then import and use that code within `#lang racket` modules.

Despite having the same syntax, `#lang lazy` and `#lang racket` behave differently:

    #lang lazy

    (define (say-hi _)
      (displayln "Hi!"))

    (say-hi (exit 1))


    $ racket lazy-example.rkt
    Hi!
    $ echo $?
    0

versus

    #lang racket

    (define (say-hi _)
      (displayln "Hi!"))

    (say-hi (exit 1))

    $ racket racket-example.rkt
    $ echo $?
    1

Exact same syntax, different semantics.

One of these: https://www.online.net/en/server-dedicated/pro-2-m-ssd . I had it for a while and wasn't using it for much.

Yup! I'm aware. I purchased their 3 year plan for 2 accounts using my own domain names.

I never used Google Authenticator. Instead, I use 1Password's 2FA functionality.

It was easy for me because I had been using GAE as a fast/free static website host. None of the sites that I moved were dynamic.

Sorry! I should've been more clear. I'm keeping it so there's no chance of them releasing it without my knowledge down the line. Whether their policy right now is to release it or not, I feel safer by not deleting the account.

If you use Chrome, none of the steps you listed matter as far as protecting yourself from Google. I used to use Chrome until it really struck home with me what the incentives are for the world's biggest web advertising company to own the world's most popular web browser in a world where over-the-wire auto-updates are commonplace.

Out of curiosity, is there a particular reason you were trying to use Racket CS for this?

AFAIU typed Racket currently adversely affects performance on Racket CS (in certain cases) and pict3d looks like it's a non-base package written in typed Racket so it's likely not the best candidate for running on Racket CS right now.

Thanks! Looks like the first link answers my question.

I suppose I could look this up, but maybe someone here knows. Is cached JS re-parsed on every page load or is the AST (or some sort of bytecode) stored as a blob on disk for faster loads from cache?

You may want to check out Ur/Web as well.

It's unfortunate that more people don't know about pip-tools (it isn't even mentioned in the OP). It + virtualenv hits a sweet spot for speed, usability and utility for me.

Design and build for mobile first then use media queries + grid for larger screens. This means I can use grid and not care about old browsers, because they'll just get the mobile version.

Fair enough! I'd more accurately describe it as composable regexes, but to each their own.

For those wondering (like I did): it doesn't seem like this has any relation to Common Lisp's ASDF.

It takes about 2 minutes (feels like 5!) on my 2016 MBP to install 102 dependencies. Doing that in Docker takes about 1.5x the time. I haven't seen it take 20-30 minutes, but 2-3 minutes is still obscenely slow in my view.

At least on non-Linux systems, containers are far more heavyweight than something like virtualenv.

Twine seems to be the recommended[1] way. It's pretty straightforward to use, thankfully.

[1]: https://packaging.python.org/tutorials/packaging-projects/#u...

Having used pure pip + virtualenv{,wrapper}, pip-tools + virtualenv, poetry and Pipenv for medium to large applications, I'm going to be sticking to pip-tools for the time being for apps. Poetry is fine, but pip-tools is faster and there's less to learn. Pipenv is unbearably slow for large applications and often buggy.

For libraries, I've been using Poetry for molten[1] and pure setuptools for dramatiq[2] and, at least for my needs, pure setuptools seems to be the way to go.

[1]: https://github.com/Bogdanp/molten

[2]: https://github.com/Bogdanp/dramatiq

Another good one is pip-tools: https://github.com/jazzband/pip-tools (which pipenv set out to replace initially, but it does a terrible job of it IMO)

Floyd's Tortoise and Hare is pretty fun: https://en.wikipedia.org/wiki/Cycle_detection#Floyd's_Tortoi...

Probably not, because many of the differences are fundamental:

* Falcon revolves around the concept of Resources, i.e. classes as the primary handlers of requests; molten revolves around functions,

* Falcon supports Python 2.x,

* automatic dependency injection via type annotations is core to molten.

I've used Falcon extensively for about 3 years while at LeadPages.

I would say the biggest difference between the two is Molten gives you more out of the box: input validation, doc/schema generation, ORM support, support for multipart/form-data requests (Falcon doesn't actually handle these out of the box!), etc.

Yes, a lot of it boils down to the ecosystem split for me.

> 2) Explicit yield points certainly save you from most of the classic threading errors

Can you provide an example of such a threading error? At most I've heard people claim that asyncio removes the need for mutexes[1]. I think that may be true at the local level, but as soon as your function needs to synchronize with other async functions in the system that ceases to be the case. At any rate, that's not enough of a win to justify the split in my opinion.

> having to use special maps and datastructures everywhere.

The GIL already protects you from corrupting builtin datastructures. Neither the GIL nor asyncio protect you from corrupting your data (the need for some form of synchronization), however.

> 4) Supposedly this refers to the `open` function? This can be solved using the `aiofiles` module, but again I suppose this ties into (1).

And most operations on opened files (like `read()`) as well as any OS bindings provided by the `os` module.

[1]: Clearly, asyncio itself still thinks they're useful: https://docs.python.org/3/library/asyncio-sync.html#asyncio....

I'm not familiar with Connexion (this was my first time hearing about it), but it seems, from reading its README, that the two approaches are polar opposites: in Connexion you write the schema first and that is used to hook up your API to your business logic, whereas in molten you write your API using normal Python code and idioms and an OpenAPI schema is generated from that code. As a user of Molten, you don't need to know anything about OpenAPI to be able to use it.

Here are my reasons:

* I am not a fan of asyncio's API (`ensure_future`), docs (though I understand these two are improving in 3.8) and of the fact that it is incompatible[1] with much of the existing ecosystem of libraries (eg. the SQLAlchemy ORM or any existing libraries that talk to... anything over the network (postgres, redis, memcached, etc.) which need to be written from the ground up in asyncio style or rewritten so their protocol parsing logic is completely separate from the IO that they do (not a bad thing, mind you, but taking battle-tested libraries and rewriting them from the ground up is not the greatest idea)), tools and even builtins (queue.Queue vs asyncio.Queue).

* I don't buy into the claimed benefits of explicitly marking yield points: any sufficiently complex code will have enough yield points (`async with`, `async for`, `await`) that reasoning about concurrency in the program isn't going to be any easier than if it had implicit yield points.

* I think ergonomics matter for developer happiness and programming with asyncio is not ergonomic in the slightest.

* File IO is blocking.

Put all of those together and you end up with a system where you can't use any of the popular, battle-tested, libraries out there, where your code is more verbose for minimal gain and where seemingly benign things (reading a file, using a `for` instead of an `async for`) may greatly impact the performance of your program all for a small increase in throughput (assuming it does increase!).

[1]: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

There are some benchmarks[1] in the molten repo as well as instructions for running them yourself. On my machine it ends up being faster than Flask and nearly as fast as Falcon.

[1]: https://github.com/Bogdanp/molten/tree/master/benchmarks