Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
All Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletter Hub
Free Learning
Arrow right icon
timer SALE ENDS IN
0 Days
:
00 Hours
:
00 Minutes
:
00 Seconds

Tech News - Languages

202 Articles
article-image-red-hat-team-announces-updates-to-the-red-hat-certified-engineer-rhce-program
Amrata Joshi
12 Apr 2019
3 min read
Save for later

Red Hat team announces updates to the Red Hat Certified Engineer (RHCE) program

Amrata Joshi
12 Apr 2019
3 min read
The Red Hat Certified Engineer (RHCE) certification program has certified skilled IT professionals for around 20 years now. This program has also one of the leading certification programs for Linux skills. As new technologies are coming up and industries are equally evolving, the focus has now shifted to hybrid cloud implementations. With this new development, shift automation has become an important skill to learn for Linux system administrators. So, the team behind RHCE thought that there is a need for evolving the RHCE program for Red Hat Certified Professionals. What changes are expected? In the updated RHCE program, the team is shifting the focus to automation of Linux system administration tasks with the help of Red Hat Ansible Automation and will also be changing the requirements for achieving an RHCE credential. With the upcoming release of Red Hat Enterprise Linux 8, the team at RHCE will be offering a new course and a new certification exam. Red Hat System Administration III: Linux Automation (RH294) The team at RHCE has designed this course for Linux system administrators and developers who are into automating provisioning, configuration, application deployment, and orchestration. The ones’ taking up this course will learn how to install and configure Ansible on a management workstation and will get a clear idea about preparing managed hosts for automation. Red Hat Certified Engineer exam (EX294) The RHCE exam will focus on the automation of Linux system administration tasks that uses Red Hat Ansible Automation and shell scripting. The ones who pass this new exam will become RHCEs. What will remain the same? Ken Goetz, vice president of Training and Certification at Red Hat writes in a blog post, “One thing that we want to assure you is that this is not a complete redesign of the program.” The candidates can still get an RHCE by having first passed the Red Hat Certified System Administrator exam (EX200) and then later passing an RHCE exam while still being an RHCSA. The Red Hat Enterprise Linux 7 based RHCE exam (EX300) will remain available for a year post the new exam gets released. How does it impact candidates? Current RHCE The RHCE certification is valid for three years from the date the candidate has become an RHCE. The period of the RHCE can be extended by earning additional certifications that can be applied towards becoming Red Hat Certified Architect in infrastructure. Candidates can renew the RHCE before it becomes non-current by passing the new RHCE exam (EX294). Aspiring RHCE An RHCSA who is progressing towards becoming an RHCE can continue preparing for the Red Hat Enterprise Linux 7 version of the course and take the current RHCE exam (EX300) till June 2020. Or else they can prepare for the new exam (EX294), based on the upcoming release of Red Hat Enterprise Linux 8. Red Hat Certified Specialist in Ansible Automation The ones who are currently Red Hat Certified Specialist in Ansible Automation can continue to demonstrate their Ansible automation skills and knowledge by earning RHCE via the new process. Ken Goetz, vice president of Training and Certification at Red Hat writes in the post, “We are aligning the RHCE program, and the learning services associated with that program, to assist individuals and organizations in keeping up with these changes in the industry.”   To know more about this news, check out Red Hat’s blog post. Red Hat Satellite to drop MongoDB and will support only PostgreSQL backend Red Hat announces CodeReady Workspaces, the first Kubernetes-Native IDE for easy collaboration among developers Red Hat drops MongoDB over concerns related to its Server Side Public License (SSPL)  
Read more
  • 0
  • 0
  • 4904

article-image-stack-exchange-migrates-to-net-entity-framework-core-ef-core-stack-overflow-to-follow-soon
Savia Lobo
08 Oct 2018
2 min read
Save for later

Stack Exchange migrates to .NET Entity Framework Core (EF Core), Stack Overflow to follow soon

Savia Lobo
08 Oct 2018
2 min read
Last week, Nick Craver, Architecture Lead for Stack Overflow, announced that Stack Exchange is migrating to .NET Entity Framework Core (EF Core) and seek help from users to test the EF Core. The Stack Exchange community has deployed a major migration from its previous Linq-2-SQL to EF Core. Following this, Stack Overflow may also get a partial tier to deploy later today. In his post, Nick said, “Along the way we have to swap out parts that existed in the old .NET world but don't in the new.” Some changes in Stack Exchange and Stack Overflow post migration to .NET EF Core The Stack community said that they have safely diverged their Enterprise Q3 release. This means they work on one codebase for easier maintenance and the latest features will also be reflected in the .NET Entity Framework Core. Stack Overflow was written on top of a data layer called Linq-2-SQL. This worked well but had scaling issues following which the community replaced the performance critical paths with a library named as Dapper. However, the community said that until today, some old paths, mainly where they insert entries, remained on Linq-2-SQL. The community also stated that as a part of the migration, a few code paths went to Dapper instead of EF Core. This means Dapper wasn’t removed and still exists post migration. This migration may affect posts, comments, users, and other ‘primary’ object types in Q&A. Nick also added, “We're not asking for a lot of test data to be created on meta here, but if you see something, please say something!”. He further added, “The biggest fear with a change like this is any chance of bad data entering the database, so while we've tested this extensively and have done a few tests deploys already, we're still being extra cautious with such a central & critical change.” To know more about this in detail, head over to Nick Craver’s discussion thread on Stack Exchange. .NET Core 3.0 and .NET Framework 4.8 more details announced .NET Core 2.0 reaches end of life, no longer supported by Microsoft Stack Overflow celebrates its 10th birthday as the most trusted developer community
Read more
  • 0
  • 0
  • 4879

article-image-numpy-1-17-0-is-here-officially-drops-python-2-7-support-pushing-forward-python-3-adoption
Vincy Davis
31 Jul 2019
5 min read
Save for later

NumPy 1.17.0 is here, officially drops Python 2.7 support pushing forward Python 3 adoption

