I don't think that clear at all at 20. Yes the numbers are mostly meaningless, but there is a lot of value knowing what it means to study, work hard, and care about something.
I appreciate the Go language's general sense of conservatism towards change. Even if you're not a fan of it, I think it's admirable that there is a project staking out a unique spot in the churn-vs-stability design space. There are plenty of other projects that churn as fast as they can, which also has its pros and cons, and it's great to be able to see the relative outcomes.
PS: it's kind of hilarious how the blog post is like "there are hundreds of proposals and miles of detailed analysis of these", vs the commenters here who are like "I thought about this for five minutes and I now have an idea that solve everything, let me tell you about it".
I'd happily come up with criticisms of any specific proposal and bikeshed it, but any one of these proposals would be preferable to the status quo.
I'd understand if they decided they needed more time to continue iterating on and analyzing proposals to find the right solution, but simply declaring that they'll just suspend the whole effort because they can't come to a consensus is rather infuriating.
“Simply declaring” is inaccurate description of the Go team’s decision. The team built several proposals, reviewed dozens more, and refined the process by gathering user feedback in multiple channels.
The Go team thoroughly explored the design space for seven years and did not find community consensus.
1) There isn't consensus that improved syntax for error handling is needed in the first place. If that is the case, they should just say so, instead of obfuscating by focusing on the number of proposals and the length of the process.
2) There is consensus about a need for improved error handling syntax, but after seven years of proposals they haven't been able to find community consensus about the best way to add said syntax. That would mean that improved syntax for error handling is necessary, but the Go team is understandably hesitant to push forward and lock in a potentially inferior solution. If that is the case, then would be reason to continue working on improved syntax for error handling, so as to find the best solution even if it takes a while.
I noticed math_emulate.c comes from Linux (it even has a " * (C) 1991 Linus Torvalds" bit on it). I was wondering what the license on that code is. It looks like Linux adopted GPL in 1992 so maybe this copy predates that, but it was under some other non-BSD license before that.
This kernel is (C) 1991 Linus Torvalds, but all or part of it may be
redistributed provided you do the following:
- Full source must be available (and free), if not with the
distribution then at least on asking for it.
- Copyright notices must be intact. (In fact, if you distribute
only parts of it you may have to add copyrights, as there aren't
(C)'s in all files.) Small partial excerpts may be copied
without bothering with copyrights.
- You may not distibute this for a fee, not even "handling"
costs.
This is clearly written by someone who has no business writing software licenses ;) but does not appear to be incompatible with the BSD license and in fact, the code in question originates from 386BSD (https://github.com/386bsd/386bsd/blob/2.0/usr/src/kernel/mat...) and made it from there into the NetBSD mainline.
The GPL has wrongly taught us to focus on “compatibility”. Compatibility is pretty much exclusively a copyleft issue.
There is no reason that you cannot use this code with this license in a larger BSD work. It is “compatible” in that sense.
This specific code has additional restrictions (not charging). That does not add any restrictions to the rest of the code though.
So, if you are charging, you are in violation of the license just for this code snippet. Linus Torvalds, the copyright holder, could try to enforce the license against you. Since he gives it away, no financial damages. Which means the remedy would be that you would not be able to use this code anymore (but could still use the rest of BSD).
I do not expect Linus to pursue enforcement on this one.
It would be a very difficult case to win anyway as you would have to prove that people were being charged specifically for the Linus code and not for other code covered by BSD (which allows charging).
I would argue that this license has not even been violated, unless somebody has put a price tag on this specific code.
True! And if so, that license has clearly been broken many times by everyone selling 386BSD, NetBSD and Linux <0.12 on CD-ROMs etc ;)
Then again -- and IANAL -- the license is worded so vaguely that I doubt any of it is enforcible. "You may not distibute this for a fee" -- what is "this"? Is it the entire kernel or does it apply to small excerpts of it? Because apparently "small partial excerpts may be copied without bothering with copyrights". But do you mean copyright attribution or are you rescinding your copyright entirely if I only copy "small partial excerpts"? But what is a small partial excerpt? And so on and so forth...
“this” is the code that Linus licensed as he did. Only that code. If you use a snippet, that snippet is governed by the license. The license does not magically extend to other code or even to any modifications that have been made since. This is not the GPL.
But the Linus license has no bearing on the rest of the code base at all.
The entire concept of “compatibility” is an artifact of copyleft. In the rest of the license universe, each piece of code is covered by its own license and it does not matter what licenses other code uses.
This license does not apply to the rest of BSD. The BSD license does not apply to this code.
Why not? BSD style licenses generally just impose constraints around liability and attribution; I can't see any reason why that wouldn't be compatible with a separate constraint on charging money. IANAL, though, so take with grain of salt.
I noticed on the Arabic example they lost a space after the first letter on the third to last line, can any native speakers confirm? (I only know enough Arabic to ask dumb questions like this, curious to learn more.)
Edit: it looks like they also added a vowel mark not present in the input on the line immediately after.
Edit2: here's a picture of what I'm talking about, the before/after: https://ibb.co/v6xcPMHv
I am pretty sure it added a kasrah not present in the input on the 2nd to last line. (Not saying it's not super impressive, and also that almost certainly is the right word, but I think that still means not quite "perfect"?)
Yep, and فمِنا too, this is not just OCR, it made some post-processing corrections or "enhancements".
That could be good, but it could also be trouble the 1% chance it makes a mistake in critical documents.
And here I thought after reading the headline: finally a reliable Arabic OCR. I've never in my life found a good that does the job decently especially for a scanned document. Or is there something out there I don't know about?
(personally I think Difftastic's treesitter based approach is superior to Delta, yet I always appreciate it when people link alternatives when discussing apps so thought I'd add this for completeness' sake)
I don't really follow Elm, but I was curious and tried to see whether the project is still alive. It appears the last commits on GitHub are from mid 2024 and the last installable release was 2019. It appears the main developer is working on a new thing?
There's definitely a "the bear is sticky with honey" confusion of discussion over whether it's dead or not. It would be nice for interested strangers like me if they could make some sort of clear statement on it.
> It appears the main developer is working on a new thing?
One of the problems is that the developer said several times, even in a recent interview, that he was still working on elm, with a focus on the long term. He gave a few vague hints about his private roadmap. After 4 years without any real public activity, I find it hard to believe there's some private activity.
No, its not. They are focused on introducing ELM on the backend as well. ELM isn't backed by big corpos like Rust and Go do so their way of operation will differ by a huge margin than those two langs, especially in terms of marketing so its inaccurate to judge that its dead just due to the inactivity.
Dead means different things to different people, but there is no way in hell I'd start a new project using a niche language that hasn't been updated in almost a year.
I would though. ELM has a very simple, straight forward syntax and everything revolves around the ELM architecture, which makes the whole thing very intuitive. I believe a statically typed and functional language will do just fine without any update for years as long as the initial implementation is done right. Unless there is a need to add some new feature, there is not point in updating the language if all the essentials were well implemented already. ELM compiles to JS and not to a native architecture. It'd be inappropriate to view ELM like one would view languages like C or any that uses LLVM as its backend.
It has been dead for years and years. I had an interest in learning and using Elm several years ago, but the bus factor of 1 told me it was dead on arrival.
> I was very excited for this interview but felt like Evan really didn’t say much of substance and largely avoided the interesting questions
>> It was a total pity party, dude acts like he invented bottled water
>>> Except, no, he doesn't act like that. He did invent something new, though, that is valuable to a lot of people. In spite of this he's still humble; outside of jealousy I'm not sure how you can justify saying he's acting like that. Why did you watch this video? To pick on Evan or Elm?
>>>> And to your insidious question, I reject the premise as neither of your hateful canned options for me fit the bill. You can spend your days defending people you don’t know, I will spend mine critiquing publicly what is obvious: Even thought he’d end up like Van Rossum or Dahl but he forgot the part where your creation brings something new to market—he only brought a new way of creating something that was already in the market (web applications). When will people get it through their skulls that can’t monetize anything if you’re unwilling to let others be involved in your work aside from throwing money at you. It’s completely ridiculous and naive and he’s butt hurt over this realization.
Another thread:
> For my part, the Elm ship has mostly sailed. I can't ignore the fact that the bdfl disappeared for multiple years without notice. That's not how trust is built.
>> i mean did Elm cease to be a perfectly usable language in the interim? what part of the FOSS social contract made you think he was obligated to provide notice?
>>> No one is "obligated" to do anything. I'm not obligated to put in effort to keep in contact with my friends and family, but if I don't I also can't be mad if our relationships drift apart. No, Evan isn't obligated to do anything with Elm that he doesn't want to do, but we also shouldn't be surprised if people question the suitability of a language, if the BDFL just up and disappears. A language isn't a small, one or two file, library that I can just copy paste and fix a bug, if the maintainer isn't reacting to issues or accepting pull requests. And it certainly isn't something that I want to take over the full burden of maintaining. So I need to know that I can, at the very least, work with the maintainers to fix issues as they come up. The view on open source is also extremely negative. Evan was offered a lot of chances to have other people come in and to build a strong core team for Elm. And there are many open source projects (including languages), that operate very successfully around that model and even manage to rotate people out, if they become exhausted with the project. So while I in no way condone attacking Evan directly, it's also fair to acknowledge that there are very good reasons people aren't investing into Elm for their next big project.
This sort of community is part of why I left Elm too, supporters seem to have an immediate knee jerk reaction to any sort of criticism and literally seem to treat Evan as some sort of messiah figure, unreasonable things like, "well, it never said anywhere that people have to give notice" if they're going to have radio silence for 5+ years, like, yeah, but it'd be a good faith effort if they did.
With how long it's been on the front page, how controversial it is, and the fact that it was posted earlier and that post _was_ flagged... I would be willing to bet a moderator has somehow disabled the ability for this post specifically to be actually flagged and is simply ignoring those that click the flag button.
I'm sure that seems conspiratorial but the guy writing the post effectively "cuts the checks" for the moderation staff here.
That's not the point - the point is there is a clear conflict of interest between users and moderation when it comes to unflagging a post from the forum's creator.
Even if you are somehow totally impartial (and it's hard to imagine from my point of view, due to information asymmetry and very mild cynicism) it would still be wise to "recuse yourself" - similar to the guidelines about how moderation happens less when it comes to topics directly discussing ycombinator.
This seems obvious to me. I'm not even particularly fond of the user flagging system. It's so clearly ripe for misuse by people trying to effectively censor topics they personally don't like. But if that system is in place, and another system is used to occasionally remove it- the latter system should be used with more care than has been done here. Not because you're definitely corrupt- but because the optics on it are not in your favor at all and it would be challenging if not impossible to alleviate those concerns.
It's like calling the word of Jesus heresy ... if pg essays don't belong on HN then the word "hacker" has lost all meaning. He's describing a system and how to change it. What else are we doing all day on these computers?
To my knowledge, the state of the art in tooth removal still is basically pliers and a lot of force. The difference today is a trained professional knows the technique and has practiced it a lot. (And anesthetic.)
To further expand on your comment, the alveolar bone is porous so we use pilers on the tooth to compress the alveolar bone, making a big enough hole for the whole tooth to come out in one piece.
Molars have 2-3 roots so it is a lot of efforts. In difficult case, I would divide the tooth into sections to pull each root out.
One thing is using rapamycin for bone and soft tissue regrowth. The FDA recently approved a human study after previous research showed success in mice.
It's laboratory antibody serum from a specific human-sourced monoclonal cell line.
Seems to work on all mammals (notably both nice and ferrets; I'm told their teeth system is widely different evolutionary and that humans are kinda in the middle).
A human study should be ongoing on some children in Japan that for genetic reasons are missing a few adult teeth (never grew).
> To my knowledge, the state of the art in tooth removal still is basically pliers and a lot of force
One time, my dentist told me "I can't get it out, I am going to fetch my dad to do it" when she had trouble removing a tooth. What followed was a not so fun experience in professionally applied dental violence. (Her father was also a dentist)
