151–160 of 193 posts
Shameless plug: This kind of posts was the reason I wrote about it recently too [1]
1 - https://world.hey.com/joaoqalves/i-could-build-this-during-t...
Let's be honest here. Curl to 98% of people is http/1 requests with some post params and maybe json body, with some custom headers. Most language standard libs (which might be using libcurl) can facilitate writing that relatively quickly. And probably with a more 'modern' CLI. Curl though, is a very wide breadth project. It currently supports the following protocols: DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP,…
I fall firmly into "those 98%" you mention.
Dlang's stdlib (only) implementation for making network requests is quite literally a direct "curl" wrapper:
https://dlang.org/phobos/std_net_curl.html
You've changed on my mind on this being an odd design decision.
Baking in libcurl for the user (or optionally allowing them to dynamically link) if they want networking was maybe the most sane/pragmatic choice you could have made for a new language.
Earlier quoted context omitted.
A question that arises out of this is, should the 90% use cases be handled by a small, simple tool, or by the tip of the iceberg of a large, complex tool such as curl? I can see the advantages of standardizing on a complex, powerful tool for simple use cases. For one thing, it may be the only way to standardize: simple versions are too easy to write, and therefore you get dozens of competitors, none of whom are popul…
Sometimes yes, sometimes no. Counter-example: Jenkins. It does what you ask of it, its base install is "naked" and only contains the minimum functionality in the core. Everything then becomes a plugin. Git. GitHub. Branch for multi-branch pipelines. Credentials management. And on and on and on. Now you have stay on top of maintaining the plugins in addition to the core. Also, many plugins require other plugins so jus…
For example, VSCode plugins are great because VSCode is thriving, and Emacs packages are a crapshoot because many of the programmers who wrote them have moved on. Eventually VSCode plugins will be like Emacs packages.
Earlier quoted context omitted.
Plenty of applications use TCP and UDP, or even custom protocols on top of raw IP. Not everything needs to come through the browser.
Micro-services, for example, are pretty much all HTTP + JSON. The only place for HTTP is the browser and purely for historical reasons. Using it for anything server-server is a waste of network and CPU.
Earlier quoted context omitted.
True. I'm kind of surprised (again) by Daniel after 20 years of maintaining curl being so salty about "people not appreciating the achievement". Yes, for overwhelming majority of users curl in 2021 is just a simple http/https request client. And, yes, in 2021 that could be written over a weekend with a better CLI, mainly because most of the languages already have all important stuff implemented in a [standard] librar…
That was honestly my first thought. Of course it's easy to rewrite curl nowadays. It can't be anything more complicated than slapping a command line interface on top of libcurl...
I can write cURL in 1 line of bash: alias mycurl='curl' /s
most people underestimate huge effort under simple to use products but integrated to our lives heavily. * redis - I can do it, listen socket, serve from hashmap * uber - how come this app is so huge, I can make it in 2 weekends (google map + api + database) * cURL - easy, use my fancy library (it already implements HTTP stack) and rewrite it ....
Let's be honest here. Curl to 98% of people is http/1 requests with some post params and maybe json body, with some custom headers. Most language standard libs (which might be using libcurl) can facilitate writing that relatively quickly. And probably with a more 'modern' CLI. Curl though, is a very wide breadth project. It currently supports the following protocols: DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP,…
I'm one of the 98%, and I don't like using cURL for this reason -- the CLI feels clunky and its gigantic number of options are distracting for my simple use case. Can anyone recommend a good alternative for the base case?
That said, I still will reach for cURL even when simpler options exist because it's ubiquitous. Same thing with Bash, grep, and sed.
Earlier quoted context omitted.
More and more APIs use HTTP as the transport for various reasons, but one of them is that HTTP has considered large number of edge cases and has been tested "in the fire" - rolling your own custom API with security and encryption is much more fraught with dangers.
Except HTTP 2.0/3.0 has very little to do with HTTP 1.0, and is more akin to use TCP/UDP directly anyway. It just happens to get a free pass over port 80.
Earlier quoted context omitted.
Today I would probably reach for an RRB tree and define some kind of simple heuristic for transients, giving me free undo/redo, and reasonably simple support for multiple cursors. Back then a gap buffer seems like a great idea. Two linked lists is a simple enough idea.
Kudos to you for supporting multiple cursors from the start, which a buffer with a gap can't support efficiently. Douglas Englebart would have approved! https://en.wikipedia.org/wiki/Collaborative_real-time_editor >History of key products: The first instance of a collaborative real-time editor was demonstrated by Douglas Engelbart in 1968, in The Mother of All Demos. Widely available implementations of the concept to…
Arguably the only "single user" devices should be things like the mouse itself, as multiple people can see the same screen (and maybe even use the same keyboard).
Some games implemented this to allow two-player on the same machine - each would get a joystick or "their half" of the keyboard.
Earlier quoted context omitted.
All those people don't realise tools like curl did start with few lines back then. And after the first two minutes of testing the devs started adding additional code to handle failures, invalid inputs, different platforms, different versions of a standard etc. One can write a lot of things in 100 lines if it doesn't have to meet higher standards than a basic chat app tutorial in the "getting started" section of a pro…
> One can write a lot of things in 100 lines if it doesn't have to meet higher standards than a basic chat app tutorial in the "getting started" section of a programming language. I'd argue that even a basic chat app is massively complex, only that all the really complex parts have already been solved. I once tried to write one on the LOWEST level I could. Realized after a month that there were not enough hours left…