Vincy Davis
31 Jul 2019
5 min read
Last week, the Python team released NumPy version 1.17.0. This version has many new features, improvements and changes to increase the performance of NumPy. The major highlight of this release includes a new extensible numpy.random module, new radix sort & timsort sorting methods and a NumPy pocketfft FFT implementation for accurate transforms and better handling of datasets of prime length. Overriding of numpy functions has also been made possible by default. NumPy 1.17.0 will support Python versions 3.5 - 3.7. Python 3.8b2 will work with the new release source packages, but may not find support in future releases. The Python team had previously updated users that Python 2.7 maintenance will stop on January 1, 2020. NumPy 1.17.0 officially dropping Python 2.7 is a step towards the adoption of Python 3. Developers who want to port their Python 2 code in Python 3, can check out the official porting guide, released by Python. Read More: NumPy drops Python 2 support. Now you need Python 3.5 or later. What’s new in NumPy 1.17.0? New extensible numpy.random module with selectable random number generators NumPy 1.17.0 has a new extensible numpy.random module. It also includes four selectable random number generators and improved seeding designed for use in parallel processes. PCG64 is the new default numpy.random module while MT19937 is retained for backwards compatibility. Timsort and radix sort have replaced mergesort for stable sorting Both the radix sort and timsort have been implemented and can be used instead of mergesort. The sorting kind options ‘stable’ and ‘mergesort’ have been made aliases of each other with the actual sort implementation for maintaining backward compatibility. Radix sort is used for small integer types of 16 bits or less and timsort is used for all the remaining types of bits. empty_like and related functions now accept a shape argument Functions like empty_like, full_like, ones_like and zeros_like will now accept a shape keyword argument, which can be used to create a new array as the prototype and overriding its shape also. These functions become extremely useful when combined with the __array_function__ protocol, as it allows the creation of new arbitrary-shape arrays from NumPy-like libraries. User-defined LAPACK detection order numpy.distutils now uses an environment variable, comma-separated and case insensitive detection order to determine the detection order for LAPACK libraries. This aims to help users with MKL installation to try different implementations. .npy files support unicode field names A new format version of .npy files has been introduced. This enables structured types with non-latin1 field names. It can be used automatically when needed. New mode “empty” for pad The new mode “empty” pads an array to a desired shape without initializing any new entries. New Deprications in NumPy 1.17.0 numpy.polynomial functions warn when passed float in place of int Previously, functions in numpy.polynomial module used to accept float values. With the latest NumPy version 1.17.0, using float values is deprecated for consistency with the rest of NumPy. In future releases, it will cause a TypeError. Deprecate numpy.distutils.exec_command and temp_file_name The internal use of these functions has been refactored for better alternatives such as replace exec_command with subprocess. Also, replace Popen and temp_file_name <numpy.distutils.exec_command> with tempfile.mkstemp. Writeable flag of C-API wrapped arrays When an array is created from the C-API to wrap a pointer to data, the writeable flag set during creation indicates the read-write nature of the data. In the future releases, it will not be possible to convert the writeable flag to True from python as it is considered dangerous. Other improvements and changes Replacement of the fftpack based fft module by the pocketfft library pocketfft library contains additional modifications compared to fftpack which helps in improving accuracy and performance. If FFT lengths has large prime factors then pocketfft uses Bluestein's algorithm, which maintains O(N log N) run time complexity instead of deteriorating towards O(N*N) for prime lengths. Array comparison assertions include maximum differences Error messages from array comparison tests such as testing.assert_allclos now include “max absolute difference” and “max relative difference” along with previous “mismatch” percentage. This makes it easier to update absolute and relative error tolerances. median and percentile family of functions no longer warn about nan Functions like numpy.median, numpy.percentile, and numpy.quantile are used to emit a RuntimeWarning when encountering a nan. Since these functions return the nan value, the warning is redundant and hence has been removed. timedelta64 % 0 behavior adjusted to return NaT The modulus operation with two np.timedelta64 operands now returns NaT in case of division by zero, rather than returning zero. Though users are happy with NumPy 1.17.0 features, some are upset over the Python version 2.7 being officially dropped. https://twitter.com/antocuni/status/1156236201625624576 For the complete list of updates, head over to NumPy 1.17.0 release notes. Plotly 4.0, popular python data visualization framework, releases with Offline Only, Express first, Displayable anywhere features Python 3.8 new features: the walrus operator, positional-only parameters, and much more Azure DevOps report: How a bug caused ‘sqlite3 for Python’ to go missing from Linux images
Read more
  • 0
  • 0
  • 4842
Visually different images

article-image-kotlin-1-3-60-released-kotlin-worksheets-support-kotlin-native-targets
Sugandha Lahoti
19 Nov 2019
2 min read
Save for later

Kotlin 1.3.60 released with Kotlin Worksheets, support for the new Kotlin/Native targets and other updates

Sugandha Lahoti
19 Nov 2019
2 min read
Kotlin 1.3.60 was released yesterday with new features, as well as quality and tooling improvements. This release adds support for more Kotlin/Native platforms and targets. It also improves the Kotlin/MPP IDE experience. For Kotlin/JS, Kotlin 1.3.60 adds support for source maps and improves the platform test runner integration. The team has also significantly enhanced some “create expect” quick-fixes to the multiplatform side of Kotlin. IntelliJ IDEA and Kotlin Eclipse IDE plugin updates Scratch files are now redesigned and improved to let you see the results, which are shown in a different window. The Kotlin team is working on enhancing the user experience with Kotlin Gradle build scripts. Developers can set function breakpoints in the Kotlin code. The debugger will then stop execution on entering or exiting the corresponding function. Multiple improvements to Java-to-Kotlin converter. The kotlin-eclipse plugin now supports experimentally incremental compilation for single modules. Improvements to Kotlin/Native compiler in Kotlin 1.3.60 The Kotlin/Native compiler has compatibility with the latest tooling bits: XCode 11 and LLVM 8.0. It also adds new platforms/targets such as watchOS, tvOS, and Android (native). Kotlin 1.3.60 adds experimental symbolication of iOS crash reports for release binaries (including LLVM-inlined code, which is one step further than what XCode is able to decode). Thread-safe tracking of Objective-C weak/shared references to Kotlin objects. Support for suspend callable references. The ability to associate a work queue with any context/thread, not just the ones created ad⁠-⁠hoc through Worker.start. The kotlinx.cli project has been (mostly) rewritten and is included in this release of the Kotlin/Native compiler. The runtime performance of Kotlin/Native compiler has also been improved: interface calls are now up to 5x faster, and type checks up to 50x faster in Kotlin 1.3.60. The team has also shared upcoming changes planned for Kotlin 1.4 which is to be released in 2020. Currently, Kotlin 1.4 is available in the experimental state. You can find the complete list of Kotlin 1.3.60 changes in the changelog. Kotlin 1.3.50 released with ‘duration and time Measurement’ API preview, Dukat for npm dependencies, and more. Introducing Coil, an open-source Android image loading library backed by Kotlin Coroutines Microsoft announces .NET Jupyter Notebooks
Read more
  • 0
  • 0
  • 4824

