every file format it uses has been created from scratch in order to handcraft the content authoring experience.
Feels like a noble intention, but creating new formats because the existing ones are not good enough just ends up with more standards (https://xkcd.com/927/). I must say they have some neat ideas, though.
Getting hooked on computers is easy—almost anybody can make a program work, just as almost anybody can nail two pieces of wood together in a few tries. The trouble is that the market for two pieces of wood nailed together—inexpertly—is fairly small outside of the "proud grandfather" segment, and getting from there to a decent set of chairs or fitted cupboards takes talent, practice, and education.
This is a great analogy
the 31,085 lines of configure for libtool still check if <sys/stat.h> and <stdlib.h> exist, even though the Unixen, which lacked them, had neither sufficient memory to execute libtool nor disks big enough for its 16-MB source code.
yummy
the Peter Principle, the idea that in an organization where promotion is based on achievement, success, and merit, that organization's members will eventually be promoted beyond their level of ability
Applying the principle to software, you will find that you need three different versions of the make program, a macroprocessor, an assembler, and many other interesting packages. At the bottom of the food chain, so to speak, is libtool, which tries to hide the fact that there is no standardized way to build a shared library in Unix. Instead of standardizing how to do that across all Unixen the Peter Principle was applied and made it libtool's job instead.
graphics/libtiff is one of the 122 packages on the road to www/firefox, yet the resulting Firefox browser does not render TIFF images. For reasons I have not tried to uncover, 10 of the 122 packages need Perl and seven need Python; one of them, devel/glib20, needs both languages for reasons I cannot even imagine.
Dependency hell
I also don’t think we’ll be seeing any serious production services running on Deno or Crystal any time soon.
Can't speak for Deno, but Crystal has been used in "serious production services" for many years. Some examples: https://lavinmq.com/, https://kagi.com, https://brightsec.com, https://www.placeos.com/ More on https://crystal-lang.org/used_in_prod/
if count > 1 if count < 4 && c != '{' count.times { into << c } else into << '{' << c << count << '}' end elsif c == '{' into << "{{1}" else into << c end end
This can be shortened to:
cr
if count > 4 || c == '{'
into << '{' << c << count << '}'
else
count.times { into << c }
end
Where classic TCP relies on packet losses to detect congestion, L4S Prague uses a bit in the IP header as an explicit congestion signal. That bit is called Explicit Congestion Notification (ECN). Using ECN makes it possible to signal congestion early and often. A congestion signal can be sent before the queue begins to fill and without paying the costs of dropping packets. This is one of the major strengths of L4S. Early and frequent signals allow the sender to react less dramatically to congestion signals, so the transmission rate can be fine-tuned quicker and more accurately.
Good intro on L4S
"But if you look at the people, the people are so much like us today. We really should be having peace together."
Nice ending in the spirit of Christmas =)
a lightning-fast compiler
That sounds suspiciously like they didn't run the compiler...
since Ruby code can work for Crystal with just slight changes, I was able to use the best code writing practice in the world: Copy and Paste!
This works and it's great to get up and running again. But note that you might be importing practices from Ruby that are subpar in Crystal. For example, turning the regex results into an array is unnecessary and inefficient. And it requires some extra steps in the code to handle this transformation.
not user-friendly.
What are the pain points that limit user-friendliness? Like Ruby, developer happiness is a prime objective in Crystals. If it cannot deliver on that, I'd like to know why and what we can do better.
The thing is, you’ll have to think about the types you pass and receive while also making sure your code is readable and simple.
In my experience, types are rarely getting in the way. If they are, you might be using them wrong. It needs a bit of a different mindset than dynamically typed languages.
The big benefit that you get with static typing is catching many errors before the code even runs. And type annotations can in fact help readability. They implicitly document the APIs.
for writing a cross-platform tool, Crystal is probably not the perfect choice.
Could you elaborate on the reasons for that? It would be great to better understand the limitations you have experienced.
On macOS, this is not supported at all
Fully-statically linked binaries are unuspported on MacOS. But that's an issue of MacOS' system lib which is not available as a statically linked library. Statical linking should be possible for any other library. So you can still produce binaries that have no runtime dependencies except for the system lib, which should be practically irrelevant because it's always available and has a pretty stable ABI.
This is the price we pay for all the benefits static types give us
The price is actually quite low. The only place where you really need type annotations is for instance variables. Everywhere else they're optional. Yet I still recommend types a lot for documentation purposes.
Phew, describing variants of Hash value types can be annoying, especially when value types are different.
The problem is applying a Rubyism (nested hash structures) to Crystal where it doesn't fit. If the structure of a JSON format is unknown, JSON::Any is great tool for that.
If it is known (which seems to be the case here), you'll get much better results with modeling the data structures into Crystal classes with the help of JSON::Serializable.
To me, Ruby with explicit, static typing would be like a salad with a scoop of ice cream. They just don't go together.
That would be: Crystal. And it goes well together I think =)
When I’m in my_app, I can’t do crystal build/run to build or run my project, but I can do shards build/run. But typing crystal docs builds my project documentation, while shards docs does not. Also shards spec does not run my test code, but crystal spec does. In my opinion, when working with an app you created you should be able to manage it entirely with shards build/spec/docs/run all from the root my_app/ directory and it should just work™.
duality between shards/crystal should be straightened. But: shards is not a task runner.
and GitHub/GitLab to store its code
shards supports any git repository, not just ones hosted on GitHub or GitLab. And also mercurial and fossil repositories.