Revolutionary technology right here lads. This is what happens when you ignore the entire history of programming languages and all the lessons learned along the way. You end up with a proposal to add type parameters, 8 or so years after its release.
Java took 8 or so years to add generics to its language, what's your point?
They explicitly did NOT ignore the history of programming languages, and resisted the urge of adding generics without fully understanding the problem that it was trying to solve (in the context of Go). See also: https://golang.org/doc/faq#generics
There's a trend going on in the past decade or so where every language goes to adopt features from other languages, adding complexity without actually solving a problem other than "I use this feature in language X, why doesn't YOUR language have it?"
Which lead to pretty shitty decisions, like half implementations of OOP in PHP and Javascript (have some classes, but not access modifiers), functional programming in Java, or every paradigm ever invented all at the same time in Scala.
> They explicitly did NOT ignore the history of programming languages, and resisted the urge of adding generics without fully understanding the problem that it was trying to solve (in the context of Go). See also: https://golang.org/doc/faq#generics
That's simply not true. Languages like StandardML, Ocaml, or Haskell have already solved the major issues 40 years ago with types vastly superior to what go offers. Since then, nothing has come even close to that level of utility and usability.
Like so many other things in go, it seems a combination of Hubris and NIH syndrome.
Just to get your argument straight: nothing comes close to the level of utility and usability of StandardML, Ocaml and Haskell?
So why haven’t aren’t those languages commonly used?
The simple answer is that there’s a lot more to a language than its type system. Go is popular because it’s simple. Throwing generics on the language without a lot of deep thought and time risks adding marginal utility while destroying a large amount of the core simplicity. While I too want generics, I understand that the caution and skepticism of the core team is not “Hubris and NIH”.
Java or C# decide null is bad and try very hard to add Option and non-nullables, but go's creators just decide they must not have a good reason, so nulls everywhere.
The potential problem of things like empty interface escaping the type system are well known, but go's creators decided that everyone else's experience here didn't really matter, so you get not only empty interface, but it becomes the only way to do certain things because of the lack of generics.
Speaking of generics, every popular multi-use language winds up building in generics or tacking them on later. Go's creators denounce all other solutions as lacking.
What makes them think they are so incredibly special that they don't need to learn from the experience of others? It seems to me that the only reasons are basically ignorance or arrogance and I don't think they are ignorant.
> So why haven’t aren’t those languages commonly used?
Languages don't generally survive without a big corporation paying the bills. If Google had chosen to put their hundreds of millions into SML instead of golang, the world would be a very different place. The first company to give such a language a chance was Mozilla with Rust and we can see how popular it has become. You could view Rust as SML with c-like syntax, lifetimes, unsafe options, no GC, extra pointer complexity, macros, etc. A bit more potential power at the cost of orders of magnitude more complexity due to being targeted at a different, lower-level problem set.
> Just to get your argument straight: nothing comes close to the level of utility and usability of StandardML, Ocaml and Haskell?
I would argue that SML is the best of those three languages and the most comparable to go as well. It's designed to be pragmatic, easy for first-year students to learn, and easy for later students to implement in compiler classes.
Go's headline feature (goroutines aka channels) have been implemented in PolyML or CML a decade or two before go existed and they did it in a type safe manner. Go has multi-value returns, but all that means is that it has partial tuple support unlike SML which has both tuples and pattern matching. Despite what you might think you know from Haskell, SML allows mutation complete with safe (and type safe) pointers.
Rather than interfaces, SML has structural typing which allows most of the same features, but with type safety and generics. There's also sum types (basically union types) which are easy to use with pattern matching and guarantee that all union types are handled safely. Unlike go with nulls everywhere that must be checked at your own peril, SML uses option types and nothing is ever null.
All of that said, I don't hate go. I believe the language could keep its existing syntax while adding most if not all of these features and retaining a decent amount of backward compatibility and making code both more terse and more readable. It could solve its generics issue while also solving its other type problems and potentially picking up extra performance on the way.
I think you're missing the point that I was trying to make.
Sometimes more features can make a thing worse. More advanced type systems may not necessarily make a large group of people more productive in a language, even if they are strict improvements. Go seems to have hit a sweet spot in terms of having just enough features to mostly get out of the way, and be otherwise straight-forward.
You could describe this part of its appeal as "worse is better". If you aren't careful about how you make something like that "better", you'll actually make it worse. I acknowledge this reality, while still personally wanting algebraic types, optional types, generics, etc. like everyone else. This gives rise to an "innovator's dilemma" of sorts for language designers.
(As an aside, if you look at the size of the Go team at Google, you'll probably be able to conclude that it's unlikely Google has put "hundreds of millions" into Go. But this is related to the core point: there isn't a huge list of language features that requires teams of experts to implement.)
Look over the SML types (not modules) and tell me where all that complexity lies. I'd argue that SML is both more simple than go (especially with this proposal) and more powerful. SML doesn't allow the shenanigans Haskell does (and a go using something similar to the SML type system wouldn't either).
As to hundreds of millions, that's easily true. Most of the people on that team make 500k per year at least with some making way more than that (and we aren't including other benefits of costs to the company who employs them). The language is publicly 11 years old and existed before that.
1e8 / 5e5 / 11 gives a mere 18 developers and less than 200 man years. I seriously doubt the compiler, libraries, and extensive tooling took less than 5x that amount at a minimum.
Re: SML types, I think you may be confounding simplicity and terseness. The last time I touched ML was decades ago, so I don’t have a specific opinion here but consider “both more simple and more powerful” could be a contradiction. The lack of power and expressiveness can in fact be part of what makes things simpler, not strictly because of the language but because programmers are forced to do things in a “dumber” way.
My criticism actually comes from SML as I view Haskell's hallmark features (immutability, laziness, and no side effects) to be at odds with pragmatic programming. I also dislike type soup that requires everyone on the team to have an extensive background with this being another area where SML seems far superior to Haskell.
I mention these languages primarily because of their use of the Hindley-Milner type system (I could have mentioned Rust, Elm, and quite a few less-known languages too).
The problem is that languages are difficult to change later. Once your language is designed, it becomes hard to change it. You can see that with Java that has half baked generics, horrible primitive types, strange collections, null and so on.
I believe, that for new languages there are only two choices:
1. Build a simple language and don't implement generics _forever_. That is fine! Just stick with it.
2. Build generics into the language from the beginning and do it right. If that's too hard for you, then don't create a language in the beginning. Creating programming languages is damn hard. Amateurs will just fail.
As a side note: My biggest disappointment regarding the 5G discussion with respect to potential health implications is the widespread lack of acknowledgement about the fact that we have not yet conducted any meaningful scientific experiments (let alone ones whose methodology is robust) to even hold a meaningful debate.
It's derailed into a political debate between those who "know for a fact" there are zero health implications and those who "know for a fact" that you'll certainly die within a week from a 5g antenna being placed next to your apartment.
If the energy isn't enough to ionize, then what is there to study?
(Extreme) heating effects can cause cancer, but the source of heat is irrelevant. The power levels 5G uses make even this point completely moot.
If you really have to search for something that could cause you cancer, perhaps those rather carcinogenic compounds your phone is made out of could be studied instead? Although I prefer just not to pulverize my phone and breath in the resulting dust. :-)
There has been a fabled danger of low levels of non-ionizing radiation without an explained mechanism for decades. There is no data to support it, but there will never be enough “studies” to disprove it.
What gets me is that these people still walk out in the sun.
We are talking about orders of magnitude weaker radiation than what you get dosed with every time you go outside. But further, sunlight does contain ionizing radiation (hello UV).
Yes, commercial airliners do pose a real health risk. There’s an understood mechanism and impact. I know I was joking about it, but only to highlight how crazy it is to push personal electronics use down for radiation health concerns, while airplanes continue to operate with no changes.
> If the energy isn't enough to ionize, then what is there to study?
DNA is conductive, and there are researchers who believe that this might be an important component in how the cell detects and repairs damage to its DNA [1].
There have been a couple of papers that claim that DNA can act as a fractal antenna allowing it to react to wavelengths that you would at first expect to be way too large to affect it. Here's one [2], which claims it interacts over a wide range of frequencies with a resonance at 34 GHz.
If DNA charge transport does turn out to play an important role in how the cell identifies damaged DNA, and if it turns out that those fractal antenna claims are true, then we'd have a potential mechanism for non-ionizing, non-heating radiation to increase cancer rates.
Note that it would not cause cancer, but it might prevent a cell from finding and repairing damage that if left unrepaired will lead to cancer.
The first part of the above, that DNA is conductive, is firmly established. How the cell detects damaged DNA is not known. That charge transport plays a role in that is currently just one theory that researchers are studying, but it is a theory that if it turns out to be true will not surprise anyone.
I haven't been able to find much on fractal antennas, especially very small ones, so can't tell if the claims about DNA acting as an antenna have merit.
Possible health effects of non-ionizing radiation have been studied in all kinds of frequency bands for many decades. So far, no significant effects that go beyond heating have been found, and there is no known mechanism that could cause such effects.
To argue devil's advocate, the scientific literature commenting on this says that existing studies are in too short a timeframe to draw long-term conclusions. I haven't dived into this other than a search on PubMed so it's a question of faith either way.
I've tended to side with the "5G must be safe" crew but to see the other side I checked pubmed and found a fair few reputable-looking studies such as this: https://www.ncbi.nlm.nih.gov/pubmed/31991167
So, yeah, how much do we know for a fact? I say that as a true sceptic (i.e. sceptical with my own views as well as anyone else's). Decades ago we knew for a fact that dumping a ton of plastic into the environment was totally fine. Also we "didn't know for a fact" that greenhouse gas emissions could play a part in affecting our climate for the worse.
Because it is transmitted at the same frequency as previous cell phone technologies. There are literally decades worth of studies around the effects of nonionizing radiation.
The only thing 5G changes is the transmission protocol.
It's fine to be a skeptic, but this is fear mongering. We don't need a 20 year long study to prove something we've known to be safe for 20 years because some crackpots claim it makes them nauseous or causes cancer. If you are going to be skeptical, why aren't you skeptical of the unverified negative claims?
Where's my proof? Google "non-ionizing radiation health". Would find a bunch of articles from reputable sources that all land on the same conclusion. It's safe.
TBH, unless you work directly in an area like this and stay up to date, it's a question of faith in experts either way. It basically becomes an appeal to authority, and as you can see, if you have multiple putative authorities, it becomes difficult to select.
This isn't the first anti-RF study he's published and I doubt it will be the last.
Looking further into his claims, he's said everything from "Alzheimer's is caused by WiFi" to "previous non ionizing studies were all flawed because that used the wrong test animal".
I expect when 6G rolls out he'll publish exactly the same study with an equally scary title.
I know, I'm committing an ad hominem fallacy. But at the end of the day I'm not buying his article see the rest of the claims. It is good enough for me that consensuses of much larger studies over longer periods are pretty much all against his study.
Pubmed is littered with similar authors in peer-reviewed journals. He's not the only one.
This shows the problem right now. If you're not an expert, you don't know what you don't know, and have to yield to some kind of authority. Noise is greater than it has ever been, and trust is low. This will get worse before it gets better....
> Because it is transmitted at the same frequency as previous cell phone technologies.
AFAIK it is not, 5G also deploys >24GHz (up to 300GHz).
Happy to be proven wrong, but so far - from my POV - this has been the biggest hole in the theory that we do not need to test 5G because we already know it is safe...
My disappointment is the lack of discussion regarding privacy. It was posted on HN just a few weeks ago how a human can be identified by its gate with high density deployment of antennas.
- Fewer towers necessary because larger coverage areas
- Better penetration of materials
- Doesn’t interfere with weather data collection
Why is there even a push for 5G? What is the benefit to the consumer? A higher bill because a 10x increase in infrastructure is necessary? Asinine. Just use wifi. I don’t understand what 5G was even made to technically accomplish.
Your ignorance of its benefits doesn't mean it has none.
You can literally google "5g benefits" and read through any number of whitepapers.
For one, it has much lower latency, making it competitive with fibre in many areas.
It's more efficient, allowing more devices in the same area. The 60GHz band in particular will allow extreme densities as seen in sports stadiums or major train stations in rush hour.
It has higher peak bandwidth.
It includes special modes optimised for very lower power devices with modest bandwidth requirements.
> For one, it has much lower latency, making it competitive with fibre in many areas.
What do people do on their phones ? I'm forcing mine in 3g all the time and it's faster than I need already. Why would you need 1ms ping and 1gbs d/u speeds ?
This sounds like phones having 4k+ screens to me, updating specs for the sake of updating specs, there is no real world need behind it. I guess many people are making big bucks in the scheme though, that's probably the major 5g benefit.
Recently during work on my cable line, I ran my whole house off of a T-Mobile hotspot on my S10. I was pleasantly surprised as browsing latency actually seemed to be less than cable, and I the FireTV was even able to stream video reasonably well.
Well if my browser, music player and chat app weren't taking literal gigabytes of ram each it might be enough ...
Our computers are millions of times more powerful than back in the days but somehow my 2018 macbook pro crawls to a halt if slack displays more than 2 gifs at the same time.
Anyway, I think we're artificially creating needs that aren't needs in the first place. "b-bu-but how am I supposed to telework from the subway if I don't have my 5g =(", "I can't even stream youtube 8k videos from the bus =("
Yeah, it works as a competitor to Wi-Fi in the ultra dense scenarios. How on Earth is it justified to deploy it to an entire city, let alone a Metropolitan area, county, state, or country? It has specific, limited use cases, and even then Wi-Fi’s solutions are arguably much better. Where is the benefit to the consumer?
Every item in your list of "4G benefits over 5G" is not actually a benefit of 4G over 5G. They are all benefits of lower frequencies (which both 4G LTE and 5G NR can use) over higher frequencies (which only 5G NR can use). When running over these lower frequencies, 5G needs the same number of towers, has the same penetration of materials, and has the same interference with weather radar.
It enables huge numbers of connections, making it more feasible for IoT appliances to use cell radios instead of wifi radios, taking yet more control away from consumers.
Oh wait, 'benefits'... well I suppose that's a matter of perspective..
>Even without superconductivity, ordinary computers and other electronics could get a huge boost in performance versus cost from twistronics, due to the fact that entire complex electronic circuits could in theory be built into a few sheets of pure carbon, without needing a dozen or more complexly etched layers of challenging materials common to today’s chips.
I'm going to speak with a potential employer quite differently than I will with a friend. Trying to artificially move yourself into that category is not going to work and will just make me even less sure of the process.
At least with a standard interview format I know what the interviewer wants. If you flip that on me and put me in a position where I have no idea whats going on, it's not going to end well.
I don't remember who first said it but blockchain has exactly one killer feature, Bitcoin. If you try to adapt it anywhere else you're probably abusing the tech.
I saw another very interesting use that I don't fully understand from a technical perspective, but it basically promised to accurately report position-at-time, via a system of transponders.
The use case is, I can tell when Fedex or the local pizza place is lying to me about my delivery being 30 minutes away, or half a mile down the street, or whether the delivery driver actually attempted to physically deliver my package to my door at 5:47pm or not. (Or Ikea can verify that their subcontracted delivery driver actually got the couch to the buyer on Sunday, or both Uber and I can know exactly where I was dropped off and picked up and when, etc., etc., without either party being able to lie about it.)
A friend of mine agreed that the idea was good, but looked into their implementation and said it was a horrorshow.
Well, that is already working pretty well. E.g. large carriers are using that in their operations, one of the distinctions between those and small time operators. One of the biggest benefits of this is the electronic proof of delivery. Just how Blockchain would help with I didn't get yet.
I think they slathered some "blockchain" on it, when they probably meant to say "cryptography"; the big value-add was that the records were tamper-proof - there was somehow no way to claim you were dropping a package off at my house when you were actually miles away.
Except that you don't have any solution for preventing squatting or other kinds of domain abuse. By design, they place this system above the court system. I'm pretty sure this is only appealing to some kind of anarcho-technologists.
It's disappointing to see that the 1 billion figure is what really grinds people's gears in here. That's the thing you should be the least concerned about.
It's probably because it's the most objectionable part of this, so it's the main target for nitpicking. The "Apple's responsible for a fuckup of their own product" isn't controversial, and I don't think "fuckups of ML used for law enforcement are a serious thing" is controversial either.
Aye, you would think that people would recognise that the value is directly proportional to the propensity of it being covered in news articles and, thus, starting discussions, such as this.
We asked respondents to evaluate their own competence, for the specific work they do and years of experience they have, and almost 70% of respondents say they are above average while less than 10% think they are below average. This is statistically unlikely with a sample of over 70,000 developers who answered this question, to put it mildly.
I'm not so sure about this conclusion. I feel that below-average developers are less likely to answer stack overflow surveys at all. In my anecdotal experience, below-average devs usually have little interest in interacting with the overall "developer community" or reading about development more than the absolute minimum needed to finish their assigned tasks.
That was my takeaway as well. It’s also somewhat ambiguous; who are you comparing yourself to? All coworkers, everyone in your graduating class, people the same age as you?
I’m sure that we’re seeing at least a bit of everyone thinking they’re more skilled than they are, but it’s more slight than that caption would lead you to believe.
I don't believe that putting a price tag on a piece of software legitimizes it for a given use case.
I get this same feeling from posts that say "Product X written in language Y". While I agree that there exists a right programming language for a given task, it is not in itself a reason to use product X.
I once "inherited" an Adobe ColdFusion codebase that hadn't been touched in about 15 years. I guess the reason it hadn't been touched in so long was because it simply worked. It was a well structured project and easy to get in to. Implementing some minor new features was straight forward and thanks to an existing test suite easy to test.
Needless to say I was pleasantly surprised by that.