article-image-is-dark-an-aws-lambda-challenger
Fatema Patrawala
01 Aug 2019
4 min read
Save for later

Is Dark an AWS Lambda challenger?

Fatema Patrawala
01 Aug 2019
4 min read
On Monday, the CEO and Co-founder of Dark, Ellen Chisa, announced the project had raised $3.5 million in funding in a Medium post. Dark is a holistic project that includes a programming language (Darklang), an editor and an infrastructure. The value of this, according to Chisa, is simple: "developers can code without thinking about infrastructure, and have near-instant deployment, which we’re calling deployless." Along with Chisa, Dark is led by CTO, Paul Biggar, who is also the founder of CircleCI, the CI/CD pioneering company. The seed funding is led by Cervin Ventures, in participation with Boldstart, Data Collective, Harrison Metal, Xfactor, Backstage, Nextview, Promus, Correlation, 122 West and Yubari. What are the key features of the Dark programming language? One of the most interesting features in Dark is that deployments take a mere 50 milliseconds. Fast. Chisa says that currently the best teams can manage deployments around 5–10 minutes, but many take considerably longer, sometimes hours. But Dark was designed to change this. It's purpose-built, Chisa seems to suggest, for continuous delivery. “In Dark, you’re getting the benefit of your editor knowing how the language works. So you get really great autocomplete, and your infrastructure is set up for you as soon as you’ve written any code because we know exactly what is required.” She says there are three main benefits to Dark’s approach: An automated infrastructure No need to worry about a deployment pipeline ("As soon as you write any piece of backend code in Dark, it is already hosted for you,” she explains.) Tracing capabilities are built into your code. "Because you’re using our infrastructure, you have traces available in your editor as soon as you’ve written any code. There's undoubtedly a clear sense - whatever users think of the end result - that everything has been engineered with an incredibly clear vision. Dark has been deployed on SaaS platform and project tracking tools Chisa highlights how some customers have already shipped entire products on Dark. Chase Olivieri, who built Altitude, a subscription SaaS providing personalized flight deals, using Drark is cited by Chisa, saying that "as a bootstrapper, Dark has allowed me to move fast and build Altitude without having to worry about infrastructure, scaling, or server management." Downside of Dark is programmers have to learn a new language Speaking to TechCrunch, Chisa admitted their was a downside to Dark - you have to learn a new language. "I think the biggest downside of Dark is definitely that you’re learning a new language, and using a different editor when you might be used to something else, but we think you get a lot more benefit out of having the three parts working together." Chisa acknowledged that it will require evangelizing the methodology to programmers, who may be used to employing a particular set of tools to write their programs. But according to her the biggest selling point is that it will remove the complexity around deployment by bringing an integrated level of automation to the process. Is Darklang basically like AWS Lambda? The community on Hacker News compares Dark with AWS Lambda, with many pessimistic about its prospects. In particular they are skeptical about the efficiency gains Chisa describes. "It only sounds maybe 1 step removed from where aws [sic] lambda’s are now," said one user. "You fiddle with the code in the lambda IDE, and submit for deployment. Is this really that much different?” Dark’s Co-founder, Paul Biggar responded to this in the thread. “Dark founder here. Yes, completely agree with this. To a certain extent, Dark is aimed at being what lambda/serverless should have been." He continues by writing: "The thing that frustrates me about Lambda (and really all of AWS) is that we're just dealing with a bit of code and bit of data. Even in 1999 when I had just started coding I could write something that runs every 10 minutes. But now it's super challenging. Why is it so hard to take a request, munge it, send it somewhere, and then respond to it. That should be trivial! (and in Dark, it is)" The team has planned to roll out the product publicly in September. To find out more more about Dark, read the team's blog posts including What is Dark, How Dark is a functional language, and How Dark allows deploys in 50ms. The V programming language is now open source – is it too good to be true? “Why was Rust chosen for Libra?”, US Congressman questions Facebook on Libra security design choices Rust’s original creator, Graydon Hoare on the current state of system programming and safety
Read more
  • 0
  • 0
  • 4733

article-image-introducing-nushell-a-rust-based-shell
Savia Lobo
26 Aug 2019
3 min read
Save for later

Introducing Nushell: A Rust-based shell

