I'm far from wizard on the topic, but from my experience it's not that simple since the relative magnitudes of the operands and the operator affect the size of the error in non obvious ways.
I spent 13 years maintaining a 2mloc reservation and accounting system that used floats for everything. By the time I got there and understood enough it was simply too late to do anything about it.
Just say no, really; that road leads to madness.
If you need precision; and many do; consider fixnums, rationals or bignums, in order of increasing complexity and flexibility.
If I remember correctly at least Alan Kay openly admits being very inspired by Lisp. Unfortunately the limitations/walled gardens they chose to impose in the name of simplification, everything is an object etc, had us running in circles for a long long time. My guess is it was picked up by managements for the same reasons as Cobol, Java, Go etc.
Do you know what the best predictor of future behavior is?
They're acting all nice and friendly right now, wasn't always like that and there's no reason to assume it always will be. Even the catholic church is pretty chill these days, but give them enough power and they'll have people burning at stakes in no time.
If you became supreme leader of your country, you'll get power drunk in no time. And it's not just you. It's everyone. Power corrupts people. Absolute power corrupts absolutely!
Remember how developers shunned Windows Phone and paid lip service to firefox os, and everything else apart from IOS and android?
Well, you can see how the power is surely corrupting Google. If you don't see it now, give it time. But it's even too late right now.
No amount of bitching will make Microsoft, Apple, Google, Amazon, Facebook and other "big bullies" play nice. What will? Strong, credible competitive threats.
You think Intel processors are expensive? Without AMD Intel processors would cost 4x as much. How much battery life would Intel PCs have without ARM? In fact, I assure you that without AMD, ARM would also be dead because Intel would have simply forbidden their partners from using ARM - the same way Google discourages top android manufacturers from using android forks.
About ur catholic reference - there's only one reason why Catholic churches are "pretty chill these days." And that's competition. New protestant churches are sprouting like grasses everywhere - competition has diluted the power of the church.
Competition is the key to niceness. Just look at the behavior of US ISPs.
The reason it's not all about power/competition is that corruption is very easy to get into your system; be that individual, corporate or otherwise; and tricky as hell to weed out. Once you've been there and done that, the bar is set lower for relapse.
I've been practicing Ving Tsun for around 25 years. Many aren't aware, but the most of the system is based on blades. The issue I've been having is finding good enough knives to train with. Most of the stuff out there is ornamental crap that will teach you the wrong thing best case and break and hurt someone if you're unlucky. I ended up getting two big, well balanced hunting knives that I've blunted for training.
I'm pretty sure I'll end up making my own sooner or later...
Go's resistance to exceptions looks like Steve Jobs and his one button mouse from here. It's not like renaming them to panic/recover fooled anyone outside of the Pike reality distortion field. Sometimes unwinding the stack is exactly what you want. Optional types are nice too, but that's more for things that are intentionally missing. I have yet to see anything here that's an improvement over just doing the obvious thing.
I'm not sure about that. Rust's use of a Result type instead of exceptions is one of my favourite things about Rust. Before I'd used it, I'd not realised how many reliability issues in other languages were caused by overlooked exception cases.
Exceptions are great when you don't want to handle errors properly, but when you do want robust error handling I find the "return a value" pattern much better. Notably even C++ is looking into implementing this!
> I'm not sure about that. Rust's use of a Result type instead of exceptions is one of my favourite things about Rust.
It works because Rust has pattern matching and generics as well. Just having a Result type isn't going to help with error handling much, and Go is not getting generics Rust style nor pattern matching any time soon.
Let us be reminded that Go errors as values are purely a convention, nothing in the language mandates their use. On the other hand panic/defer/recover are language constructs.
Option types demand pattern matching and similar techniques for working with those types. Otherwise you just have "if (x.isDefined) a else b" blocks of code everywhere.
They are not overlooked, they are better handled further up the call stack. And not having the option to forward them implicitly is a step back, not forward. There's no way to make a programming language better by forcing users to do anything, in many cases the user will have more experience than the person implementing the language. A programming language is a tool, predicting and dictating how the tool is to be used is missing the point.
I don't think forcing is the right word.. I've noticed that languages where the "right way" is the path of least resistance the code quality stays high even if a lot of people with varying levels of expertise contribute
> There's no way to make a programming language better by forcing users to do anything
Sure there is, many important language features boil down to forcing users to do the right thing (not necessarily the easy thing).
In highly concurrent languages like Go, there’s not always a meaningful stack to unwind, and you end up having to pass error values around anyway. So I can easily sympathize with the decision to stick with one mechanism for error handling.
And fixing the output of that is where the rest of us often profit from.
A language that provides a lot of freedom when it comes to expressiveness without offering much in the way of constraints (to truly convey the purpose of a given piece of code with the least amount of ambiguity possible) will almost definitely turn into utter crap in contact with junior developers, and will often be a source of pain for more experienced ones once the project is nontrivial, whether they realize it or not.
Do you see any problems with optimizing everything we do for junior developers? I mean, most of us aren't, and it would be really nice if someone gave a crap about wasting our lives as well.
It's not necessary optimizing for junior developers. When properly implemented, language hand-holding is a tool for "better" programmers as well. I find that my brain capacity is limited, and the more I can focus it on issues that are productive rather than eg. tracking the liveness status of my data or potential system-wide effects messing with it, the more useful work I can perform.
Not to mention working together with more junior people, in which case it will be you doing the hand-holding instead, because the tools don't
I don't think that Go will move to exceptions. Sure, panic/recover are renamed exceptions (very similar to Rust panics, btw), but standard library and community libraries uses errors, so you'll use them anyway (unless you want to rewrite or wrap the world which is possible, I guess, in automated way and that's a provoking thought!).
Exceptions are like cancer. You never know when you're going to get one, you have no idea how to handle them or if you should handle them, and they produce fatal bugs at unexpected places.
I didn't say that, I said that exceptions are used for exceptional problems. Expected errors like missing values are better handled using optional types. I find the one ring to rule them all attitude less than constructive.
I'll annonance my bias towards go. But from what I understand, allowing exceptions allow for more complex code parhs. Whereas explicit error handling forces you to handle it in the moment.
Problem is you're not handling errors, you're wasting precious energy shuffling errors to code that knows how to handle it; which is exactly what exceptions could do for you. The end result is the same, except it takes more effort and the code looks like crap.
Exceptions are really no less complex than return values, and they do not (easily) play nice with asynchronous and lambda/functional programming models. Witness their near abandonment in JavaScript for example.
I like Go mostly the way it is. Its simplicity is genius. Anything added should be considered with great care.
One of my teachers at university kept repeating that you can't really call yourself a programmer before you've implemented at least one language. I don't know about that, everyone is entitled to an opinion.
What I do know is that it's one of precious few things in software that I still find interesting enough to bother [0]. I'm guessing part of the answer is that this is where you end up sooner or later.
And then we have the internet, which is a big part of the equation. It's easy to get numb, but I remember a time when information about implementing interpreters/compilers was VERY hard to come by.
It's all good from my perspective, we're barely scratching the surface of what is possible and there are plenty of good ideas left to rediscover in our history.
But I do wish that more designers would dare to step outside of the box more. Creating a language isn't about cherry picking features from existing languages, it's about finding better ways of solving problems.
As others noted, proving medical benefits has been illegal for a long time. What we do have is the authentic personal experience and testimony to its benefits from hundreds of thousands of users. I know, drug users are not to be trusted; unless it's alcohol or tobacco, then it's ok. But still; you rarely hear users preach the health benefits of crack cocaine, or even alcohol/tobacco.
It does wonders for chronic pain, without the nasty side effects of opiates.
It makes it easier to deal with ADHD/Aspberger traits, without the nasty side effects of amphetamine.
And it seems to have extraordinary cancer curing powers, without long term killing you like chemo.
I am aware of the legal issues related to the matter as well as the many claims of medical relief if provides. I don't doubt that some will be found... I just think that if people are going to run around touting its medical qualities, there should be some kind of non anecdotal proof of these claims by now. I've heard some pretty outrageous claims about THC and CBD, but a few years ago I was hearing some of those same claims about Acai, and a string of others before that, none of which panned out. I just think throwing around all these unsubstantiated claims could be doing more harm then good in the eyes of the opposition to the matter.
Being very pro-cannabis both recreationally and medically, I am very much looking forward to such research so we can put the argument about the plant to rest for a while.
I'd also prefer a C version, but I think it's possible to call a Go function from C [0]. I don't know how well that would work though, since Go requires a runtime.
There is also a Rust implementation of libp2p[0]. Exposing C functions from that library is probably the most "proper" way currently feasible to use libp2p from C.
Works short term but wrecks your immune system long term, which means you will get sick from something else and no one can be blamed. Have you actually seen someone on chemo? Scientifically sound is not the first thing that comes into my mind. There's even a decent amount of objective research out there these days showing exactly this so there are really no excuses for clinging to these delusions any more.
I skimmed both books several times back in the days, but didn't really have enough experience to know what to make of it. I once used the bridge pattern to write a multi backend GUI framework, looked it up in the book and all.
32 years into the game my perspective is that patterns is exactly what I don't want in my code...
I spent 13 years maintaining a 2mloc reservation and accounting system that used floats for everything. By the time I got there and understood enough it was simply too late to do anything about it.
Just say no, really; that road leads to madness.
If you need precision; and many do; consider fixnums, rationals or bignums, in order of increasing complexity and flexibility.