HTTP.jl VS JET.jl

The req.url field contains the URL of the received request, the req.method field contains request method, like GET or POST, the req.body field contains the POST body of the request in binary format. HTTP request object contains much other information. All this you can find in HTTP.jl documentation. Our web application will only check the request method. If the received request is a POST request, it will parse req.body to JSON object and send the data from this object to the isSurvived function to make a prediction and return it to the client browser. For all other request types, it will just return the content of the index.html file, to display the web interface. This is how the whole source of titanic.jl web service looks:

If you want to just get the html of a website whose url you already have you can make requests from the http.jl package. https://juliaweb.github.io/HTTP.jl/stable/

HTTP.jl and Gumbo.jl for web-scraping

I haven't seen that tutorial, but I agree that HTTP.jl, Gumbo.jl, and Cascadia.jl are the way. I used them to export public wishlists from bookdepository, which has no API nor a built in exporting tool.

I find some of the library documentation hard to understand. Compare http.jl with python's requests, for example. Something as core as HTTP requests should have clear docs with tonnes of examples. Part of this is also a personal dislike of documenter.jl styling. Idk why the contrast is so low – would prefer a standard readthedocs theme.

An informative discussion on julia forum. Have you tried using https://github.com/aviatesk/JET.jl to minimize type instabilities?

For instance, https://github.com/aviatesk/JET.jl is still in its relative infancy, but it's played a big role in detecting quite a few potential bugs that had never been reported to use by users or caught in our testing infrastructure. There's also been a lot developments like interfaces to RR the time travelling debugger https://rr-project.org/ which helps us better understand and catch some very hard to debug non-deterministic bugs.

Have you seen Shuhei Tadowaki's work on JET.jl (?)

If you're curious: https://github.com/aviatesk/JET.jl

This may seem more about performance (than IDE development) but Shuhei is one of the driving contributors behind developing the capabilities to use compiler capabilities for IDE integration -- and indeed JET.jl contains the kernel of a number of these capabilities.

This is sort of being done right now, as dynamic languages have begun to adopt gradual typing... at least Python and Julia, that I know of.

If something like [JET.jl](https://github.com/aviatesk/JET.jl) become ubiquitous in Julia, one could add a function that pointed out all the places in the code where types are not fully inferred by the compiler.

It'll never be quite the same level of safety as a static language, however.

- Pattern matching (sometimes you don't want the overhead of a method lookup)

[1]: https://github.com/aviatesk/JET.jl

You can use the `@code_warntype` macro to check for type stability, which is very helpful for detecting such performance pitfalls on single function level. In the future, https://github.com/aviatesk/JET.jl may give a more powerful way to do it.