Savia Lobo
26 Aug 2019
3 min read
On August 23, Jonathan Turner, an Azure SDK developer introduced a new shell written in Rust, called Nushell or ‘Nu’. This Rust-based shell is inspired by the “classic Unix philosophy of pipelines, the structured data approach of PowerShell, functional programming, systems programming, and more,” Turner writes in his official blog. The idea of Nushell struck when Turner’s friend Yehuda Yatz demonstrated the working of Powershell. Yatz asked Turner if he could join in his project “we could take the ideas of a structured shell and make it more functional (as opposed to object-oriented)? What if, like PowerShell, it worked on Windows, Linux, and macOS? What if it had great error messages?” Turner highlights the fact that “everything in Nu is data”; this means when a user tries other commands and realize that they are using the same commands to filter, to sort, etc. Rather than having the need to remember all the parameters to all the commands, they can just use the same verbs to act over our data, regardless of where the data came from. Nu also understands structured text files like JSON, TOML, YAML, and allows users to manipulate their data, and much more. “You get used to using the verbs, and then you can use them on anything. When you’re ready, you can write it back to disk,” Turner writes. Nu also supports opening and looking at the text and binary data. On opening a source file, users can scroll around in a syntax-highlighted file. Further on opening an xml, they can look at its data. They can even open a binary file and look at what’s inside. Turner mentions that there is a lot one might want to explore with Nushell. Hence, the team has released Nu with the ability to extend it with plugins. Nu will look for these plugins in your path, and load them up on startup. Rust language is the major backbone for this project and Nushell would not have been possible without Rust, Turner exclaims. Nu internally uses async/await, async streams, and employs liberal use of “serde” to manage serializing and deserializing into the common data format and to communicate with plugins. Nushell GitHub page reads, “This project has reached a minimum-viable product level of quality. While contributors dogfood it as their daily driver, it may be instable for some commands. Future releases will work fill out missing features and improve stability. Its design is also subject to change as it matures.” The team will further work towards stability, the ability to use Nu as the main shell, the ability to write functions and scripts in Nu, and much more. Users can also read the book on Nu, available in both English and Spanish language. To know more about this news in detail, head over to Jonathan Turner’s official blog post or visit Nushell’s GitHub page. Announcing ‘async-std’ beta release, an async port of Rust’s standard library Rust 1.37.0 releases with support for profile-guided optimization, built-in cargo vendor, and more Weaponizing PowerShell with Metasploit and how to defend against PowerShell attacks [Tutorial]
Read more
  • 0
  • 0
  • 4719
Unlock access to the largest independent learning library in Tech for FREE!
Get unlimited access to 7500+ expert-authored eBooks and video courses covering every tech area you can think of.
Renews at £15.99/month. Cancel anytime
article-image-python-3-9-alpha-1-is-now-ready-for-testing
Vincy Davis
22 Nov 2019
3 min read
Save for later

Python 3.9 alpha 1 is now ready for testing

Vincy Davis
22 Nov 2019
3 min read
Three days ago, the team behind Python announced the release of Python 3.9.0a1, which is the first out of the six planned alpha releases of Python 3.9. The final stable version of Python 3.9 is slated to release in May 2020. An alpha release indicates that developers can start testing the new features and check for bug fixes but are not recommended to use it in production. Last month, the previous stable version, Python 3.8 was released with features like walrus operator, positional-only parameters support for Vectorcall. Read More: Core Python team confirms sunsetting Python 2 on January 1, 2020 Let’s look at some of the raw features that you can be expected in the upcoming Python 3.9 version. Some improvements introduced in Python 3.9.0a1 Language Changes The __import__() function which is invoked by the import statement will now raise ImportError instead of ValueError. In the previous versions, the latter used to occur when a relative import went past its top-level package. Starting from Python 3.9.0a1, the absolute path of the script filename will be specified on the command line: the __file__ attribute of the __main__ module. The sys.argv[0] and sys.path[0] will become an absolute path rather than a relative path. Also, the traceback will now display the absolute path for __main__ module frames in this case. The encoding and errors arguments in the debug build and development mode will now be checked in the string encoding and decoding operations. Improved Modules ast: It is added in the indent option to dump() and produces a multi-line indented output. asyncio: It can now use coroutine which is a generalized form of subroutines. Subroutines enter and exit at only two different points, while coroutines can be entered, exited, and resumed at many points. Moreover, asyncio.run() is updated to use the new coroutine. New functions like curses.get_escdelay(), curses.set_escdelay(), curses.get_tabsize(), and curses.set_tabsize() and constants F_OFD_GETLK, F_OFD_SETLK and F_OFD_SETLKW is included in Python 3.9.0a1. Few Python users have already started testing the Python 3.9.0a1 release. https://twitter.com/codewithanthony/status/1197559895744110592 The next alpha release for Python 3.9 is scheduled for 16th December 2019. To know more about Python 3.9.0a1, check out the official documentation. Introducing Spleeter, a Tensorflow based python library that extracts voice and sound from any music track Severity issues raised for Python 2 Debian packages for not supporting Python 3 Introducing OpenDrop, an open-source implementation of Apple AirDrop written in Python Poetry, a Python dependency management and packaging tool, releases v1 beta 1 with URL dependency PyPy will continue to support Python 2.7, even as major Python projects migrate to Python 3
Read more
  • 0
  • 0
  • 4682

article-image-github-octoverse-the-top-programming-languages-of-2018
Prasad Ramesh
19 Nov 2018
4 min read
Save for later

GitHub Octoverse: The top programming languages of 2018

