HN user
Some Rust libraries have started to implement unioning multiple error types and handling a subset of them while propagating the rest. But as far as I know, the idea hasn't caught on. Here are the crates I know of.
Is it time for the literate programming renaissance?
Have you tried Clojure?
Somebody save Kathy Sierra’s blog! https://headrush.typepad.com/ I’ll try to archive it. I love her work. But even if I save it, it should live on somewhere else.
Have you seen Scrappy? It’s still early, but it’s the most interesting thing I’ve seen in a while.
Pinboard was a clone with a different business model: users actually paid for it.
Fast forward, and delicious died, only to be acquired by — you guessed it — Pinboard [1]. Because Pinboard was actually serving its paying customers, it just kept trucking along.
[1] https://blog.pinboard.in/2017/06/pinboard_acquires_delicious...
Yes, I did this at my startup. Fast forward a few years, and now the company has more Rust code than Python, and the majority of the company's IP is in Rust.
I suggest beginning with small, one-off things that don't have much impact. People, even developers, tend to shy away from things that aren't familiar. By introducing Rust in a small, low-risk way, it helps people get familiar with it. They get to build familiarity with building Rust projects, navigating the project structure, and reading docs. I submit pull requests that get people to read Rust code, even if it's just to say "looks good". Their familiarity builds slowly over time, meaning they'll be less triggered by seeing Rust in a larger, more impactful project down the road.
How do you boil a software developer? Slowly.
If they give Rust a chance and your team has a champion to guide them, they'll see its merits. I think a lot of people come to Rust for the performance, but that's not why they stay.
Yeah, this is just baffling. A team can be so averse to learning new tools, good ones too, that they would rather dump their time into rewriting. Instead of getting paid to level up their skills, they'd rather block forward movement of the company's goals to maintain the status quo.
How long ago was that?
Better resources, like what? Please share links.
The same author has a post from 2022 [1].
Is it possible to achieve arbitrary code execution on any Go version, even with PIE, and with no package import at all, just builtins? Yes!
Whether it's capture the flag is irrelevant, IMO, because anything that's allowed by the compiler will emerge given enough complexity.
1: https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...
It's unfortunate that there's no mention that not all these languages are equally safe.
Go isn't memory safe when using goroutines. See: Golang data races to break memory safety: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
Hollow Knight
Don't forget all the variations on how to use the format() method.
# In order
'Hello, {}!'.format(who)
# Numbered
'Hello, {0}!'.format(who)
# Named
'Hello, {name}!'.format(name = who)Ruby not having first-class functions
This is simply false. Ruby has first-class functions.
Not only that, it has blocks, which few other languages have. Ruby optimizes for the common use-case of a method that takes a single callback/piece of code, and I miss it in most other languages, including Python.
In Python, the "with" statement is super special. But in Ruby, it's just a method that takes a block. And any method can take a block, not just one per class.
https://yehudakatz.com/2010/02/07/the-building-blocks-of-rub...
I currently work for a company where one of my co-workers is a maintainer of the official Gitea repo.
There was no mention of this anywhere prior to the blog post, including in private Discord channels. It has _not_ been public knowledge for a while.
What you said is false. I suspect that is why you're getting downvoted.
Git isn't designed for "noobs trying to pick up coding just to experiment". It also isn't really designed for solo developers as the OP is about.
Git is designed for collaboration. Git's UI is absolutely unintuitive, especially coming from other version control software. But that's irrelevant. Everyone wants to use it because of the network effect.
In terms of _why_ the UI is unintuitive, I believe it's because it intentionally exposes its internal representation. Unlike its predecessors like subversion, Git has infinite flexibility in terms of the workflow that teams of people can adopt. But the flexibility comes at the cost of learning how to use a distributed graph of commits.
Personally, I never learned git by reading recipes of commands, like the OP. I only really grokked it by understanding how it works internally. This article helped me:
Git for Computer Scientists https://eagain.net/articles/git-for-computer-scientists/
I know you're asking about Computerphile, but this video explains how one of the Numberphile videos is wrong: https://www.youtube.com/watch?v=YuIIjLr6vUA
When I was new to Ruby and hadn't learned the available tools yet, I had similar problems because I brought practices from other languages that didn't work.
Typically, what you're describing is solved, in different ways depending on your setup. I literally never think about the issue you're describing when using Ruby.
- With Rails/ActiveSupport in development mode: Module B is autoloaded lazily when C refers to it.
- With Rails/ActiveSupport in production mode: All modules are eagerly loaded at startup.
- Plain Ruby: There's a few ways, but most gems simply have a file at the top level that eagerly requires all files when the gem is required. Same with an app.
If startup time becomes an issue, you can configure the autoloading at the top level, and the appropriate file will be required lazily when it's referred to. But at that point, just use ActiveSupport.
This is simply false. Ruby modules are first class. They're objects that you can pass around like any other object. You can put them in a local variable. You can define methods on them. You can do metaprogramming using them. You can build classes by mixing modules together. You can create modules (and classes) at runtime. Many things that need to be built-in in other languages are just a library in Ruby.
Files and modules in Ruby are two distinct things. While Python makes files one-to-one with modules, Ruby allows you to define as many modules as you like in a file, zero or more.
It's true that if you define a constant at the top-level of a file, it uses the global namespace.
By convention, if you have a file named `foo.rb`, you'd write:
module Foo
# Code here
end
The only thing I disliked more than moving from Ruby to Python was moving to Go. All the things I love about Ruby are the antithesis of Go.
IMO, Ruby optimizes for reading. You simply cannot write concise code in Python as in Ruby. One reason (of many) is because of all the import statements required in Python. In Ruby, there is often only a single require statement, or maybe none at all, at the top of a file.
The difference is convention over configuration. In Ruby, if you know the convention, then you know exactly where everything is defined without needing to read it. In Python, you must read all those import statements to know where something is coming from, not to mention write them in the first place.
And if you really need to know where something is defined, you simply ask it.
puts obj.method(:foo).source_location
Did you try asking users to pay? I.e. tell your users, you're shutting down unless everyone starts paying. It could be Kickstarter style in that X number of users have to put in their payment information by some date, or you still shut down. That way, there's no chance that some people start paying, but you still shut down.
And before someone criticizes Ruby for being inconsistent in how the method is called, Ruby isn't a callable oriented language [1]. The common case is calling methods, so the fact that you need to say `.call(5)` both makes it more consistent and makes real code more concise, especially when making DSLs where chaining is really useful.
1: https://yehudakatz.com/2010/02/21/ruby-is-not-a-callable-ori...
I second both of these. Even though they write a lot about tech, you can replace the specific technologies with the modern day equivalent and it's still relevant. For a lot of the topics, I haven't come across anything else that better articulates it.
The next level is getting into the mind of Kathy Sierra. The idea that helping people become passionate -- or badass, as she later rewords -- is an end in itself. This isn't just about tech.
I started using the DuckDuckGo app on iOS to do exactly this. You can choose to "fireproof" any site you're on, adding it to a list of sites that's immune to clearing all data.
I don't think it has a history feature at all though.
This tells me that you've never used a well-managed language or framework. Those aren't the only two options.
Ruby 1.9 was released around the same time as Python 3, with a similar amount of large breaking changes, and no one was holding on to Ruby 1.8 the way the Python community held on to Python 2.7. You could keep using it if you wanted to, but no one did. Ember.js is another example that I've used that was refreshingly well-managed, with a clear (oftentimes automated) upgrade path between minor releases. Using semver and LTS versions, it didn't just break backward compatibility without a significant deprecation period. Those are just a few examples off the top of my head, but I'm sure other good examples exist.
When things are well-managed, you as a developer have the freedom to upgrade when it's a good time for you. When you have production software with real users or a business that depends on it, you can't always just drop whatever you're doing to upgrade, which is why backward compatibility is needed.
If it's done right, there's a self-imposed drive to want to move to the latest with all its improvements. On the other hand, with Python 3, they took away things that people cared about, leaving developers not only with no drive to upgrade, but an irrational impetus to hold on to what they had, even when the situation was fixed at a technical level.
Is there a 2021 update to this topic? How has the state of WASM changed? How have JS engines changed? Is it still a good idea to make these changes to your JS code?
Can you elaborate on why you think they “botched” the standardization? I don’t know much about the topic, and I’m genuinely curious about what went right and wrong.
Yes. It contributes to RSI. It's best to use thumbs for frequently used key modifiers.