Excuse me, but it is complete nonsense to suppose that inheritable classes or templates reduce performance, if that is what you mean by generics. In fact, in the hands of skilled programmers, templates are often used to improve performance. And inheritable types has nothing whatsoever to do with performance, again improving it if anything (by allowing you to express a design in a way that is both extensible and performant).
You're wrong. Depending on the implementation, generics can indeed come with a performance hit; the main example is Java, where type erasure and runtime casts are involved.
There's currently no generics support in Go but, based on what the language currently is it (statically typed, no operator overloading, type interference on variable declarations, etc.) a generics implementation will have to be "magic" in some way - that is, it cannot simply be implemented as a code rewrite before compiling.
goroutines are not threads - the Go documentation enforces this point over and over again, because it is not a minor distinction. Now, this doesn't make Go concurrent runtimes "predictable" either, but it is not as bad as you picture it.
Modern data structures without classes or generics? This is where I checked out on Go after initially being interested.
Well, it is your loss. The lack of classes (a blessing) and generics (a curse) means that the language is very performant, at the cost of expressiveness.
And no way to avoid the memory management, a crippling problem shared with Java that makes it a bad choice for many applications (e.g., low latency financial transactions).
I've seen a shitload of financial transaction code written in Java. Now, i'll admit that C++ is usually much better suited for the task, but "lack of memory management" is normally not an issue for that application - or for most ones, i'd add.
It fills nicely the niche between low and high-level languages. You get C-like semantics, modern data structures, memory management and high performance with fast compiled binaries.
Also, it is one of the few languages out there where concurrency is not an afterthought.
I wish the standard library came with more goodies (Python can really spoil you in that sense) and that it was a bit more expressive - generic programming f.ex. would be a godsend. But hose will probably happen in the future. It is an otherwise fast, clean and well designed language, which thanks Baby Jesus isn't obsessed with OOP.
LinkedIn has clear and obvious enterprise value, both in single sign-on and platform value and the treasure trove of backend user data.
Agreed, fair enough. Then again, there's the question of how much value is really there. LinkedIn might be deemed valuable for Microsoft, but at 26,2 billion?
Uh, you don't understand the value of LinkedIn to an enterprise focused company?
No, i really don't. Twitter is a purely consumer product - what use would tweets have within a company?
Crossing the line from consumer to enterprise is not easy, even when you're not Twitter. Facebook is, IMHO, making the same mistake with Workplace in world where Slack and Hangouts/gDocs already exist.
The problem, is news doesn't really have to be any of the above. Investigation pieces and editorials do though, but just because they share space in a newspaper doesn't mean they are the same.
News should be nothing more than "this just happened/is happening". With that in mind, Twitter is indeed a good source of news - it reacts really fast to global events.
I'd argue that Twitter is a very effective form of news. Everyone and his mother has an account these days, and whenever something important happens the immediacy of the communication and it's propagation via comments/retweets means that you get updates pretty much on real time.
I remember following the failed 2016 coup in Turkey and was pretty amazed on how Twitter beat channels like CNN and BBC News - things i read on Twitter would be reported anything up to 30 minutes later on live TV.
It's a shame Twitter never managed to come up with a profitable business plan.
What exactly would Twitter liabilities be? Honestly have no idea.
PS, i loved the Microsoft bit and how "no one seems to think the acquisition would make any sense for an increasingly enterprise-focused company", right after they dumped an island made of money for LinkedIn.
Again, the "rest of the platform" issues aren't relevant here, other than perhaps screen size (iPhone vs. iPad). I'm not sure what processors Apple's used have in the way of floating-point or SIMD support, so I'm not sure what flavors of "fat" are needed other than "ARMv6 vs. ARMv7 vs. ARMv8-A 64-bit".
ARM11 (iPhone 1 to 3), A4 (iPhone 4), A5 (iPhone 4S), A7 (iPhone 5), A8 (iPhone 6), A10 Fusion (iPhone 7). And that's just for their phones.
Or, you can get a x86 platform with offers backwards compatible instruction sets and relatively standardized architectures.
The problem with ARM goes way beyond CPU compatibility, which is the point made by Linus in the video: there's just too many CPU+hardware combinations out there, all (mostly) incompatible with each other. Apple gets away with multi-platform (fat) binaries simply because their ecosystem is way more constrained.
He is talking about THE LINUX KERNEL which runs on more than desktops and mobile devices. how can you comment on things like this with your deficient ability to comprehend basic information?
Chill down son. Like it or not, mobile device are by far the largest Linux install base in the world, with roughly 80% of all phones sold each year running Android (meaning Linux on ARM). This is orders of magnitude above desktops, let alone embedded devices. As the head kernel maintainer rest assured, the guy is plenty aware of the shortcomings of that platform.
Same deal. The problem is deeper than just applications though - this is also the reason why you can't have a generic Android installer for multiple platforms.
Android suffers this very issue, where you end up needing a bytecode VM (Dalvik) just to ensure compatibility across devices. This doesn't mean that the ARM instruction set isn't a joy to work on though.
Slashdot Mirror
Excuse me, but it is complete nonsense to suppose that inheritable classes or templates reduce performance, if that is what you mean by generics. In fact, in the hands of skilled programmers, templates are often used to improve performance. And inheritable types has nothing whatsoever to do with performance, again improving it if anything (by allowing you to express a design in a way that is both extensible and performant).
You're wrong. Depending on the implementation, generics can indeed come with a performance hit; the main example is Java, where type erasure and runtime casts are involved.
There's currently no generics support in Go but, based on what the language currently is it (statically typed, no operator overloading, type interference on variable declarations, etc.) a generics implementation will have to be "magic" in some way - that is, it cannot simply be implemented as a code rewrite before compiling.
goroutines are not threads - the Go documentation enforces this point over and over again, because it is not a minor distinction. Now, this doesn't make Go concurrent runtimes "predictable" either, but it is not as bad as you picture it.
Go has supported building packages as shared libraries for a good while now.
And, speaking of compiling, the executables are large — even if you use somebody else's code, you must still compile it all into your application...
...by default. Try go build -linkshared.
Modern data structures without classes or generics? This is where I checked out on Go after initially being interested.
Well, it is your loss. The lack of classes (a blessing) and generics (a curse) means that the language is very performant, at the cost of expressiveness.
And no way to avoid the memory management, a crippling problem shared with Java that makes it a bad choice for many applications (e.g., low latency financial transactions).
I've seen a shitload of financial transaction code written in Java. Now, i'll admit that C++ is usually much better suited for the task, but "lack of memory management" is normally not an issue for that application - or for most ones, i'd add.
It fills nicely the niche between low and high-level languages. You get C-like semantics, modern data structures, memory management and high performance with fast compiled binaries.
Also, it is one of the few languages out there where concurrency is not an afterthought.
I wish the standard library came with more goodies (Python can really spoil you in that sense) and that it was a bit more expressive - generic programming f.ex. would be a godsend. But hose will probably happen in the future. It is an otherwise fast, clean and well designed language, which thanks Baby Jesus isn't obsessed with OOP.
LinkedIn has clear and obvious enterprise value, both in single sign-on and platform value and the treasure trove of backend user data.
Agreed, fair enough. Then again, there's the question of how much value is really there. LinkedIn might be deemed valuable for Microsoft, but at 26,2 billion?
Uh, you don't understand the value of LinkedIn to an enterprise focused company?
No, i really don't. Twitter is a purely consumer product - what use would tweets have within a company?
Crossing the line from consumer to enterprise is not easy, even when you're not Twitter. Facebook is, IMHO, making the same mistake with Workplace in world where Slack and Hangouts/gDocs already exist.
Um, that's not what it says on that excerpt...
The problem, is news doesn't really have to be any of the above. Investigation pieces and editorials do though, but just because they share space in a newspaper doesn't mean they are the same.
News should be nothing more than "this just happened/is happening". With that in mind, Twitter is indeed a good source of news - it reacts really fast to global events.
I'd argue that Twitter is a very effective form of news. Everyone and his mother has an account these days, and whenever something important happens the immediacy of the communication and it's propagation via comments/retweets means that you get updates pretty much on real time.
I remember following the failed 2016 coup in Turkey and was pretty amazed on how Twitter beat channels like CNN and BBC News - things i read on Twitter would be reported anything up to 30 minutes later on live TV.
It's a shame Twitter never managed to come up with a profitable business plan.
Twitter's business model has been non profitable pretty much since its inception. They were aiming for a LinkedIn and no one is taking the bait.
Wonder if we're reaching the end of the second dotcom bubble...
What exactly would Twitter liabilities be? Honestly have no idea.
PS, i loved the Microsoft bit and how "no one seems to think the acquisition would make any sense for an increasingly enterprise-focused company", right after they dumped an island made of money for LinkedIn.
And, you were eaten by a grue.
Between an idiot and and a son of a bitch, always choose the former. Sons of bitches, at the very least, have a plan.
There are the CPU issues, such as "what version of VFP does the processor have, if any?" [...]
Which is also tackled in the x86 world...
Again, the "rest of the platform" issues aren't relevant here, other than perhaps screen size (iPhone vs. iPad). I'm not sure what processors Apple's used have in the way of floating-point or SIMD support, so I'm not sure what flavors of "fat" are needed other than "ARMv6 vs. ARMv7 vs. ARMv8-A 64-bit".
ARM11 (iPhone 1 to 3), A4 (iPhone 4), A5 (iPhone 4S), A7 (iPhone 5), A8 (iPhone 6), A10 Fusion (iPhone 7). And that's just for their phones.
I remember having a "whoa" moment the first time i found out ARM supported free bitshifts witihin a MOV.
Or, you can get a x86 platform with offers backwards compatible instruction sets and relatively standardized architectures.
The problem with ARM goes way beyond CPU compatibility, which is the point made by Linus in the video: there's just too many CPU+hardware combinations out there, all (mostly) incompatible with each other. Apple gets away with multi-platform (fat) binaries simply because their ecosystem is way more constrained.
He is talking about THE LINUX KERNEL which runs on more than desktops and mobile devices. how can you comment on things like this with your deficient ability to comprehend basic information?
Chill down son. Like it or not, mobile device are by far the largest Linux install base in the world, with roughly 80% of all phones sold each year running Android (meaning Linux on ARM). This is orders of magnitude above desktops, let alone embedded devices. As the head kernel maintainer rest assured, the guy is plenty aware of the shortcomings of that platform.
Same deal. The problem is deeper than just applications though - this is also the reason why you can't have a generic Android installer for multiple platforms.
Can we also light a candle for Cyrix?
He's indeed talking about desktop and mobile devices though, where this is an issue.
Android suffers this very issue, where you end up needing a bytecode VM (Dalvik) just to ensure compatibility across devices. This doesn't mean that the ARM instruction set isn't a joy to work on though.
What? Since when cars sell with an EULA attached?