Prasad Ramesh
19 Nov 2018
4 min read
After the GitHub Octoverse report last month, GitHub released an analysis of the top programming languages of 2018 on its platforms. There are various ways to rank the popularity of a programming language. In the report published on the GitHub Blog, the number of unique contributors to both public and private repositories tagged with the primary language was used. In addition, the number of repositories tagged with the appropriate primary programming language was also used. JavaScript is the top programming language by repositories The most number of repositories are created in JavaScript. The number of repositories created has a steady rise from 2012. Around this time, GitHub was housing nearly 1 million repositories in total. New JavaScript frameworks like Node.js were launched in 2009. This made it possible for developers to create client and server sides with the same code. Source: GitHub Blog JavaScript also has the most number of contributors JavaScript tops the list for the language having the most number contributors in public and private repositories. This is the case for organizations of every size in all regions of the world. New languages have also been on the rise on GitHub. In 2017, TypeScript entered the top 10 programming languages for all kinds of repositories across all regions. Projects like DefinitelyTyped help in using common JavaScript libraries with TypeScript which encourages its adoption. Some languages have also seen a decline in popularity. Ruby has sunk in the charts over the last couple of years. Even though the number of contributors in Ruby is on the rise, other languages like JavaScript and Python have grown faster. Newer projects not likely to be written in Ruby. This is especially true for projects owned by individual users or small organizations. Such projects are likely written in popular languages like JavaScript, Java, or Python. Source: GitHub Blog Languages by contributors in different regions Across regions, there haven’t been many variations in languages used. Ruby is at the bottom for all regions. TypeScript ranks higher in South America and Africa compared to North America and Europe. The reason could be the developer communities being relatively new in Africa and South America. The repositories in Africa and South America were younger than the repositories in North America and Europe. Fastest growing language by contributors PowerShell is climbing the list. Go also continues to grow across repository type with rank 7. It’s rank is 9 for open source repositories. Statically-typed languages which focus on type safety and interoperability like Kotlin, TypeScript, and Rust are growing quickly. So what makes a programming language popular on GitHub? There are three factors for top programming languages to climb ranks—type safety, interoperability, and being open source. Type safety: There’s a rise in static typing except for Python. This is because of the security and efficiency static typing offers individual developers and teams. The optional static typing in TypeScript adds safety. Kotlin, offers greater interactivity while creating trustworthy, type-safe programs. Interoperability: One of the reasons TypeScript climbed the rankings was due to its ability to coexist and integrate with JavaScript. Rust and Kotlin which are also on the rise, find built-in audiences in C and Java, respectively. Python developers can directly call Python APIs from Swift which displays its versatility and interoperability. Open source: These languages are also open source projects with active commits and changes. Strong communities that contribute, evolve, and create resources for languages can positively impact its life. For more details and charts, visit the GitHub Blog. What we learnt from the GitHub Octoverse 2018 Report Why does the C programming language refuse to die? Julia for machine learning. Will the new language pick up pace?
Read more
  • 0
  • 0
  • 4658

article-image-jdk-11-first-release-candidate-rc-is-out-with-zgc-epsilon-and-more
Bhagyashree R
27 Aug 2018
3 min read
Save for later

JDK 11 First Release Candidate (RC) is out with ZGC, Epsilon and more!

Bhagyashree R
27 Aug 2018
3 min read
On Friday, Oracle released the JDK 11 first Release Candidate. It includes features such as nest-based access control, dynamic class-file constants, improved Aarch64 intrinsics, and more. The general availability of the final release of JDK 11 is scheduled for next month on the 25th. Every six months, in June and December, the community initiates the release cycle for the next JDK feature release. The work proceeds over the next three months in three phases: Rampdown Phase One (RDP 1), Rampdown Phase Two (RDP 2), and Release-Candidate Phase (RC).The durations of the phases for JDK 11 are four weeks for RDP 1, three weeks for RDP 2, and five weeks for RC. What is new in JDK 11 RC 1.0 ? Nest-based access control Nest is introduced to allow classes that are a logically part of the same code entity, but are compiled to distinct class files, access each other’s private members. Dynamic class-file constants To support a new constant-pool form named, CONSTANT_Dynamic, Java class-file format is extended. Loading this pool will delegate creation to a bootstrap method, just as linking an invokedynamic call site delegates linkage to a bootstrap method. Improvements in Aarch64 intrinsics Intrinsics are used to improve performance by leveraging CPU architecture-specific assembly code for a given method, instead of a generic Java code. The existing string and array intrinsics are improved and new intrinsics are implemented for the java.lang.Math package on AArch64 processors: sin (sine trigonometric function) cos (cosine trigonometric function) log (logarithm of a number) Epsilon A new garbage collector named, Epsilon is introduced that handles memory allocation but does not implement any actual memory reclamation mechanism. The JVM will shut down once the available Java heap is exhausted. Java EE and CORBA modules removed These modules are removed from the Java SE Platform and the JDK. Earlier, they were deprecated in the Java SE 9, indicating their removal in a future release. HTTP Client (Standard) The HTTP Client API, introduced as an incubating API in JDK 9 and JDK 10 is standardized. This API received a number of rounds of feedback that resulted in significant improvements. The module name and the package name of the standard API will be java.net.http. Local-variable syntax for lambda parameters When declaring the formal parameters of implicitly typed lambda expressions, the use of ‘var’ is allowed. Now the following expression: (var x, var y) -> x.process(y) is equivalent to: (x, y) -> x.process(y) Unicode 10 The existing platform APIs will support version 10.0 of the Unicode Standard. It is supported in the following classes: In java.lang: Character and String In java.awt.font: NumericShaper In java.text: Bidi, BreakIterator, and Normalizer New Flight Recorder Flight Recorder, a low-overhead data collection framework is provided for troubleshooting Java applications and the HotSpot JVM. Addition of ChaCha20 and Poly1305 cryptographic algorithms An implementation of the ChaCha20 and ChaCha20-Poly1305 ciphers as specified in RFC 7539 are added. ChaCha20 is a relatively new stream cipher that can replace the older, insecure RC4 stream cipher. ZGC (Experimental) The Z Garbage Collector, also known as ZGC, is a scalable low-latency garbage collector. ZGC is a concurrent, single-generation, region-based, NUMA-aware, compacting collector. To know more about these updates and improvements in detail, head over to its official website, OpenJDK. JavaFX 11 to release soon, announces the Gluon team State of OpenJDK: Past, Present and Future with Oracle Mark Reinhold on the evolution of Java platform and OpenJDK  
Read more
  • 0
  • 0
  • 4632

article-image-haskell-is-moving-to-gitlab-due-to-issues-with-phabricator
Prasad Ramesh
03 Dec 2018
3 min read
Save for later

Haskell is moving to GitLab due to issues with Phabricator

