HN user
ainar-g
Have you ever learned a language? Because that's what it is for a very large percentage of people.
Which is why the Soviet government used “ultraviolet baths” to make sure that children up North got their vitamin D.
https://www.nationalgeographic.com/photo-of-the-day/photo/ul...
There's always ReactOS[1], a project for a bug-for-bug compatible Windows clone. It used to mostly aim at Windows 9x compatibility the last time I'd checked, though, but that could probably change. And if anyone wants to create a Win7 clone, at least some of the groundwork has already been made.
Thank you, rsc, for all your work. Development in Go has become much more enjoyable in these 12 years: race detector, standardized error wrapping, modules, generics, toolchain updates, and so on. And while there are still things to be desired (sum types, better enum/range types, immutability, and non-nilness in my personal wishlist), Go is still the most enjoyable ecosystem I've ever developed in.
Source on the reasons, from the editor: https://pony.social/@thephd/112791335889843647.
If I recall correctly, ProtoBuf has a reflection layer, and it's probably using that.
Re. bad tooling. grpcurl[1] is irreplaceable when working with gRPC APIs. It allows you to make requests even if you don't have the .proto around.
While the compiled programs stayed the same, we no longer get a warning (even with -Wall), even though both compilers can easily work out statically (e.g. via constant folding) that a division by zero occurs [4].
Are there any reasons why that is so? Do compilers not reuse the information they gather during compilation for diagnostics? Or is it a deliberate decision?
Ah, so extremely localized uses of pointers, got it, thanks.
That could be true, but I've done a few optimizations of allocations in Go code, and I don't recall pointers to stack values ever being optimized (unless the entire branch is removed, of course). If anyone could provide an example of the code that does pointer operations yet doesn't cause allocations, I'd appreciate it!
Whenever you do:
v := interfaceType(concreteTypeValue)
in Go, what you're actually doing on a lower level is: dataPtr := &concreteTypeValue
typePtr := typeData[concreteType]()
v := interfaceData{
data: dataPtr,
typ: typePtr,
}
The first line here is the allocation, since (at least, the way I recall the rule) in Go pointers never point to values on the stack, so concreteTypeValue must be allocated on the heap. The rule about pointers not pointing to the stack is there to make it easier for goroutine stacks to grow dynamically.There is a proposal to get this using the "defer" keyword into either the next C revision or the one after that[1].
[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3199.htm.
Privilege separation[1], most likely. If your system needs to do three things, it could either just do all of them using a single executable requiring all three permissions (thus also theoretically allowing an attacker to use it to do all three things as well) or split your system into three executables, each only having the permission to do one thing (thus reducing the amount of potential damage).
This makes me thing of the stories I've heard stories from those who lived in communal apartments back in the U.S.S.R. days. Couples who had a creaking bed and wanted to go at it at night would just do it on the floor instead of on the bed. Which in turn makes me think if those beds are just some kind of kickback scheme, because I can't be the only one who thinks of suck obvious solution, can I?
Edit: Seems to be fake news: https://www.snopes.com/fact-check/anti-sex-beds-2020-olympic....
Why the quotation marks? If I recall correctly, Vala compiles (by way of C) into native code.
IPv6, too. (Unless you also need interface IDs for link-local addresses.)
On a related note, have there ever been extensions for PosgreSQL/SQLite/any other FOSS DBMS that would allow using Tutorial D[1] (the Third-Manifesto one, not to be confused with Walter Bright's D language) to define and query data? In particular, I feel like PostgreSQL's CREATE TYPE[2] feature would allow for easier bridging between SQL and Tutorial D.
Unfortunately, searches for “PostgreSQL Tutorial D” don't issue useful results for obvious reasons.
[1] https://www.dcs.warwick.ac.uk/~hugh/TTM/index.html
[2] https://www.postgresql.org/docs/current/sql-createtype.html
A feature that combines well with range and enum types are typed indexes of arrays:
TYPE
TWeekday = (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday,
Sunday);
VAR
WeekdayNameIndex : ARRAY [TWeekday] OF ShortString = ('Mon', 'Tue',
'Wed', 'Thu', 'Fri', 'Sat', 'Sun');
Now `WeekdayNameIndex` is a properly type- and range-checked look-up table.It's really sad that these simple joys of Pascal are still lacking from a lot of mainstream languages.
Re. the shape of the code, it's probably a matter of habit, as I have the complete opposite experience reading code in languages with exceptions. That is, I find that there is too much happening within a few lines, wondering which line can explode and in which ways, heh.
Funny you mention Go, because it's my main language these days. And I have to be honest, I don't have the issues you're mentioning. 99 % of loops in the code I review is the plain for-range type, and whenever it's something more complex, I usually am/recommending splitting away the body. Also helps with complexity metrics (and having at least a maximum cyclomatic complexity checker for your code is a must, imo). And if your error handling is repetitive, there is a high chance you're not adding the important context to errors and/or not checking if the context is added in the reviewed code.
A thing I've discovered that helps me a lot that don't see mentioned at all is to always review code by checking it out on your machine and using your editor to inspect it. Maybe it's just me, but there is something about seeing the code in your own environment as well as having all of your tools to e.g. see where a method is used helps massively.
I think one of the reasons might have something to do with the fact that with more experience—and thus, often, a higher position—comes the responsibility of reading more code. Often, you come to a point where you are reading more code than you are writing, i.e. when conducting code reviews or investigating an issue. And while the code in more complex languages can still obviously be readable, simple languages force the code to be at least somewhat readable even at its worst.
It does have optional support for JS thru Duktape[1] Engine, if I recall correctly, but that engine doesn't support a lot of modern JS stuff, mostly being limited to ECMAScript 5.
I've looked up some JSSS code examples, and it seems like it's pretty much the only type of code where the "with" keyword makes sense:
<style type="text/javascript">
tags.H1.color = "red";
tags.p.fontSize = "20pt";
with (tags.H3) {
color = "green";
}
with (tags.H2) {
color = "red";
fontSize = "16pt";
marginTop = "4cm";
}
</style>I was hoping that Canonical has higher standards when it comes to server software, as opposed to something like Snapcraft, but reading this makes me think that maybe they both were developed by the same team.
At least the people who named it understood the silliness of the issue, heh.
Ah, understandable.
Depending on whether or not the resulting YAML is supposed to be human-readable[1], you can just produce JSON output, since YAML 1.2 is a superset of JSON. I did that at one of the places I worked in at the time, and it worked very well.
[1]: I personally think that JSON is plenty readable, but a lot of people seem to disagree.
What are you using yq for? Unless you use YAML-only features (e.g. integers, arrays, and objects as object keys), it seems like it would be easier to just pipe-convert your YAML to JSON and process it with jq.