This release enables quite a lot of new things to appear in
const fn, two new standard library APIs, and one feature useful for library authors. See the detailed release notes to learn about other changes not covered by this post.
Well, not much for me to add.
I really want to like Rust, but that syntax. 😐
Flatland_Spider,
Same.
I really want to like d-lang (love the syntax), but that garbage collection…
If we had something in between, it would be my favorite.
GC is what turned me off from Dlang as well. “It’s C++ with GC!” :\
Also, FreeBSD and OpenBSD not being as well supported as Linux. I can get behind a niche language, but one of the BSDs needs to be tier 1 platforms.
I’ve pretty much settled on Go/Golang for right now. It basically lets me write C style code, and it does what I need it to do, which is mostly power network services.
There are several other languages I’d like to explore when I have time: Crystal, Zig, Ocaml, LISP, Swift, and Elixir.
Flatland_Spider,
To be fair, it’s much better than C++ if we can overlook the GC. They’ve cleaned up the mess with include files, templates, forward declarations, etc. I’m very impressed. Even the GC wouldn’t be bad where it’s appropriate, but it’s just a shame they didn’t cater to systems programming where GC is undesirable.
Rust is awesome at providing robust code integrity checks at compile time and they even provide some integrity checks for multithreaded race conditions, which are notoriously hard in conventional languages. I still prefer the C syntax, but rust has so much technical merit that I think every CS student should learn it. While C will remain unavoidable in the real world for decades to come, at least most of that will be a legacy relic in a couple hundred years, haha.
I preferred dlang myself. Personally I never thought it was a good idea to make the language syntax depend on letter case. Granted, I write in the latin alphabet, but I think it was a dumb decision for a language to rely on case sensitivity which is actually kind of difficult with utf8.
I’m at the point where I have trouble learning more languages because I’m already using too many, haha.
D looks really cool. A better C++ with a cleaner syntax is something I can get behind. I seriously looked at it for writing clients since it has generics, and I’m still looking for the perfect compiled language for client applications.
By virtue of being GC’ed and limited OS support, it didn’t provide anything over Go which I’m already spooled up on, and I decided I would deal with structs. If they had picked RIAA to be the memory management, like C++, it would have been a harder decision to move on. Limited OS supported would have sunk it anyway, but the decision would have been harder to make.
Are you talking about make functions and structs public or private based on the case of the first character in the name?
It’s kind of weird initially, but it works well enough in practice. I would say that’s not as objectionable as whitespace being significant, and this from someone who uses and likes Python.
Go itself is basically a giant web/network service framework, and that alone makes it awesome for what I need it for. 🙂
It’s mostly tinkering. 🙂 I get bored doing the same thing repetitively, so trying a new language is fun.
The other part is I’m looking for a really good client language. Elixir would be more of a server side language, so it would be more of an alternative to Go in services. LISP is just for fun. It’s such a weird paradigm that I’m not sure how to best use it.
Crystal is compiled and GC’ed :\ with a Ruby-like syntax. I need to see how it handles CLI options and arguments as well as if it would translate JSON into something usable without too much of a performance hit or boilerplate. It checks most the needed OS platforms: macOS, Linux (RHEL/CentOS, Fedora), FreeBSD. OpenBSD is a work in progress.
Zig purportedly aims to be a modern version of C, which would be great. It checks most the needed OS platforms: macOS, Linux (RHEL/CentOS, Fedora), FreeBSD. OpenBSD is a work in progress.
Swift is probably my biggest hope for a good client side language. Everything I’ve seen seems to indicate it could be the one. FreeBSD and/or OpenBSD support still needs to happen though.
Ocaml has good support for all of the needed platforms, and I’m trying to find a functional language I really like. Ocaml is one of the few functional languages which doesn’t depend the JVM, and it’s also compiled. Those reasons automatically get it included. 🙂
I have rather different views on these topics:
– Syntax, to me, is one of the least important aspect of a programming language. It can make a language more or less pleasant to use but it is essentially in the same category as compilation speed, error reporting, presence of REPL etc.
– D-lang, Rust, C++, Java, Python etc are all pretty much equivalent in the way they make a programmer express ideas. Of course, applications and environments are vastly different, so it is still worth learning a few of them for practical reasons. But as far as differences go, using a regexp or sql library is a bigger cognitive jump than switching from C++ to Python.
– I love GC everywhere except low-level languages. Without a built-in/standard GC there is no way to pass complex data structures between libraries, so we either dumb down all interfaces to primitive data types (=low level language) or we end up with leaks and tons of conventions for reclaiming memory.
ndrw,
I appreciate that it’s subjective. I am able to learn new syntax, but I gravitate towards C & javascript like syntax over pascal, basic, or the like when I have a choice. The strange thing is that I learned to program in basic and pascal, so at least for me it wasn’t a case of sticking to simply sticking to what I know. So I agree syntax is not a huge issue, but it’s enough to make me prefer dlang.
Compilation speed and quality of errors can are often worse than other languages especially when it comes to templates/generics. These are far more objective than syntax, which is subjective, so I don’t feel they belong in the same category.
We can consider assembly, I’ve gotten used to intel syntax for assembly and I’m quite frustrated by at&t. Obviously it represents the exact same idea, but one syntax is preferable to me and I would expect more people to have a preference (whether it’s the same as mine or not).
Obviously you are right that switching syntax isn’t as big a shock as new libraries. The syntax can pose challenges for a week or so, but the different libraries can pose a challenge for a very long time. For example, I’ve been using PHP for 2 decades-ish., but I still have to refer to the documentation. It’s not so much that it’s difficult to understand, it’s actually fairly easy, but the language is highly inconsistent and all the frameworks kind of get mixed together. In this respect, learning more languages can actually lead to more confusion.
I think many developers agree. I don’t have a problem with GC where it’s appropriate, however I’ve also found that sometimes programmers who are accustomed to GC tend to abuse it and the result is less efficient code.
I think many developers agree. I don’t have a problem with GC where it’s appropriate, however I’ve also found that sometimes programmers who are accustomed to GC tend to abuse it and the result is less efficient code.
As it often happens, it is about the difference between use and abuse. Java standard library, which got GC a bad name, is a good example. It was designed in times when more OOP was seen as a solution to all problems (including ones caused by too much OOP). Combine it with a relatively poor implementation, VM and the fact that machines back then performed like today’s embedded systems and we have a recipe for performance issues. By all means, if memory size is a factor, use C and stick to primitive data types.
What I don’t like is languages like C++ that promise high level features and don’t deliver on it. In C++, in general case, we should never create any objects or allocated structures with a lifetime exceeding a scope of a function/method. This means no passing objects to other functions at all because once we do it, all control over the object life cycle is lost and we have a leak. Of course, that’s not what we do – we create such objects, “carefully” pass their references around and trust someone will be able to clean them up. It works but it is a terrible programming model – we could just as well use goto for our function calls.
A less pleasant syntax is less pleasant, and that’s kind of my point. Syntax can create friction and produce negative reinforcement. I’m the one typing this code out, and I spend a lot of time typing out code. I’d like to enjoy how I spend my time.
For example, I don’t work with Windows because I find it unpleasant. I find Unix-like operating systems pleasant, so I spend my time working with them.
Another example, Perl arrays. Creating an array isn’t bad
my @things = ("lamp", "desk", "pencil", "paper pad");, but accessing elements is weirdprint $things[0];. It’s little things like that.I thought everything with regex tries to be Perl compatible these days.
As for the jump between C++ and Python, I think that depends on which way the person is going. 🙂
It’s worth nothing automatic memory management in a language isn’t a bad thing, but GC is usually associated with specific techniques which can have some really nasty side effects.
In my case, it happens to be I already have a GC’ed language I’m familiar with, a couple really (Go, Python), and I’m looking to complement them with something that has memory management without a GC, or has a GC which is suitable for lower-level environments.
Sometimes, we need something that isn’t GC’d, but we’d like modern conveniences. Usually “modern conveniences” means a GC, but it doesn’t have to, which is the appeal of Rust.
@ndrw, Nice summary, I’m in agreement with all your observations.
Although with my IoT hat on I think REPL is very useful, in IoT you have to support some many MCU architectures you do not want to manage all the build and program variants, so REPL is invaluable.
I’d like to see portability updates in a future release. Something like “you can now use the system LLVM and not build a custom, modified version in source”. That would really help considering how hard it is for a small OS to get patched upstreamed to LLVM. Then we don’t have to port 2 versions just to get rust to run.
If it’s going to take over C, it has to be portable like C. Basic rule guys.
Patches upstream for OS’s shouldn’t be that difficult for LLVM/Clang. There are a handful of non-mainstream OS’s with support. For C to work you still have to have a C compiler ported. That still involves patches.
If I remember, they are some architectures that the LLVM project doesn’t plan to support. That’s why there is some projects for writing a Rust front-end for the GCC suite, and also mrust (https://github.com/thepowersgang/mrustc) a Rust-to-C compiler targeting embedded systems (where C is often the only compiler available)