Prasad Ramesh
03 Dec 2018
3 min read
The Haskell functional programming language is moving from Phabricator to GitLab. Last Saturday, Haskell Consultant Ben Gamari listed down some details about the move in a mail. It started with a proposal to move to GitLab A few weeks back, Gamari wrote to the Haskell mailing list about moving the Glasgow Haskell Compiler (GHC) development infrastructure to GitLab. The original proposal wasn’t complete enough to be used but did provide a small test instance to experiment on. The staging URL https://gitlab.staging.haskell.org is ready to use. While this is not the final version of the migration, it does have most of the features a user would expect. Trac tickets are fully imported, including attachments Continuous integration (CI) is available via CircleCI The mirrors of all boot libraries are present Users can also login using their GitHub credentials if they choose to Issues in the migration There are also a few issues listed by Gamari that needs to be worked on: Timestamps associated with ticket open and close events aren't accurate Some of the milestone changes have problems on being imported Currently, CircleCI fails when forked Trac Wiki pages aren’t imported as of now Gamari said that the listed issues have either been resolved in the import tool or are in-progress to be resolved. The goal of this staging instance is to let contributors gain experience using GitLab and identify any obstacles in the eventual migration. Developers need to note that any comments, merge requests, or issues created on the temporary instance may not be preserved. The focus is on identifying workflows that will become harder under GitLab and ways to improve on them, pending issues in importing Trac, and areas that do not have documentation. Why the move to GitLab? The did not choose GitHub as stated by Gamari in another mail: “Its feature set is simply insufficient enough to handle the needs of a larger project like GHC”. The move to GitLab is due to a number of reasons. Phacility, the company that owns Phabricator has now closed support to non paying customers As Phalicity now focuses on paying customers, open-source parts used by GHC seem half finished Phabricator tool Harbormaster causing breaking CI Their surveys indicated developers leaning towards Git rather than the PHP tool Arcanist used by Phabricator The final migration will happen in about two weeks and the date mentioned is December 18. For more details, you can follow the Haskell mailing list. What makes functional programming a viable choice for artificial intelligence projects? GitLab open sources its Web IDE in GitLab 10.7 GitLab raises $100 million, Alphabet backs it to surpass Microsoft’s GitHub
Read more
  • 0
  • 0
  • 4589
article-image-matthew-flatts-proposal-to-change-rackets-s-expressions-based-syntax-to-infix-representation-creates-a-stir-in-the-community
Bhagyashree R
09 Aug 2019
4 min read
Save for later

Matthew Flatt’s proposal to change Racket’s s-expressions based syntax to infix representation creates a stir in the community

Bhagyashree R
09 Aug 2019
4 min read
RacketCon 2019 happened last month from July 13 to 14 bringing together the Racket community to discuss ideas and future plans for the Racket programming language. Matthew Flatt, one of the core developers, graced the stage to give his talk: State of Racket. In his talk, he spoke about the growing community, performance improvements, and much more. He also touched upon his recommendation to change the surface syntax of Racket2, which has sparked a lot of discussion in the Racket community. https://www.youtube.com/watch?v=dnz6y5U0tFs&t=390 Later in July, Greg Hendershott, who has contributed Racket projects like Rackjure and Travis-Racket and has driven a lot of community participation, expressed his concern about this change in a blog post. “I’m concerned the change won’t help grow the community; instead hurt it,“ he added. He further shared that he will shift his focus towards working on other programming languages, which implies that he is stepping down as a Racket contributor. Matthew Flatt recommends surface syntax change for removing technical barriers to entry There is no official proposal about this change yet, but Flatt has discussed it a couple of times. According to Flatt’s recommendation, Racket 2’s ‘lispy’ s-expressions should be changed to something which is not a barrier of entry to new users. He suggests to get rid or reduce the use of parentheses and bring infix operators, which means the operator sign will be written in between the operands, for instance, a + b.  “More significantly, parentheses are certainly an obstacle for some potential users of Racket. Given the fact of that obstacle, it's my opinion that we should try to remove or reduce the obstacle,“ Flatt writes in a mailing list. Racket is a general-purpose, multi-paradigm programming language based on the Scheme dialect of Lisp. It is also an ecosystem for language-oriented programming. Flatt further explained his rationale behind suggesting this change that the current syntax is not only a hindrance to potential users of Racket as a programming language but also to those who want to use it as “a programming-language programming language”. He adds, “The idea of language-oriented programming (LOP) doesn't apply only to languages with parentheses, and we need to demonstrate that.” With this change, he hopes to make Racket2 more familiar and easier-to-accept for users outside the Racket community. Some Racket developers believe changing s-expressions based syntax is not “desirable” Many developers in the Racket community share a similar sentiment as Greg Hendershott. A user on Hacker News added, “Getting rid of s expressions without it being part of a more cohesive improvement (like better supporting a new type system or something) just for mainstream appeal seems like an odd choice to me.” Another user added, “A syntax without s-expressions is not an innovative feature. For me, it's not even desirable, not at all. When I'm using non-Lispy languages like Rust, Ada, Nim, and currently a lot of Go, that's despite their annoying syntactic idiosyncrasies. All of those quirky little curly braces and special symbols to save a few keystrokes. I'd much prefer if all of these languages used s-expressions. That syntax is so simple that it makes you focus on the semantics.” While others are more neutral about this suggested change. “To me, Flatt's proposal for Racket2 smells more like adding tools to better facilitate infix languages than deprecating S-expressions. Given Racket's pedagogical mission, it looks more like a move toward migrating the HtDP series of languages (Beginning Student, Intermediate Student, Intermediate Student with Lambda, and Advanced Student) to infix syntax than anything else. Not really the end of the world or a big change to the larger Racket community. Just another extension of an ecosystem that remains s-expression based despite Algol and Datalog shipping in the box,” a user expressed his opinion. To know more about this change, check out the discussion on Racket’s mailing list. Also, you can share your solutions on Racket2 RFCs. Racket 7.3 releases with improved Racket-on-Chez, refactored IO system, and more Racket 7.2, a descendant of Scheme and Lisp, is now out! Racket v7.0 is out with overhauled internals, updates to DrRacket, TypedRacket among others
Read more
  • 0
  • 0
  • 4587

article-image-dart-2-2-is-out-with-support-for-set-literals-and-more
Savia Lobo
27 Feb 2019
2 min read
Save for later

Dart 2.2 is out with support for set literals and more!

