That's right. But 'Google's' covers both cases. Evidence:
case a: Bernie Sanders' socks.
case b: Bernie Sanders' campaign promises.
You weren't confused by the nuanced difference in ownership and endorsement, but you learned more about the socks - and may be more interested in them - than if the name was omitted.
Looks pretty good, but would like to see more than just a features list. Some documentation? An issues list? A way to discuss the project with the developers and other users? (e.g. via Gitter or a Google Group)
Neat. This and Oryol [1] appear to have similar goals, I think this already calls for a more in-depth comparison... Either way, this kind of technology could end up being a better choice than the node-webkit / electron paradigm, for many projects that want to target in-browser and native platforms.
I've been planning a project like that using raw GL, but with these frameworks popping up, the concept might go from experimental to very robust.
The native version is inherently lightweight and the emscripten/browser version could also be very lightweight and efficient, depending on how much attention they pay to that target while developing the framework. Looking forward to see how this plays out.
The main advantages of electron are html, css and javascript. This is not going to be an alternative to it unless you implement a browser engine on top of it, going full circle...
On the other hand, something like react-native for desktop, coupled with a nice GUI library, could be very interesting.
Sure, this will never be a 100% alternative to electron. People who derive pleasure from writing HTML, Javascript, and CSS whenever possible will never stray from that kind of framework. As you say, some also choose these frameworks because of the extensive browser API features. However, some people who don't particularly appreciate these languages and API still use electron because it allows them to target browser and native with a single code base. This is where things might change.
The sad fact is that most electron applications only use a small fraction of the massive featureset provided by a full browser, and whenever a tiny GUI application gets forcibly bundled with 70+MB of browser runtime, a cute fluffy animal dies. I think this new kind of framework has the potential to save some cute fluffy animals in the long term, though certainly not all of them.
This illustrates one of the serious issues with C++: numerous code files in a project authored relatively recently that are dedicated to basic application plumbing such as memory allocation/tracking and concurrency.
Its 2016. There are a number of performant cross-platform systems/languages that have good built-in facilities for these basic plumbing problems.
C++ is an outdated language, and the entire mindset and ecosystem is wasteful and constantly reinventing the wheel. C++ was still sort of relevant when I was playing with it in High School in 1994, but even then it was dated in most ways.
These are some very poor software engineering choices.
Educate yourselves about the Nim programming language.
Outside performance critical areas, where shaving off KB and ms really counts, C++ has become an infrastructure language with others taking most of the work.
I'm not exactly a fan of C++, but this isn't fair. What you're describing is more of a problem with this project's coding style than the language. Most of https://github.com/google/ion/tree/master/ion/base is covered either by the STL or Boost; most of what the C++ committee has been doing lately consists of trying to encourage people to not do what this project is doing (by improving the breadth of the standard library).
Should be covered by core aspects of the language, and like you said its most. Its 2016, the standard library and language should handle concurrency and memory allocation which all programs have to do.
I know a guy who works at an airline company. He's porting all the C++ and assembly code to 64 bit architecture. He genuinely did not know C++ was a seperate language from C.
To be fair, he shamelessly bragged about getting the job through nepotism.
To provide performance improvements that you don't get using the built in facilities.
You don't have to write these things yourself, but if you're trying to eke out every last drop of performance (either at runtime or build time) then you have the option to do so.
Many times it is to get the performance improvements you think you should need, but actually never will.
Having been coding since the days of Assembly being a normal language for business applications, I never seen a programming community so obsessed with micro-optimizations per code line, (without using profilers, because programmer knows best), like the C one.
And by correlation the C sub-communities from C++ and Objective-C ones.
Other communities think first into getting their data-structures and algorithms right, use the profiler and then optimize.
I agree that micro-optimization obsession is a problem in the C++ community, but sometimes it is useful and then it's nice to have the option.
Personally, I have my own custom hashmap which provides a 10%-15% performance improvement over the std one for my use case, and I also have custom mutex/thread code similar to the one listed in this library because it provides better performance when no other thread has the lock, and avoids needing to compile/link against the boost equivalent which adds seconds of compile time to any file that includes it.
These are all optimisations that I have tested and profiled though.
"one of the serious issues with C++: numerous code files in a project authored relatively recently that are dedicated to basic application plumbing such as memory allocation/tracking and concurrency."
For some applications, manually tending to the basic plumbing is a necessity and not a burden. I.e high performance applications tend to be memory bouns.
I agree that C++ is not a right tool for every job and that as a language it has issues. But those issues are not about verbosity nor about manual memory management - the latter is rather a feature.
I suppose one would need a theory encompassing most of high performance applications to achieve that.
Also, that library seems to run on a quite large subset of common platforms. I don't think there is a high level language with as painless integration to as many platforms as C++ does.
The thing with multiple platform support is that it's a really dirty realworld-bound problem. That is, no matter what one does, there will be incompatibilities and unexpected bugs. The best anyone can do, is to pick a platform with as wide userbase on the platforms one wants to support and use that if one wants to minimize headache caused by problems between third party components.
There is no joy in high level abstractions if the execution stalls on implementation related bugs.
Nim is really the way to go, I don't understand why people still spend time learning slow languages with poor engineering design and concepts. Just learn NIM!
I has been written with so solving so many concepts everyone is trying to solve, but don't solve at ALL.
Just open your eyes the solution is right under your nose.
This might be what I need, but it needs guides and tutorials ...
Basically what I'm looking for is a thin client that can render a canvas, or image, and get keyboard/mouse inputs. And if possible use the HTML Canvas API, and run JavaScript. Basically something like nw.js or Electron, but with only a canvas. With cross platform support.
I don't really understand their build system so not sure how to fix this cleanly but I added:
#define NOCRYPT (1)
#define NOUNCRYPT (1)
at the top of ./third_party/zlib/src/contrib/minizip/zip.c and unzip.c
And that got past the zlib errors on yosemite and built some of the demos (I will post some screenshots on twitter @joeld42, but it's just boxes and stuff). However, there was a linker error later with some json parser (maybe it was in the tests? I can't even tell) that I didn't figure out yet.
I also had to install "ninja" because apparently it needs like six different build systems.
The "ios" targets build... but I don't know what to do with them. I ended up with a directory full of .app files. Maybe zip them and rename them ipa?
Anyways, it looks like there's some cool stuff in there but there's a ton of dependencies and it doesn't really feel "lightweight". I'll definitely keep an eye on this one but it really could use more documentation for people not familiar with google's ecosystem.
45 comments
[ 3.1 ms ] story [ 113 ms ] threadIf it's not Google's, it's nobody's.
Could go for "Google publishes Ion, a cross-platform OpenGL abstraction."
case a: Bernie Sanders' socks.
case b: Bernie Sanders' campaign promises.
You weren't confused by the nuanced difference in ownership and endorsement, but you learned more about the socks - and may be more interested in them - than if the name was omitted.
"Google Ion" -- officially endorsed project
"Google's Ion" -- something owned/done by Google
It does not appear to be in the file system.
I've been planning a project like that using raw GL, but with these frameworks popping up, the concept might go from experimental to very robust.
The native version is inherently lightweight and the emscripten/browser version could also be very lightweight and efficient, depending on how much attention they pay to that target while developing the framework. Looking forward to see how this plays out.
[1]: http://floooh.github.io/oryol/
On the other hand, something like react-native for desktop, coupled with a nice GUI library, could be very interesting.
The sad fact is that most electron applications only use a small fraction of the massive featureset provided by a full browser, and whenever a tiny GUI application gets forcibly bundled with 70+MB of browser runtime, a cute fluffy animal dies. I think this new kind of framework has the potential to save some cute fluffy animals in the long term, though certainly not all of them.
Its 2016. There are a number of performant cross-platform systems/languages that have good built-in facilities for these basic plumbing problems.
C++ is an outdated language, and the entire mindset and ecosystem is wasteful and constantly reinventing the wheel. C++ was still sort of relevant when I was playing with it in High School in 1994, but even then it was dated in most ways.
These are some very poor software engineering choices.
Educate yourselves about the Nim programming language.
Stats for SourceForge (maybe out of date): http://www.statisticbrain.com/computer-programming-language-...
This goes for every code line that one writes, most of the time backed up by urban legends and popular beliefs instead of profiling the code.
Whereas other programming languages cultures, tend have a more meaningful approach to optimizing software.
To be fair, he shamelessly bragged about getting the job through nepotism.
You don't have to write these things yourself, but if you're trying to eke out every last drop of performance (either at runtime or build time) then you have the option to do so.
Having been coding since the days of Assembly being a normal language for business applications, I never seen a programming community so obsessed with micro-optimizations per code line, (without using profilers, because programmer knows best), like the C one.
And by correlation the C sub-communities from C++ and Objective-C ones.
Other communities think first into getting their data-structures and algorithms right, use the profiler and then optimize.
Personally, I have my own custom hashmap which provides a 10%-15% performance improvement over the std one for my use case, and I also have custom mutex/thread code similar to the one listed in this library because it provides better performance when no other thread has the lock, and avoids needing to compile/link against the boost equivalent which adds seconds of compile time to any file that includes it.
These are all optimisations that I have tested and profiled though.
The problem I see is when doing applications where doing the work in 100ms or 1s doesn't matter at all.
Yet one will be discussing about bounds checking impact, if i++ or i = i + 1 generate the same code and many other micro-optimizations.
For the type of work I do, I always embraced the STL and never though a second about those issues, yet I was able to fulfill the expectations.
For some applications, manually tending to the basic plumbing is a necessity and not a burden. I.e high performance applications tend to be memory bouns.
I agree that C++ is not a right tool for every job and that as a language it has issues. But those issues are not about verbosity nor about manual memory management - the latter is rather a feature.
Also, that library seems to run on a quite large subset of common platforms. I don't think there is a high level language with as painless integration to as many platforms as C++ does.
The thing with multiple platform support is that it's a really dirty realworld-bound problem. That is, no matter what one does, there will be incompatibilities and unexpected bugs. The best anyone can do, is to pick a platform with as wide userbase on the platforms one wants to support and use that if one wants to minimize headache caused by problems between third party components.
There is no joy in high level abstractions if the execution stalls on implementation related bugs.
I has been written with so solving so many concepts everyone is trying to solve, but don't solve at ALL.
Just open your eyes the solution is right under your nose.
It's hilarious that nobody recognizes blatant trolling on HN
Since it is also from Google, even though not officially, maybe the Android NDK team could learn a few things about C++ code quality.
Ion's code looks so much nicer than any these APIs
https://developer.android.com/ndk/reference/index.html
#define NOCRYPT (1) #define NOUNCRYPT (1) at the top of ./third_party/zlib/src/contrib/minizip/zip.c and unzip.c
And that got past the zlib errors on yosemite and built some of the demos (I will post some screenshots on twitter @joeld42, but it's just boxes and stuff). However, there was a linker error later with some json parser (maybe it was in the tests? I can't even tell) that I didn't figure out yet.
I also had to install "ninja" because apparently it needs like six different build systems.
The "ios" targets build... but I don't know what to do with them. I ended up with a directory full of .app files. Maybe zip them and rename them ipa?
Anyways, it looks like there's some cool stuff in there but there's a ton of dependencies and it doesn't really feel "lightweight". I'll definitely keep an eye on this one but it really could use more documentation for people not familiar with google's ecosystem.