Savia Lobo
27 Feb 2019
2 min read
Michael Thomsen, the Project Manager for Dart announced the stable release of the general purpose programming language, Dart 2.2. This version, which is an incremental update to v2, offers improved performance of ahead-of-time (AOT) compiled native code and a new set literal language feature. Improvements in Dart 2.2 Improved AOT performance Developers have worked on improving the AOT performance by 11–16% on microbenchmarks (at the cost of a ~1% increase in code size). Prior to this optimization, developers had to make several lookups to an object pool to determine the destination address. However, the optimized AOT code is now able to call the destination directly using a PC-relative call. Extended Literals to support sets Dart supported the literal syntax only for Lists and Maps, which caused difficulties in initializing Sets as it had to be initialized via a list as follows: Set<String> currencies = Set.of(['EUR', 'USD', 'JPY']); This code proved to be inefficient due to the lack of literal support and also made currencies a compile-time constant. With Dart 2.2’s extension of literals to support sets, users can initialize a set and make it const using a convenient new syntax: const Set<String> currencies = {'EUR', 'USD', 'JPY'}; Updated Dart language Specification Dart 2.2 includes the up-to-date ‘Dart language specification’ with the spec source moved to a new language repository. Developers have also added continuous integration to ensure a rolling draft specification is generated in PDF format as and when the specification for future versions of the Dart language evolves. Both the 2.2 version and rolling Dart 2.x specifications are available on the Dart specification page. To know more about this announcement in detail, visit Michael Thomsen’s blog on Medium. Google Dart 2.1 released with improved performance and usability Google’s Dart hits version 2.0 with major changes for developers Is Dart programming dead already?  
Read more
  • 0
  • 0
  • 4583

article-image-golang-1-11-rc1-is-here-with-experimental-port-for-webassembly
Natasha Mathur
17 Aug 2018
3 min read
Save for later

Golang 1.11 rc1 is here with experimental port for WebAssembly!

Natasha Mathur
17 Aug 2018
3 min read
Golang team released Golang 1.11 rc1 version, earlier this week. The latest release explores features like web assembly (js/wasm ), preliminary support for modules and improved support for debuggers among others. Golang is currently one of the fastest growing programming languages in the software industry. Golang’s easy syntax, concurrency, and fast nature are few of the reasons for its popularity. It is a modern programming language, created by Google back in 2009 for the 21st-century application development. Let’s have a look at the key features that come with Golang 1.11 rc1. WebAssembly ( js/wasm) WebAssembly is different in the sense that it is not processed by a CPU directly, but instead, it is an intermediate representation which is compiled to actual machine code by the WebAssembly runtime environment. Now, Go 1.11 rc1 has added an experimental port to WebAssembly (js/wasm). Go programs used to compile to only one WebAssembly module. These modules include the Go runtime for goroutine scheduling, garbage collection, maps, etc. Because of this, the resulting size would be around 2 MB, or 500 KB compressed. Go programs can call into JavaScript with the help of new experimental syscall/js package. Now, with new GOOS value "js" and GOARCH value "wasm" added to the web assembly, Go files named *_js.go or *_wasm.go will now be ignored by Go tools except for cases when GOOS/GOARCH values are being used. The GOARCH name "wasm" is the official abbreviation of WebAssembly. The GOOS name "js" is due to the host environment that executes WebAssembly bytecode are web browsers and Node.js, both of which use JavaScript to embed WebAssembly. Preliminary support for modules Go 1.11 rc1 offers preliminary support for a new concept called “modules,” which is an alternative to GOPATH with integrated support for versioning and package distribution. With modules, developers are not limited to working inside GOPATH. Also, the version dependency information is explicit yet lightweight, and builds are more reliable. Improved support for debuggers The compiler in Go 1.11 rc1 now produces significantly accurate debug information for optimized binaries. This includes variable location information, line numbers, and breakpoint locations. Due to this, it is easier to debug binaries compiled without -N -l. There are still few limitations to the quality of the debug information which will improve with the future releases. DWARF sections have been compressed by default. This is due to the accurate debug information produced by the compiler. This is transparent to most ELF tools (like debuggers on Linux and *BSD) and is supported by the Delve debugger on all platforms.   Other changes Many direct system calls have been removed from the macOS runtime. Go 1.11 binaries are now less likely to break on upgrading macOS version because system calls are made through the proper channel (libc). Go 1.11 is expected to be released later this month. For more information, check out the official release notes. Writing test functions in Golang [Tutorial] How Concurrency and Parallelism works in Golang [Tutorial] GoMobile: GoLang’s Foray into the Mobile World
Read more
  • 0
  • 0
  • 4497
article-image-wanna-be-rockstar-developer
Aaron Lazar
27 Jul 2018
5 min read
Save for later

Hey hey, I wanna be a Rockstar (Developer)

Aaron Lazar
27 Jul 2018
5 min read
New programming languages keep popping up every now and then, but here’s something that’s out of the box - jukebox to be precise! If you’ve ever dressed up (or at least thought of it) in leather tights, a leather jacket, with an axe strung around your neck, belting out your favourite numbers, you’re probably going to love this! Somebody...no not Nickelback, created a language that is designed for creating computer programs using song lyrics! The language is called...hold your breath...Rockstar! Say, what?? Are you kidding me? Is this some kind of joke/’fake news’? No, it’s not. It’s as real as Kurt writing those songs she sang in Hole! ;) Rockstar is heavily influenced by the lyrical conventions of 1980’s hard rock and power ballads. And the somebody who created it is Dylan Beattie, a Microsoft MVP for Visual Studio and Development Technologies. Unsurprisingly, Dylan’s a musician himself. Rockstar is already growing in popularity! Will you take a look at the growth on Github and the discussions going on on Reddit? You ask why would Dylan do such a thing? Cos, as Van Halen would say, “Everybody Wants Some”! Well, he thought it would be cool to have such a language, where you can use your favourite lyrics to drive your computer and HR recruiters nuts! It’s mainly part of a movement to force recruiters from using the term, “Rockstar Programmers”. Did I say movement? Rockstar supports a unique feature known as poetic literals, which allow programmers to simultaneously initialize a variable and express their innermost angst. I’m sure Billie Joe Armstrong and Axl Rose will surely appreciate this! This is what sample Rockstar code looks like, solving the fizzbuzz problem: Let’s start with the minimalistic version: Modulus takes Number and Divisor While Number is as high as Divisor Put Number minus Divisor into Number (blank line ending While block) Give back Number (blank line ending function declaration) Limit is 100 Counter is 0 Fizz is 3 Buzz is 5 Until Counter is Limit Build Counter up If Modulus taking Counter, Fizz is 0 and Modulus taking Counter, Buzz is 0 Say "FizzBuzz!" Continue (blank line ending 'If' Block) If Modulus taking Counter and Fizz is 0 Say "Fizz!" Continue (blank line ending 'If' Block) If Modulus taking Counter and Buzz is 0 Say "Buzz!" Continue (blank line ending 'If' Block) Say Counter (EOL ending Until block) And now, the same thing in idiomatic Rockstar code: Midnight takes your heart and your soul While your heart is as high as your soul Put your heart without your soul into your heart Give back your heart Desire is a lovestruck ladykiller My world is nothing Fire is ice Hate is water Until my world is Desire, Build my world up If Midnight taking my world, Fire is nothing and Midnight taking my world, Hate is nothing Shout "FizzBuzz!" Take it to the top If Midnight taking my world, Fire is nothing Shout "Fizz!" Take it to the top If Midnight taking my world, Hate is nothing Say "Buzz!" Take it to the top Whisper my world Oh yeah, did I mention that Rockstar doesn’t care two hoots about indentation. Also, it discourages the use of comments. Why? Cos this is Rock ‘n’ Roll, baby! Let whoever wants to know the meaning, discover it on their own! Now that’s hardcore! To declare a variable in Rockstar, you simply use a common word like "a, an, the, my or your" as a preface and any unique name (e.g. "Suzanne"). For types, you can use words like "mysterious", meaning no value is assigned, or "nothing/ nowhere/nobody", for null. You could name your variable “em” so to increment it, you’d use "build em up" and to decrement it, you’d use "knock em down". Now if that’s not cool, you tell me what is! Like in Ruby or Python, variables are dynamically typed and you don't need to declare them before use. That’s not all! For I/O, you’re at the liberty of using words like "listen to" or "shout," "whisper" or "scream". Someone actually happened to test out the error handling capabilities of Rockstar, a couple of days ago: If you accidentally typed “!love” as a property, it will return “you give !love a bad name”. I wonder what it would do, if we just typed in the lyrics to Sweet Child o’ Mine. Nevertheless, the Github (Shooting) Stars are growing like a weed (pun intended) ;) I suggest you Don’t Stop Believin’ in it and go check this language out! And don’t forget to tell us in the comments, about how it Rock(ed) You Like a Hurricane or better yet, Shook Me You All Night Long! ;) Will Rust Replace C++? Why Guido van Rossum quit as the Python chief (BDFL) Apollo 11 source code: A small step for a woman, and a huge leap for ‘software engineering’
Read more
  • 0
  • 0
  • 4492

article-image-exciting-new-features-in-c-8-0
Richa Tripathi
12 Apr 2018
3 min read
Save for later

Exciting New Features in C# 8.0

Richa Tripathi
12 Apr 2018
3 min read
It’s been more than 20 years since Microsoft released the first version of the C# language. Over the years C# has experienced a remarkable evolution, from being called as a Java copycat to one of the most loved and used programming languages. The current developments in C# 7 ecosystem are exciting, and grabbing the attention of developers, but what about the future? Can developers take a sneak peek into the future of C#? Well of course they can! The Microsoft language design team have been developing the language features ‘in the open’ for quite some time now. They have proposed several new features for the upcoming C# 8.0 and have released several prototypes for the developers, to try them out and provide feedback on the official Github repo. Let’s take a look at the most likely new C# 8 features: Nullable Reference Types The name of this particular feature might confuse a lot of developers wondering “Isn’t nullable reference a bad idea?” or “Shouldn’t it be called non nullable reference types?”. Sir Tony Hoare, a British computer scientist invented null references and famously called them the “Billion Dollar Mistake” as the biggest problem is, of course, the risk of getting the infamous null-reference exception. Since all reference types in C# can be null, you always run the risk of getting an exception when you try to access some member of the object. Functional languages try to deal with this problem by having a type that represents the concept of potential absent value. Instead of introducing non-nullable reference types in C#, Microsoft has chosen to consider reference types as non-nullable by default and provide mechanisms to deal with nullable types. Since the premise of a reference is often considered to be non-nullable and to be dereferenced. Asynchronous Streams Asynchronous streams provide the ability to use async/await inside an iterator. In most cases, an iterator is implemented synchronously. There are some cases, however, where it might need to await a call on every iteration to fetch the next item. In such cases, asynchronous streams can come in handy. To support this feature, a couple of things need to be taken care of: New types, the async equivalents of IEnumerable and IEnumerator Ability to specify an await on an iterator construct such as foreach. Default interface implementations: The primary use case for default interface methods is to enable the developer to safely evolve an interface. You could add new methods to it and, as long as you provide a default implementation, existing clients of the interface wouldn’t be forced to implement it. Another important value proposition of default implementation on interfaces relates to Android and iOS. Since both Java and Swift offer this feature, it’s tricky to use C# to wrap Android/iOS APIs that make use of default interface implementations. C# 8.0 will make it possible to wrap those APIs more faithfully. There are plenty of other features proposed to be implemented in C# 8 such as target-typed new expressions, covariant return types, and extension everything. All these features are in different stages of development and a lot can (and probably will) change from now until C# 8.0’s release Till then you can closely follow the official Github repo for C#.   Stay up to date with the latest features, release dates, and general discussions on key programming tools and tech by subscribing to Packt Hub. Check out other latest news: Red Programming Language for Android development! What’s new in Visual Studio 1.22 OpenCV 4.0 is on schedule for July release
Read more
  • 0
  • 0
  • 4448