Rust 1.0 Enters Beta

An anonymous reader writes: Rust is a systems programming language focused on safety and speed and aims, among other things, to offer memory safety without garbage collection and threads without data races. Over on the Rust blog, the Rust Core Team has announced the release of Rust 1.0 beta. They write, 'The beta release marks a very significant "state transition" in the move towards 1.0. In particular, with the beta release, all libraries and language features that are planned to be stable for 1.0 have been marked as stable. As such, the beta release represents an accurate preview of what Rust 1.0 will include.' The final Rust 1.0 release is scheduled for May 15th, 2015. A warning from the developers: "Rust is a work-in-progress and may do anything it likes up to and including eating your laundry." The FAQ is worth reading.

Comments

Likely interesting

[umafuckit]

When Rust becomes a little more polished it will likely become very interesting.

Re:Likely interesting

[Anonymous Coward]

It's been in development for years. 1.0.0 means it is polished now, at least on the level of the language.

Re:Likely interesting

[smittyoneeach]

Until we get to "Rust 2 Enterprise Edition", it's all just so much talk.

Re:Likely interesting

[Anonymous Coward]

It's kind of sad how many people completely missed the joke here.

Give the ecosystem a few days to catch up

[drewm19801927]

Now is a good time to play around with Rust and explore the language features! If you build against the beta release and don't add external package dependencies, your code will most likely continue to function for the duration of the 1.0 release cycle. However, now is probably a particularly ~bad time for new rust users to start a project and add a bunch of dependencies from Cargo/crates.io. Beta changed code dependencies on unstable features from warnings to errors, so a lot of common libraries in the ecosystem are broken at the moment, and will take a little while to get updated. Happy hacking!

Ada

[Elledan]

Is there any reason why anyone would want to use Rust when they're already proficient in both C++ and Ada?

You'd think that Ada is already covering most if not everything what Rust is trying to cover here, especially the memory safety and concurrency aspects.

Re:Ada

[Anonymous Coward]

Well, its always good to have exploration so for me Rust is a good thing. Yea, it may not take the World by storm but may bring some new ideals to the table.

Re:Ada

[Anonymous Coward]

C++ and Ada are geezer languages for unemployable old dinosaurs. Rust is hipster hotness, bitch. You know it or you don't get paid. Ever again.

Re:Ada

[angel'o'sphere]

Simpler syntax, less code to write (less verbose)?

Re: Ada

[Anonymous Coward]

test test

Re: Ada

[Anonymous Coward]

nsa and jcs hate memory safe languages. too few exploitable bugs. c++ will enjoy a long life because of this

Re:Ada

[Celarent Darii]

No. Ada already has a very basic syntax, which if you look at the Ada example is so much like Rust that really I fail to see any significant difference. Ada is also completely buzz-word compliant. It has also been used to make real projects, and even has a ANSI Standard since 1983. Rust can't even guarantee a feature set, nor even a stable keyword set.

Wish them luck, but frankly it's a bit like reinventing the wheel. I guess it's what hipsters do when they skip CS 102 in order to 'find themselves' - try to 'reinvent' what they should have learned in college.

Re: Ada

[Anonymous Coward]

Ada is a royal pain to use in the industries it is used in. It works sort of fine for projects developed by a single entity. However, this never happens where Ada is actually used.

For example, in a real project I worked on. I had to integrate the components from a subcontractor. They had defined their own fixed width int types, which incidentally, also had been done by our people as well. The different types which where the same where incompatible. In the end we had to produce a wrapper lib which took care of exposing the subcontractor APIs converting UINT32 to UNSIGNED32 and back.

Re:Ada

[jones_supa]

C++ and Ada are geezer languages for unemployable old dinosaurs. Rust is hipster hotness, bitch. You know it or you don't get paid. Ever again.

Are there actually Rust jobs already?

Re:Ada

[Electricity Likes Me]

Complaining about other people's open source projects seems to be what Slashdot posters do in order to make themselves feel important.

Re: Ada

[Anonymous Coward]

That was actually recommended by the book I read about Ada, said it provided better portability. hmph, I better finish that book to see if it mentioned this problem.

Re:Ada

[tgv]

Yes, but you'll need 5 to 10 years of Rust experience. In a lead role.

Re:Ada

[Milharis]

I think the most significant difference is that Rust is much closer to a functional language than to something like C.
They just don't want to market it as a functional language because their targets are mostly C programmers, and most of those would never accept one.
Look at the main features: (almost) everything is an expression, pattern matching, type inference, actor-based concurrency, higher-order functions and closures, that's the kind of things you mostly find in functional languages.

Is Rust going to fix everything? Of course not. Is it going to succeed in the long term? No one knows.
But it is certainly interesting.

Re: Ada

[Anonymous Coward]

Your anecdote certainly doesn't point out any flaw of Ada, the whole story sounds like a management or software architecture problem.

Re:Ada

[Anonymous Coward]

C programmers have a language with tons of functional stuff they could use if they wanted. It's called c++ and, unlike rust:

1) It's fairly stable
2) Their code works
3) It's standardized
4) It's proven

Re:Ada

[drewm19801927]

Wow, Ada code looks nothing like Rust code to me. Ada looks like a mix of BASIC and python. I don't know Ada, but Rust supposedly makes stronger guarantees of memory correctness for parallel code. Rust just went beta yesterday; breaking changes up to now were to be expected. Once there are more people with real-world experience with both Ada and Rust, I'll be very interested in reading about their experiences. Maybe you haven't been following it closely, but Rust is not some one-developer toy scripting language. A team of brilliant engineers has been working on it full-time at Mozilla for years.

Re:Ada

[Anonymous Coward]

Only at Google, or whoever owns Mozilla nowadays.

Re: Ada

[Anonymous Coward]

Yes. If It was possible to force compatible APIs and types through central management. It would have been a fairly useful language. However those management issues are pervasive in the industries where Ada is and was supposed to be used.
Basically, the design of the language has not taken into account the organisational structures of the industry where it is used. You may call this a management issue and ignore the problem. I tend to call it reality instead.

Re: Ada

[Anonymous Coward]

Checked my favorite ADA book and it sounds like the person didn't know ADA well, or the projects had major architectural problems.. an hour of reading and it seems like they should have at least used generics, or something along those lines. At the very least it looks like they could have just redefined one of the types to show it's compatible with the other and could have been used interchangeably without problems.

Re:Ada

[Anonymous Coward]

Wish them luck, but frankly it's a bit like reinventing the wheel. I guess it's what hipsters do when they skip CS 102 in order to 'find themselves' - try to 'reinvent' what they should have learned in college.

If the only point of "college" for you was "learning to be submissive" then you failed, degree or no degree.

Also, for the record, "college" is where "hipsters" hangout to get their "international" (communist) educations.

Likewise, the idea "college" is only for workforce training is what "hipsters" think.

Therefore, you are 100% full of shit. QED.

All you are saying is "I don't like competition" and "why can't everyone mooch off of the taxpayer like I do?"

Re: Ada

[Anonymous Coward]

even though you point out valid things, maybe you should not expand discussion too much

Re:Ada

[amorsen]

It would be unusual if Rust was marketed as a functional language, because AFAIK no functional language exists without garbage collection today.

Re:Ada

[Nubbywubwub]

Does Ada do compile-time lifetime checking? The hype about Rust is only because it can prove that programs are memory-safe at compile time without any kind of runtime overhead, which as far as I know is only possible in Ada if you either use garbage collection or if you forbid dynamic memory allocation entirely. Also, is it possible for Ada to expose a C interface such that I can write a reusable library in Ada and call it from Python, Java, C++, etc without requiring me to start an Ada runtime? This is another thing that's exciting about Rust.

Re:Ada

[Anonymous Coward]

Ada looks like a mix of BASIC and python

It looks more like Pascal. Ada was based on and an extension of Pascal. I don't know Ada either, but from my quick reading it looks like Ada and modern Object Pascal have a similar feature set.

Re:Ada

[Anonymous Coward]

Ya, just like those morons who went and developed C. COBOL already had a 15 year history of greatness behind it and is still running all the critical stuff. buncha newbs.

Re:Ada

[angel'o'sphere]

Sorry, there is no real relation between Adas and Rusts syntax, no idea which idiots modded you to +5.

Re:Ada

[HiThere]

Well, unicode handling is a *bit* easier in Rust. Unfortunately the general character class seems to be available only as an experimental feature, and the library B+Tree doesn't persist to a file. So it's clearly got some drawbacks. (OTOH, C++'s handling of unicode is pathetic. Vala is better, but it seems dependent on the Gnome libraries, which means it's probably untrustworthy.)

That said, handling variable length strings and heap allocation in Ada is really painful. (Yes, I know about unbounded-etc. But all literal strings are a different type.) And Ada's memory management is only slightly better than C++'s. You *can* do it in either, but in both it begs for an error to occur (though Ada will often catch the error).
This is too bad, because I really like much of the Ada type system.

Re:Ada

[roca]

Rust offers manual memory management with automatic safety checking --- the language guarantees you don't leak memory, and you can't access an object after it's freed (assuming you don't opt into unsafe code). No other mainstream language, including Ada, offers that.

What's a "compiler" ?

[Anonymous Coward]

Is this Rust thing another web framework? Should I assert 5 years experience with Rust on my CV?

Re:What's a "compiler" ?

[gweihir]

Not quite, but close enough methinks.

(Yes, I do detect the irony, but it is reality that is ironic here...)

Re:What's a "compiler" ?

[Anonymous Coward]

what does this have to do with sega cd?

"without garbage collection"

[Anonymous Coward]

This is a good feature now? Fragmented memory is desirable?

Re:"without garbage collection"

[Anonymous Coward]

Garbage collection uses up cycles.

Re:"without garbage collection"

[BasilBrush]

You must be a Java programmer. Garbage collection is generally a very bad idea for a systems language, because of the periodic stalls whilst it does the cleanup. Especially if it's shunting blocks around memory to defragment. It's one of the big reasons why Android underperforms iOS, why it's never been so smooth in operation. And the only thing a developer can do about it is switch to a different language or develop for a more powerful machine.

Memory fragmentation can be a problem - but the success of C and C++ in most domains over the decades has shown it's just one more aspect a programmer has to deal with, it's not a showstopper. It's fixable, on the same machine, with the same language.

Re: "without garbage collection"

[Anonymous Coward]

This is why garbage collection was removed from ios. It's impossible to get smooth scrolling when the garbage collector kicks in. Apple told its developers to suck it up and write better code, and they did.

Re:"without garbage collection"

[gweihir]

For some applications, it does not matter much. If you need high-performance, you need to do your own memory management anyways. In the space in-between, Rust will have a problem.

Re: "without garbage collection"

[Anonymous Coward]

most importantly, automatic gc is killing realtime ergonomics

Re:"without garbage collection"

[Anonymous Coward]

yep! that's the solution! just like i do on my calculator MEM DROP every other keystroke to keep it snappy!

Re:"without garbage collection"

[gTsiros]

"It's one of the big reasons why Android underperforms iOS, why it's never been so smooth in operation."

no, there is only one reason: shitty coding.

Re:"without garbage collection"

[Anonymous Coward]

So every graphical Java app ever created is "shit code." That certainly must say something about the language and its implementations.

Re:"without garbage collection"

[Anonymous Coward]

yeah, but that's just it. What would you prefer? Shitty coding in a C++ or like language that can cause security nightmares? Or Java which may slow down the computer once in a while? Or Swift that's the effin best... combining pascal and objective-C like no other... wait, like ADA... mofo, we gots to get our own rust

Re:"without garbage collection"

[Anonymous Coward]

garbage collection is also not energy efficient.... you basically have something always running in the background looking at things twice to see if it is ready to be discarded.... makes it easier to write bad code (cylindrical references) and not pay for it, but it is not the best solution.

Re:"without garbage collection"

[Anonymous Coward]

All a developer needs to do to avoid "stalls" is to collect garbage on a regular schedule and when a program expects to be idle.

You are definitely a Java developer. So clueless about the real world - a definitive symptom.

1. How do you *ever* identify the time "when a program expects to be idle"?

2. How do you ever get program to be idle when there is a work to do?

3. The most common case when GC is triggered, is when application tries to allocate memory, but finds none free. Or you do not use the dynamic memory?

You would know this if you had actual programming experience.

Yep. Definitely a Java user. No other developers were ever so clueless about inner working of their language or the environment program works in since the times of the BASIC popularity.

Re: "without garbage collection"

[Anonymous Coward]

wow, a dangerous amount of excellence in the deluge of java mediocrity.

Re: "without garbage collection"

[Anonymous Coward]

we agree that neither c++ nor java is up to the job. thank you.

Re: "without garbage collection"

[Anonymous Coward]

more fud. you can control memory allocation and deallocation about as fine as with c++.

you are spreadind f.u.d.

Re:"without garbage collection"

[IamTheRealMike]

You must be a Java programmer. Garbage collection is generally a very bad idea for a systems language, because of the periodic stalls whilst it does the cleanup

Ah yes, the "systems language" debate. Oh how I love those.

Here are a few things to ponder.

The first is that your claim about Android underperforming iOS doesn't seem to have any merit. I have a Lollipop device here and it's as smooth as any iPhone I've ever used. Indeed I suspect by "smooth" you mean whether animations consistently hit 60fps and that has relatively little to do with garbage collection because most animations only last for a second or two, and you can easily delay GC until after it's finished. If you actually read about Project Butter and the work the Android team did to make things fast and smooth, it mostly involved deep changes to the graphics stack. The new GC in ART helps when doing things like scrolling down infinite lists, but otherwise, it's not a big deal. Bear in mind GC pauses on a modern Android device are in the realm of milliseconds - not fast enough to cause a frame skip unless you're really pushing up against the deadlines.

Another thing to consider is that people love to try and define "systems language" to mean whatever language they happen to prefer at the time. For instance the Linux guys have claimed for years that C++ isn't a "systems language" because you can't use it to write a kernel. However, quite a few successful kernels have done just that: for instance parts of the MacOS kernel are written in C++, the osV kernel is mostly C++ and so on. Microsoft even wrote an entire OS with kernel and everything in garbage collected C#. I've come to believe that the term "systems language" is so vague as to be useless for describing programming languages.

Final point. Rust claims to be superior for systems programming because it doesn't need a garbage collector. However, Mozilla is not in the business of writing kernels. They are in the business of writing web browsers. Web browsers absolutely can be garbage collected and due to the need to support Javascript, often are. At a time when Mozilla is dumping resources into designing an entirely new programming language and experimental layout engine that uses it (Servo), the Chrome guys are quietly getting on with migrating Blink (aka WebKit) to garbage collected C++. The project is called Oilpan, look it up. Apparently Google disagrees with Mozilla about the need for a non-GCd "systems language" for the kind of work they're doing.

Re:"without garbage collection"

[Anonymous Coward]

Internally Google are porting as many of their C++ systems to Go as possible. Everyone that has ever worked there, or even asked someone that has, knows that Google is not a fan of C++. They only still use it for projects that have very strict performance/memory requirements and for projects that are simply too expensive to migrate.

Re:"without garbage collection"

[Anonymous Coward]

Mozilla sees merit in RESOURCE SAFETY. That includes mitigating common memory leaks with Rust, but also things like avoiding threaded data races. It's fine to pretend that just because a browser needs a GC for its GC'ed languages, it's not fine to assume that the rest of the browser needs to rely on one. Or that Rust is ONLY intended for browsers, when it quite clearly is not... it's just what Mozilla happens to be using it for, but that also happens to encompass a LOT of systems software components, often which do not require garbage collection. In fact the more I actually think about this, the less sense your arguments make. If Google jumped off a cliff, would you?

Re:"without garbage collection"

[Anonymous Coward]

>You must be a Java programmer. Garbage collection is generally a very bad idea for a systems language, because of the periodic stalls whilst it does the cleanup.
You must be an idiot.

>It's one of the big reasons why Android underperforms iOS, why it's never been so smooth in operation.
ART Runtime explained for 5 year olds. https://www.youtube.com/watch?v=EBlTzQsUoOw

Re:"without garbage collection"

[BasilBrush]

The first is that your claim about Android underperforming iOS doesn't seem to have any merit. I have a Lollipop device here and it's as smooth as any iPhone I've ever used.

I nearly went into this with my post, but decided it was better to make a simple clear point without dealing with the obvious avenues for counter-argument in advance.

Android got smooth by throwing hardware at it. The reason for a while Androiders were bragging that their phones had more cores or higher clock speeds was that Android needed it.

Then there was the NDK, whose justification was explicitly things for which Java and Garbage Collection were unsuitable.

I don't know anyone who thinks C++ isn't a systems language. For the simple reason that C++ is C when you want it to be. Such people may exist, on the internet there are all views represented. But they don't know what they are talking about if so.

And I don't really care who's behind the language. And I certainly wouldn't any extra weight to an idea just because some people at Google think it.

Re:"without garbage collection"

[drewm19801927]

Things could get very interesting indeed if Apple opens up Swift. I'm not sure if Swift can cover all of the use cases that Rust does, but it can probably cover most of them, and Apple has worked very hard on Swift's ergonomics. Interactive REPL-style coding is a mere twinkle in some rust dev's eye right now; the closest we have is the playpen and the playbot in the IRC channel. The world wins if either of them catch on.

Re:"without garbage collection"

[gTsiros]

You can write good code and bad code in any mainstream (just so that exercises like brainfuck, malbolge or dis are excluded) language.

Android is just horribly written. They make monumentally bad engineering decisions. Remember one of the major flaws of os/2 4? Yeah. Same thing. Horribly designed UI? Yup. hidden meat interface, interactive elements moving around on their own, windows popping up and disappearing, no deadzone between buttons... But ok that's not coding, that's UX design.

Android is a clusterfuck of bad decisions on every single point and i say that as a proud owner of about a dozen of the blasted things (x10 mini pro, x10 mini, xperia arc, z ultra, z1, milestone, etcetcetc).

but it sure is pretty! look at all those animations! "material design" they call it these days?

Re:"without garbage collection"

[drewm19801927]

Rust or Swift, that is... we're pretty screwed if the Rust playbot takes over the world :)

Re: "without garbage collection"

[Anonymous Coward]

Not twice. Every long lived object is inspected N times (where N is unbounded). Generational collection decreases N by a constant factor.

This is why papers that claim reference counting and GC have the same computational complexity are stupid. They can have the same apparent complexity in some common scenarios, but that's it.

I use Lua heavily, which has mark & sweep GC. They even removed the generational collector cause it was too complex for no benefit in the domains Lua is popular. I enjoy the benefits of marking GCs everyday.

But I never store huge datasets in Lua for processing. I use Lua to bind discrete C objects and libraries that do the heavy lifting. And in those components I can use more optimal memory strategies, which vary from component to component. They have better big-O behavior as well as low fixed costs.

Anybody who defends one-size-fits-all memory management isn't fit to be an engineer.

Re:"without garbage collection"

[IamTheRealMike]

Um, I did work at Google for quite some years, and given the vast size of their C++ codebase the chances of it all being ported to Go any time this decade is zero. And for what it's worth I keep hearing from people who still work there that they're desperately trying to avoid being forced to use Go. It's hardly a slam dunk language decision.

Re:"without garbage collection"

[fsterman]

Android got smooth by throwing hardware at it. The reason for a while Androiders were bragging that their phones had more cores or higher clock speeds was that Android needed it.

I'm sorry, but this is the same argument that people made against Java in the 90's, when Java was a few orders of magnitude slower. But as time went on, the total percentage that the computational overhead took up dropped to less than 1% because the hardware got faster. Java's success shows that developer convenience is a very powerful thing.

Re:"without garbage collection"

[Anonymous Coward]

Being forced to use Go, and not using C++ are a bit different. Maybe they want to use something else with much more industry adoption.

Re: "without garbage collection"

[Anonymous Coward]

you just indicted about 90 percent of the computer science folks in academia.

but yeah, i agree with you.

Re:"without garbage collection"

[Nubbywubwub]

A good memory allocator makes memory fragmentation a non-issue. Your system's default memory allocator probably fails at this, but by default Rust uses a custom fork of jemalloc, which is an allocator specifically designed for fragmentation avoidance and scalability in concurrent environments.

Re:"without garbage collection"

[Nubbywubwub]

Your final point about Servo and Oilpan is off. Servo has garbage collection in the same way that Chrome is growing garbage collection via Oilpan: for keeping track of objects in the DOM (in fact, Servo uses the SpiderMonkey GC for this, it's actually pretty neat. See https://blog.mozilla.org/resea... for details). Mozilla isn't afraid of garbage collection, they just happen to think that if you can get by without it then hey, why not?

Re:"without garbage collection"

[BasilBrush]

But as time went on, the total percentage that the computational overhead took up dropped to less than 1% because the hardware got faster.

Which is exactly the same thing as I said. Java's shortfalls were mitigated by hardware upgrades, not by actually fixing it. It can't be fixed. Whilst the GC stalls can be comped with for higher level software, it's a showstopper for lots of systems level programming.

Re:"without garbage collection"

[BasilBrush]

I think they will open source Swift. But I doubt it'll get much use outside of iOS and OSX programming. So many of the implementation decisions are about being compatible with Objective-C and the Apple frameworks. It *could* be used for other things, but I think the bias there will be enough to keep others away.

Re:"without garbage collection"

[HiThere]

The proper way to handle that is to allow garbage collection to:
1) run in a separate thread, and
2) be disabled in sections of the program where timing is critical.

If your application needs to, you can disable garbage collection right after the beginning, and never re-enable it. Then the compiler/linker can be smart enough to just remove it as unused code.

Garbage collection allows many techniques to be handled with non-deterministic freeing of memory. This can be especially important when programs are running on multiple independent threads/processes. (Sorry about threads/processes, but different languages use the terms differently. I mean code that can be running on separate cores and whigh has only limited sharing of information between the routines. In Python this would by MultiProcessor code, not multi-threaded, but it's not the same as separate system processes, quite. I'm not sure how Java would term it, but it's my understanding that in Java separate threads have common access to the same memory, and this isn't what I mean. I'm thinking more of D's std.concurrency or Ada's Tasking. [Ada has ways around the lack of garbage collection, but that's a part of what makes Ada difficult to use, as storage pools don't really handle things well dynamically. OTOH, I sometimes wish D's garbage collection was more deterministic. There's trade-offs everywhere.])

Re:"without garbage collection"

[Anonymous Coward]

You're a blogger, aren't you? News flash, asshole: software exists that does other things than serve your fake friends' insatiable demand to see your blog posts. When does a program expect to be idle? When it's not actively processing data this very second, that's when. Programs aren't all external-event-driven, can you imagine that? Not every program is an HTTP server, you stupid fuck. There's more software out here in the really real world than you can possibly even conceive of, you moronic asshole blogger.

Re:"without garbage collection"

[Anonymous Coward]

And the only thing a developer can do about it is switch to a different language or develop for a more powerful machine.

It's possible to use static memory allocation even with garbage collected languages. Sorry, but what you're saying is ignorant bullshit.

Re:"without garbage collection"

[Anonymous Coward]

Rust claims to be superior for systems programming

Eh... care to cite anything that corroborates your claim? I can't recall any Rust authorities stating things like that.

Chrome guys are quietly getting on with migrating Blink (aka WebKit) to garbage collected C++

Rust provides garbage collection. In fact this is being used to unify Javascript object and DOM object memory management. Your ignorance of this fact indicates that you don't know what you're talking about.

Chrome ... Oilpan ... blah blah

Chrome fared no better than its contemporaries at the most recent pwn2own. That event (and the 2014 pwn2own as well) revealed yet another batch of dangling pointers, use-after-frees and races, most of which Rust could have prevented. Those flaws would have never even compiled.

Chuckleheads such as yourself will impede adoption, naturally, but Mozilla is on the right track here and they will prevail. Rust, or something like it that delivers both memory safety and bare metal performance will eventually put C/C++ to pasture.

It's a shame it has taken so long.

Re:"without garbage collection"

[BasilBrush]

Everyone who is responded to me has done so as if I said that Garbage Collection is always bad. Of course it's not. Languages such as Python are great places for GC, as is Javascript, and Java, when it's used at the application level.

It's just a very bad idea for systems programming.

Re:"without garbage collection"

[IamTheRealMike]

No, WebKit already traces through C++ for the DOM GC. Oilpan is a project to make it use GC for *all* Blink objects including objects not exposed to the DOM at all. Read the design doc to learn more.

Re:"without garbage collection"

[HiThere]

But being bad for systems programming is not the same as being bad in a systems programming language. I will readily grant that there are applications in which it is desireable to avoid garbage collection. This just means that the language must be able to run well without it. And really, is easily casting integers to pointers and back important? That's the main they the language needs to avoid to make garbage collection reasonable. And switches, either program or compiler, to disable it are also fairly easy.

Re:"without garbage collection"

[maestroX]

You must be a Java programmer. Garbage collection is generally a very bad idea for a systems language, because of the periodic stalls whilst it does the cleanup.

Why not garbage collection methods in the kernel with different strategies?

Why do we need new langs?

[Anonymous Coward]

Everything is written in JavaScript or soon will be. New language development is a waste of time that should be better spent making mobile apps for 3D printers.

Re:Why do we need new langs?

[siddesu]

My 3D printer doesn't run Javascript yet, you insensitive clod.

Re:Why do we need new langs?

[Anonymous Coward]

I'm building a new cross platform language, bootstrapping it in ASM.js. It's sad, but the web browser is just yet another "OS" my code needs a wrapper for now.

Re:Why do we need new langs?

[fsterman]

Eventually the METAL Linux kernel module (C -> JS + asm.js) will boost overall processing speeds by ~4%.

Re:Why do we need new langs?

[Anonymous Coward]

"Yet"

Why we should know C and C++

[Anonymous Coward]

C and c++ are very good core language for software companies. Specially those who did engineering in the field of electronics subject, they might be interested in Embedded programming. C is used in embedded programming. C and c++ are native language which performance are much faster than other language. If you are interested to see all jobs and career opportunities, You can analyse by seeing the page http://www.alljobopening.com/jobs/all-job-opening-in-india/. So start leaning C++ if you are doing performance related work.

Re: Why we should know C and C++

[Anonymous Coward]

Jesus, I don't want to compete with people who can live on a 10th of my salary, why would I want to study the outsourced technologies, this is dumb.

Re: Why we should know C and C++

[Anonymous Coward]

people who can live on a 10th of my salary

You have just overstated their income, of course.

At our company, Indian engineers make less than 10% of the typical engineer in the US/EU. I'm one of the better paid and more qualified engineers in the EU, so it looks to management like I'm 20+ times as expensive as someone from India. However, I also produce a lot more than those engineers, and respond to customer requests a lot faster. So management hates my existence, but puts up with me because the alternative is worse (slower responses to market demand, and almost as much cost).

Oh fuck off.

[Anonymous Coward]

The pace of development of new ideas in commercial software engineering over the last twenty years is essentially null - just a cycle of NIH and wheel reinvention over and fucking over by egos and profiteers wanting to lock you in to their thing. I really don't know whether anyone involving themselves in this bullshit is deluded or just wants a share of the circle-jerk funding.

Re: Oh fuck off.

[Anonymous Coward]

i see nsa shills are alert and will badmouth any real it security improvement

Have you actually tried using Rust?

[Anonymous Coward]

Have you actually tried using Rust? I have, and I can tell you that it isn't "polished".

Maybe it won't change as goddamn much as it typically has each day, but it's not a clean language like say Python or C# are.

Its library API is something awful. You have to write stuff like:

let path = Path::new(&app_path)
println!("file name: {}", path.file_name().unwrap().to_str().unwrap());

The memory management approach is also, to put it nicely, a royal pain in the ass to use. Maybe it can guarantee a higher level of safety, but it slows down development to a crawl, even once you understand how it all works and can work with the compiler instead of against it.

Its string handling is fucked up beyond belief. Go read about about String and &str if you don't believe me.

Rust is a very tedious and anal language to use, to the point of any safety gains being eliminated by much slower development time.

I feel that I can get almost the same level of safety by using modern C++ techniques like RAII and smart pointers, along with strict compiler options, without the speed of development slowing to a crawl.

Rust will be "polished" the day that we can use it swiftly and effectively, rather than being burdened by its awkward memory management, or its shit-for-brains library API, or it's convoluted string handling. I mean, these are some pretty basic things that it's screwing up. If it can't get those even remotely right, it's not "polished".

Re:Have you actually tried using Rust?

[gweihir]

Rust is a very tedious and anal language to use, to the point of any safety gains being eliminated by much slower development time.

Well, with that, it is likely far more efficient to have somebody that does understand both C and secure coding to do things in C. The thing is that Rust cannot eliminate all security problems anyways, and the remaining ones will be much more obscure. It also will introduce problems of its own, just as any language with tight control does, and for some of them, only a fix on the language side will help.

All in all, I am not sure this is the right approach. It seems to be geared at letting less competent coders do code that is security-critical, but that will never work well. If I am right, Rust may do more harm than good.

Re:Have you actually tried using Rust?

[Anonymous Coward]

The Rust path library actually forces you to think about possible errors. I prefer that over libraries that simply pretend errors don't exist and end up crashing at runtime (or far worse) because of it. In this case, not all paths will have a filename and they definitely won't all be valid UTF-8 so those function calls return a Result (essentially Either for those familiar with Haskell or ML).

Cross-platform path handling is hard and most libraries simply pretend errors don't exist.

Re:Have you actually tried using Rust?

[Anonymous Coward]

It strikes me as a "better" C++- that really isn't. It's got some arbitrary syntactic things (painting the bike shed) that lead me to wonder, right along with their proviso about it being alpha/beta code. Sorry, their claims of safety are nullified by the smartass remarks that they think they're being cute with.

Exclamation points on the end of things like println!() do nothing, really, for the language- and if you've got that idiot notion...what else have you missed?

Re:Have you actually tried using Rust?

[Anonymous Coward]

The simplest solution to "safety" is to probably work on making something like Haskell or Erlang produce tight native code like the C/C++ compilers produce. It'll be slightly slower and code slightly larger, but in general, the safety problems in question disappear in a functional language. They pick up other issues and they're just alien enough that few have fully adopted them at this time.

Re:Have you actually tried using Rust?

[Electricity Likes Me]

You are essentially blaming all security bugs ever on "incompetence". That's lazy management in the business world and it's stupid everywhere else. C has numerous and many traps. Building tools which make it impossible to make the "easy" mistakes is how we get to spend more time thinking about the actual hard ones.

Re:Have you actually tried using Rust?

[Anonymous Coward]

Exclamation points on the end of things like println!() do nothing, really, for the language

Exclamation points are used to denote macros. Why do you think println in Rust is implemented as a macro? It should be rather obvious.

Re:Have you actually tried using Rust?

[Anonymous Coward]

Just because Rust may make you think about possible error conditions it doesn't mean that they're handled any better than when using other languages.

Look at Servo. This is a web browser rendering engine written using Rust, written by many of the same people working on Rust. Specifically, look at a bug like https://github.com/servo/servo/issues/5051.

That bug report shows that Servo crashed at runtime. You'll also see error messages like

thread 'LayoutWorker worker 3/6' panicked at 'called `Option::unwrap()` on a `None` value', /Users/larsberg/rust/src/libcore/option.rs:362

and

thread 'PaintTask' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', /Users/larsberg/rust/src/libcore/result.rs:743

That looks an awful lot like an uncaught Java NullPointerException or an uncaught C# NullReferenceException! All of this unwrap() crap that's supposed to prevent problems like runtime failures has, guess what, resulted in a runtime failure!

Contrary to what you're claiming, even the people behind Rust write applications that "simply pretend errors don't exist and end up crashing at runtime"!

The Rust compiler itself is rife with runtime failures. Look at the Rust compiler bug list, and do some filtering on "ICE" or "Internal Compiler Error". For a compiler for a language that's supposed to help avoid errors, that's written in that very language, it sure does suffer from a lot of unexpected runtime failures and other bugs!

If the people creating Rust end up creating so much broken code while working on the Rust compiler itself, even now that it's supposed to be getting "stable", how the hell can we expect it to be any better for the rest of us mere mortals who aren't Rust experts?

Re:Have you actually tried using Rust?

[gweihir]

No, I do not. What I am pointing out is that this language will have "management" assign even less competent people to do "secure code" than they do now, for a likely net loss in security.

And besides, Rust does not prevent you from making all "easy" mistakes either, just some of them.

There is this class of "tool fetishists" that think all problems with coding can be solved by just using the "right tools". You even hear that opinion form people that really should know better. Well, guess what, if that were possible, we would have the right tools by now. The fact of the matter is that performance, security, maintainability, etc. cannot be enforced by tools. It takes coders that know what they are doing, that have the talent and experience to get it right. Of course, these people are expensive and they will give stand up to management when management wants things that are stupid.

Re:Have you actually tried using Rust?

[Anonymous Coward]

Oh wow, a single bug due to a careless use of unwrap in a project as large and complex as a rendering engine! You totally showed them. It's not like they already had plans to remove all uses of unwrap and standardize error handling across their experimental project once the language and standard library stabilizes. Rust is definitely shit!

You're a fucking moron.

Re:Have you actually tried using Rust?

[gweihir]

Indeed. I think these people are so in love with their own genius that they have overlooked that their tool is probably going to do a lot more harm than good. After several decades of research into software reliability and security it is clear that it is not a question of the tools used, although that flawed idea is strong in some academic and industrial quarters. What these people are basically saying is that if you have just the right kind of hammer, then you cannot hurt yourself with it anymore. Of course, that would be a Styrofoam hammer (or similar) that is also completely unfit for its primary purpose. The same is true for programming languages.

Re: Have you actually tried using Rust?

[Anonymous Coward]

given tthat we had horrible bugs in hpux windows and linux kernel code, i call bull on your shillery

Re:Have you actually tried using Rust?

[Anonymous Coward]

That's just one example. Search the Servo bugs yourself. You'll find other examples. You'll find more in the Rust bug list, too. It isn't a one-off case. This is a problem that's chronic to Rust code, even code written by the creators of Rust themselves!

Their future plans are irrelevant. If Rust 1.0 allows those kinds of bugs, then it's no better than Java or C# or C++ or other languages. In fact it may even be worse, because it gives this false sense of security while being no better.

Re:Have you actually tried using Rust?

[Anonymous Coward]

Performant compilers are very hard. That's hardly an usual amount of bugs for a compiler of this scope. The primary C# and Java implementations have had hundreds of thousands of bugs, and that's not including the internal bug list at Sun/Oracle and Microsoft. GCC has had well over a million.

Re:Have you actually tried using Rust?

[Anonymous Coward]

Nobody said writing a compiler is easy. But we're talking about a compiler for Rust, written in Rust, in this case.

The Rust web site states very prominently that "Rust is a systems programming language that runs blazingly fast, prevents almost all crashes*, and eliminates data races." (emphasis added).

Even the asterisk message only says "* In theory. Rust is a work-in-progress and may do anything it likes up to and including eating your laundry."

For a language that explicitly claims that it should "prevent almost all crashes", even the people who should know how to use it best (its creators) seem to run into an awful lot of crashes on the multiple projects that they've worked on using it!

Re:Have you actually tried using Rust?

[Anonymous Coward]

Why are Rust proponents so caustic so often? Whenever Rust comes up here or at HN or on other discussion sites people will point out some very real flaws with it. Instead of responding to those flaws like mature adults, the Rust proponents will fly into a rage and start insulting anyone who dares question Rust in any way. At HN, the Rust proponents will then systematically downmod anyone who isn't obviously pro-Rust, in a pathetic show of censorship. The only other programming language community that I've seen this kind of hostility from is the Ruby community. But maybe that shouldn't be surprising, as there is some overlap between the two. Some prominent Rubyists have gotten involved with the Rust project lately. This alone makes me not want to use Rust. I don't want to be treated with that sort of disrespect.

Re:Have you actually tried using Rust?

[Anonymous Coward]

I'm not a Rust proponent. I don't give a fuck about Rust and will probably never use it. His complaints are just retarded though.

Re:Have you actually tried using Rust?

[Jeremi]

Well, guess what, if that were possible, we would have the right tools by now. The fact of the matter is that performance, security, maintainability, etc. cannot be enforced by tools.

I take it you do all of your programming in assembly language, because there's nothing to be gained by using anything higher-level than that, because you totally know what you're doing at all times?

(Or if not, you've tacitly admitted that there is a benefit to using a tool that enforces some level of safety; you're only quibbling about what that tool should be)

Re: Have you actually tried using Rust?

[Anonymous Coward]

even the supposed experts kernel code mess up on a regular basis. well defined failure is much better than undetected subversion of a c kernel

Re: Have you actually tried using Rust?

[Anonymous Coward]

exactly as should be. well defined stop of program due to a bug stops attacker in his tracks.

Re:Have you actually tried using Rust?

[Anonymous Coward]

Except that comment said nothing about Rust. The arguments, "It might solve problems, but it will make new ones, therefore it will be worse," and "It won't solve every problem, therefore it doesn't do anything," are empty arguments that could be said of just about anything without any knowledge of what the argument is being used against. Especially when coming from a particular poster with a history of being very confident about subjects they know almost nothing about.

Re: Have you actually tried using Rust?

[gweihir]

You must have some really, really inflated ego to claim "disingenuous argument" as an AC. Your posting also shows that you obviously have zero understanding of the history of computing.

Re:Have you actually tried using Rust?

[Anonymous Coward]

the Rust proponents will then systematically downmod anyone who isn't obviously pro-Rust

The only one that was "systematically downmodded" in the HN thread was a known Scala zealot. Scala zealots should be downmodded or banned outright no matter the discussion.

Re:Have you actually tried using Rust?

[MightyMartian]

How is it you know his complaints are invalid then?

Re:Have you actually tried using Rust?

[tgv]

> the remaining ones will be much more obscure

That is by itself not an argument. The same obscure errors can be present in code written in another language. Rust does not seem to induce code with subtle bugs.

Re: Have you actually tried using Rust?

[Anonymous Coward]

pascal, algol and ada provided much better security properties than c. strong typing and runtime checks are badly needed, if you are concerned about cyber security.

for honest definitions of security. that is.

Re:Have you actually tried using Rust?

[drewm19801927]

Wow, HN must be attracting a very special subset of rust folks if what you say is true. I've found the rust devs and everyone in the community to be consistently polite and helpful. There was one guy who would leave a mix of verbal abuse and insightful technical arguments, and the abuse the devs took politely before ultimately banning him was epic. If you get stuck on something, help in IRC or SO is almost immediate.

Re:Have you actually tried using Rust?

[Anonymous Coward]

For someone with strong opinions, i wonder if you've actually USED Rust, because you're just making wild accusations that don't hold up as far as I can tell. What's "shit for brains" about the library? Why is the string handling any more "convoluted" than the handling in other systems languages? Why is the memory management "awkward" to you, compared to having to use a GC or having to find obscure bugs later because the compiler didn't catch them for you?

It would go a long way if you would actually offer criticism that applies to the current language, and not just recycled nonsense-arguments that you could apply to any language you just happen to dislike.

Re: Have you actually tried using Rust?

[gweihir]

You confuse security properties of a language and security of software written it it. A typical beginners/amateur mistake. For example, pascal programs often have severe security problems because the coder needed to work around the limitations of the language and messed that up. After all, "Pascal is secure" and hence a Pascal programmer does not need to understand security. In practice, that mind-set results in utter failure. I am merely pointing out that Rust seems to be inflicted strongly by the same faulty reasoning. Security is not a property created by tools. It is a property created by understanding and experience.

But I think your dishonest and cowardly sniping from anonymity actually has a different purpose: Sow discord. That puts you right into the NSA/STASI/GeStaPo corner. It is also quite possible that the NSA has looked as Rust and found that it is not a problem for them (for example because even more incompetent coders will offset any advantage, or because they have their own people in the project to place backdoors) and hence they are pushing for its adoption in secure software wherever anonymity protects their identity.

Re:Have you actually tried using Rust?

[gweihir]

You can stick your innuendo up you backside, where it properly belongs.

Tool selection is a matter of convenience. Hence I have currently standardized on Python glue-code with C-modules wherever performance is critical. (I would have standardized on Eiffel, but it is too far in a niche...) This has nothing to do with security. In order to make my code secure, I have to understand any and all of its external interfaces, how to protect them and then make sure in addition that all my assumptions on the internal data paths are correct. Rust will not do any of that for me, but it might create a false sense of security.

Seriously, what are you people thinking? "No silver bullet" was written almost 30 years ago, and you people are still searching for it? Talk about repeated failure...

Re: Have you actually tried using Rust?

[gweihir]

You are assuming Rust will give you that. It will not.

Re:Have you actually tried using Rust?

[Anonymous Coward]

If Rust prevents more bugs than the other leading brand, what's the problem? Or is it not worth switching to Rust if some of the most complex software you could write with it still has bugs? Or are you too hung up on a few people's grandiose (and erroneous) statements, and thus dislike the language just as much? I honestly don't understand what your beef with Rust actually is, or if you even have a beef to begin with or are just talking shit because you want to be contrary.

Re: Have you actually tried using Rust?

[Anonymous Coward]

I use to be excited about Rust, so I got involved with the project on github. The main developers were not friendly. They were not welcoming or polite. They also didn't care about keeping the documentation up to date with the constant changes. Maybe I've been around the OpenBSD project to long, but the lack of focus on documentation was a red flag.
On top of it all the syntax is terrible. I don't think it will take off.

Re: Have you actually tried using Rust?

[Anonymous Coward]

You're a moron. Have you ever bothered to read the spec? Rust is far more advance than C# or Java.

Re:Have you actually tried using Rust?

[Anonymous Coward]

Clearly Rust doesn't prevent bugs, although it's (incorrectly) claimed that it does. This is proven by the fact that even the people who created Rust in the first place cannot write Rust code that doesn't crash due to basic flaws.

Re:Have you actually tried using Rust?

[Anonymous Coward]

>Attempts to "standardizes" on one language
>Calls others out for "searching for magic bullets"

Are you high, or just a massive hypocrite? Nobody is seeking a magic bullet. They are seeking a better language than the ones we are currently using. Clearly Ada and the other Rust-likes weren't good enough for convenience-seekers like you who don't care about longer-terms maintenance and debugging and API costs compared to how quickly you can write the initial slew of print statements in your app, or how quickly you can hit the floor running with the language without having to learn anything new.

Are you sure you're not the one ignoring 30+ years of CS development? It sure sounds like you're trying to attack others for the same things you're doing, while waving your hands in the air to gather as many stray mod points you can.

Re:Have you actually tried using Rust?

[serviscope_minor]

"No silver bullet" was written almost 30 years ago, and you people are still searching for it?

That's because it was a through-and-through. I can write programs far grander in both scope and complexity than almost any programmer of 30 years ago. The reason is not because I am a super-awesome-uber-l33t programmer it's because modern tools are really very good.

I would argue that's the case for most programmers now.

If that's not a silver bullet, then I don't know what is.

Re:Have you actually tried using Rust?

[gTsiros]

scope and complexity say absolutely nothing about the quality of code

why did you choose those two words instead of "[...] programs far better than almost [...]" ?

Re: Have you actually tried using Rust?

[MenThal]

The argument may be that Rust, like a lot of other types of tools, libraries, frameworks etc, tend to make easy things easier, but harder things harder. It is a common pitfall and tradeoff that may be worth it or not.

For single threaded programs, I'd likely rather stay with C++ than jump on Rust any time soon. For heavily multithreaded programs, I'd be plenty lost, so perhaps Rust would be a net benefit in those cases.

At any rate, I hope this means it is maturing, stabilising and can get documented well enough to be a feasible alternative. If nothing else, the ideas around security handling might get us thinking in better ways in other languages.

Personally, I ran away screaming from C++ to Ruby after several years of losing my sanity, despite that meaning a large jump in other aspects of work area. Perhaps this is a good halfway point? Time will tell, crossing fingers.

Re: Have you actually tried using Rust?

[Anonymous Coward]

Wearing safety glasses doesn't make you safe, and you can still hurt yourself in a lot of ways with tools if you don't know how to use them. That doesn't mean safety glasses are useless and do nothing for safety.

There is no magic bullet to security, no programming language that magically guarantees any program it makes is both useful and secure regardless of the programmer's incompetence. However, that doesn't stop some tools from being more secure than others, that make it more difficult to make common mistakes, or make it easier for knowledgeable programmers to get things done. Arguing that it can't stop people from being stupid is just empty BS that doesn't say anything about what Rust (or any other language) actually does to make things better or worse.

Re: Have you actually tried using Rust?

[Anonymous Coward]

50percent of all cve exploits could be avoided by using something like pascal, ada or rust.

c is a usg invention.

the cyber war domain is by now a big thing.

fbi and other imperial coppers have bitched about crypto just recently.

i state facts plus my analysis. my mission would be impaired by amateurs if non anon. feel free to dispute my arguments.

Re:Have you actually tried using Rust?

[serviscope_minor]

scope and complexity say absolutely nothing about the quality of code

So? I can write programs that do more useful stuff than most programmers from 30 years ago. Doing useful stuff is the ultimate goal. And like I said, it's not because of me it's because there are excellent tools and techniques for managing the complexity of large problems.

Re: Have you actually tried using Rust?

[Anonymous Coward]

I've been around the OpenBSD project

Retard detected.

Re: Have you actually tried using Rust?

[Anonymous Coward]

he is inventing and then denouncing the silver bullet. i am not sure whether this is done in good faith.

of course rust is just a better tool than c. but that is definitely progress in the light of the cyber wars going on.

Re: Have you actually tried using Rust?

[Anonymous Coward]

because you and your ftmeade/bell labs friends assert this, it must be true ?

classic fud on display here.

Re:Have you actually tried using Rust?

[Anonymous Coward]

Its string handling is fucked up beyond belief. Go read about about String and &str if you don't believe me.

Your entire comment shows that you're completely out of touch with modern systems development, but this line takes the cake. The lack of this sort of distinction in C++ has been plaguing the language for years, and has only recently been addressed with the addition of std::string_view in C++14.

Also, your code example of using a path is adorably naive. Paths are fucking hard, and Python (your example of a "clean" language) fucks them up royally. What happens if the path doesn't have a file name (hello, root directory)? What happens if your file name isn't valid UTF-8 (hello, Unix and Windows)? Rust makes it obvious when details are liable to screw you over, which ironically is exactly what someone like you seems to need to keep them from completely fucking things up.

Re: Have you actually tried using Rust?

[Anonymous Coward]

Between your crazy (and obviously wrong) assertions, and the guy who keeps posting "You're a moron." constantly, you Rust fanatics are starting to look like a bunch of whackos.

Re: Have you actually tried using Rust?

[Anonymous Coward]

deterministic crashes due to programming bugs is EXACTLY what you want.

of course if your goal is to have more opportunities for war, you want the opposite and like the c language.

if they claim to be bug free, they are idiots.

Re: Have you actually tried using Rust?

[Anonymous Coward]

can you do that without a fully scanning gc ? if not, it is not a replacement because non realtime.

Re:Have you actually tried using Rust?

[Anonymous Coward]

The thing is that Rust cannot eliminate all security problems anyways, and the remaining ones will be much more obscure.

Let me get this straight: your argument is that Rust can't eliminate attack vectors such as, for example, SQL injection, and therefore we shouldn't use it over a language which trivially exposes you to both huge classes of memory vulnerabilities *and* SQL injection? It's one thing to say that Rust is so new that its set of "unknown unknowns" is larger than C, because that's entirely true and reasonable. But we also *know* that C is a nightmare to audit and prove secure, as any of the recent widely-publicized vulns should have made obvious by now. You're also free to look at the results of every Pwn2Own competition, which *always* involve exploiting memory unsafety. Being memory safe by default isn't faffery, it's literally the baseline for any competent programming language emerging in the modern day (look how hard C++11 and C++14 are trying to tack memory safety onto the language, with mixed results).

Re:Have you actually tried using Rust?

[Anonymous Coward]

Exclamation points on the ends of things indicate compile-time shenanigans. There's one on println!() because it does compile-time checking of the format string that you give it, the purpose of which is to shut down vulnerabilities such as format string attacks in C: en.wikipedia.org/wiki/Uncontrolled_format_string

Re:Have you actually tried using Rust?

[Anonymous Coward]

Please explain how it is possible for this language to do "more harm than good". At worst it would be exactly as vuln-ridden as C, which would leave us no worse off. Fortunately from what I've seen it's actually damn good at its job. Unless you think that making it harder to pwn people who are unintentionally using your software is somehow a downside.

Re: Have you actually tried using Rust?

[tgv]

Sure. I only wanted to point out that Rust doesn't seem any worse than other languages in that particular respect.

BTW, I looked at Ruby and thought: what an awful mess. It's the kind of language that allows you to do things too cleverly. Redefining what a declaration means by overriding functions, was that really necessary?

I'm not too positive about Rust, but I admire the attempt.

Re:Have you actually tried using Rust?

[obarthelemy]

I think you're both right and wrong. Clearly, a safe tool, especially a tool made safe to the point of being unusable, is not a panacea. Yet kids with motorbikes have a lot more fatal accidents than kids with cars.

The sad truth is you need both: tools with no bugs and safe-by default, and programmers who know how to use them. I agree that if I have to choose, the safe programmer is more important... but show me a project where you can guarantee all devs will be of the "safe" kind (let alone, be that one lone mythological safe dev) for the actual life of the app ?

Re:Have you actually tried using Rust?

[Nubbywubwub]

First of all, claiming that HN is some bastion of civility is lolworthy. Second of all, if you read those discussions it's actually amusingly opposite: one of the Rust developers basically does nothing but roam around and hem and haw and equivocate about how the language isn't going to solve all your problems and you shouldn't bust a nut over it. The people who get downmodded are actually just dumbasses (no shortage of those on HN, in fact it's a booming market).

Re: Have you actually tried using Rust?

[Nubbywubwub]

Security is not a property created by tools. It is a property created by understanding and experience.

This is a false dichotomy. Security is created by understanding and experience, and *enforced* by tools.

Re: Have you actually tried using Rust?

[Nubbywubwub]

Is the "obviously wrong" assertion that C is an utter shitshow when it comes to producing software that's resistant to exploitable memory safety vulnerabilities? Not only is that not obviously wrong, I'm going to have to ask for a citation if you think anyone in the world seems to believe otherwise.

Re: Have you actually tried using Rust?

[Nubbywubwub]

The argument may be that Rust, like a lot of other types of tools, libraries, frameworks etc, tend to make easy things easier, but harder things harder.

When I think about hard problems, I think about things that are hard to do in C++ like storing internal references to the stack or reasoning about who's going to deallocate some bit of memory or about coordinating memory between threads. C++11/14 helps, but the hole that it's trying to dig the language out of is massively deep. Meanwhile, Rust makes these hard problems easy. We don't have enough experience with Rust yet to know what important things it truly makes hard, but memory safety is a big deal to me so I'm willing to take the chance on the unknown.

Re: Have you actually tried using Rust?

[Anonymous Coward]

So you think all OpenBSD users are retarded? Pull you're head out of your ass man.

Re:Have you actually tried using Rust?

[Nubbywubwub]

Well, guess what, if that were possible, we would have the right tools by now.

Judging from this attitude, I'm starting to think that the fact that we don't have the right tools is because every time someone tries to design and implement the right tools they get shut down by chicken-or-the-egg fallacies like this one.

Re: Have you actually tried using Rust?

[Nubbywubwub]

Actually, it will. I appeal to our shared subject line: "Have you actually tried using Rust?"

Re: Have you actually tried using Rust?

[Anonymous Coward]

For example, pascal programs often have severe security problems because the coder needed to work around the limitations of the language and messed that up.

Okay, you're saying "for example", but really you're making a claim without an example. Can you provide a concrete example of this?

Re:Have you actually tried using Rust?

[Half-pint HAL]

Exclamation points on the end of things like println!() do nothing, really, for the language

Exclamation points are used to denote macros. Why do you think println in Rust is implemented as a macro? It should be rather obvious.

Why should the coder care whether println is implemented as a macro or a procedure?

Re: Have you actually tried using Rust?

[Half-pint HAL]

The difference is that C is a very low-level language -- it has even been suggested only half-jokingly that C is just portable assembly language. It is inherently insecure because it allows the coder to do pretty much anything the underlying computer can do. It's a case of trading flexibility against other features.

Re:Have you actually tried using Rust?

[Nubbywubwub]

It's part of Rust's general policy of favoring explicitness, which is understandably controversial. Macros are very free-form and upon seeing a new one for the first time there's very little the programmer can assume about what they do (which, at the limit, can include running arbitrary code at compile time). In contrast, a function call is relatively easy to reason about. It's not 100% necessary by any means, though losing the syntactic distinction distinction might make many macros virtually unparseable for all I know (macros are so free-form that the current parsing tactic is "if I see the exclamation point, consume paired delimeters until they balance out, at which point I know that I'm out of the macro and can continue parsing as normal).

Re:Have you actually tried using Rust?

[tricorn]

Your average desktop computer, compared to a system from 30 years ago, is over 7,000 times faster, has 3-6,000 times as much RAM and 1.5 million times as much persistent storage available, and can communicate over 4,000 times faster, and that's not even getting into graphics capabilities.

There's more code in the boot ROM than there was in the boot ROM plus OS plus several applications.

It's not that programming tools are so much better, or that programming techniques have advanced, it's that you can write programs with many fewer restraints.

Re: Have you actually tried using Rust?

[gweihir]

Go away NSA shill.

Re: Have you actually tried using Rust?

[gweihir]

That argument is bogus and that has been known for a long, long time.

Re: Have you actually tried using Rust?

[gweihir]

C is not insecure. Security is not a language property. What you probably means is that it is easy for the incompetent to write insecure code in C. That is however true of any real language, including Rust. The nature of the insecurities will change, but that is it.

Re: Have you actually tried using Rust?

[gweihir]

That is a pure conjecture. Changing the language does not suddenly make people that do not understand security write secure code. What is true, on the other hand, is that most CVEs could be avoided if the people that wrote software would understand security.

Re: Have you actually tried using Rust?

[Nubbywubwub]

Ah, I see, you're rejecting this language out-of-hand because you've read a mathematical proof that programming languages must necessarily be fraught with undefined behavior like C is, and that null-based error handling like C has is the absolute and unassailable pinnacle of robust software architecture. If I may, could I ask you to link me to a text of said proof? I don't have an ACM membership, but since it's been known for "a long, long time" I would hope that it's passed into the public domain by now.

Re: Have you actually tried using Rust?

[gweihir]

I agree on that. Rust may be a small step in the right direction, but it may also be counter-productive. Any fanatical heralding of a tool as THE silver bullet that will solve all problems is completely bogus.

I do have to say that the reaction here to criticism against Rust will make me stay away from it. And one of the things I do for a living is writing secure software.

Re: Have you actually tried using Rust?

[gweihir]

Security cannot be enforced by tools. That approach has been tried time and again and has universally failed. First it was static typing, then it was garbage collection, then it was 5G languages, then it was patterns, etc. All failures. All heralded with the same bombastic claims that Rust comes with and none delivered. The only thing known to improve software security significantly is coders that do understand security.

Re: Have you actually tried using Rust?

[gweihir]

Openssh. Attacked constantly, extremely secure, implemented in C. Postfix. Attacked constantly, extremely secure. Written in C. Qmail. Linux network stack and firewall code. xBSD kernels. The list goes on.

C is a good basis for secure coding, but only if you have people that know what they are doing. Incompetents will, on the other hand, still mess things up with Rust.

Re: Have you actually tried using Rust?

[gweihir]

Go look for one yourself. And If you do not understand what I am talking about, you have no place in this discussion.

Re:Have you actually tried using Rust?

[gweihir]

Seriously? Are you mentally challenged? It is dead simple: "Rust is secure" => "managers think their coders do not understand security anymore" => "vulnerabilities abound".

Re: Have you actually tried using Rust?

[Nubbywubwub]

When you write C, do you enable warnings such as -Wall, -Wextra, -Weverything, -Wetc? This is an example of a tool that helps to enforce strict practices that lead to more robust products. And if you think warnings are a waste of your time, then please let me know which projects you work on so that I can remove such recklessly cowboy-coded products from my machines. Experience is no excuse for believing oneself infallible.

Re: Have you actually tried using Rust?

[Anonymous Coward]

Go look for one yourself.

Ah, that'd be a "no" then and your claims are therefore baseless.

Re:Have you actually tried using Rust?

[serviscope_minor]

It's not that programming tools are so much better, or that programming techniques have advanced, it's that you can write programs with many fewer restraints.

It's a mix of both. It's 2015, so that makes 1985 30 years ago. The '85 era computer I have most experience with is the BBC Model B. For the day it had an excellent implementation of BASIC: proper named procedures and functions and even an integrated assembler.

It didn't however even have proper block-structuring like the later QBasic for things like IF statements. You could allocate memory but not deallocate: it didn't even have a proper heap. It was outstanding for the day but very, very primitive by modern standards. And it wasn's super efficent so you had to do heavy lifting in ASM which is very slow going.

Compared to something like that modern tools are amazing: it's not just the extra performance it's being able to manage large systems.

Re: Have you actually tried using Rust?

[Anonymous Coward]

on GCC 4.7 and later.. Yes..
on GCC 4.4->4.7 subset..
On GCC ->4.4 depends...

But there are much better ways... like static code-analysis that actually detects real security-problems.. (and lots of other stuff too)

Best way to write secure code is to first draw a flow-diagram of the system, then design the the interaction-points between the modules and then write unittests and then start implementing the code... and when the code is done use a good tool for static code-analysis..
So... The tools are not there to enforce but there to help for all the random stuff that is hard to keep track of..
I can write code that is 100% correct and that not a single tool will complain about... But at the same time it could contain big security-issues due to bad design..

Re:Have you actually tried using Rust?

[Anonymous Coward]

No... But you can write more bloated code without it affecting performance too much...

Re: Have you actually tried using Rust?

[Half-pint HAL]

Sorry, I should have said it is no inherently security.

Re:Have you actually tried using Rust?

[Anonymous Coward]

Seems that AC was correct after all if you just look at the poster's comments made since...

They are so generic and contentless, they could be made in an argument against or for just about anything security related. They could be copy pasted into a thread discussing why one shouldn't switch to Linux because the change might introduce more errors, or into a thread saying why one should switch from Linux because it might introduce more errors, etc.

Once you get to the point of saying you don't even need to look at a language to judge it, you realize it is all baseless assumptions, which become hypocritical when making multiple posts complaining others are making assumptions.

Re:Have you actually tried using Rust?

[tricorn]

In the meantime, plenty of people were writing things in Pascal for the Mac. You had a resource compiler with resource files. You could write things in C, on a Unix system. You could build things with "make". Most of the software tools used to compile Linux and most of the current standard software was already in existence. There were source code control systems. There was X Windows. There was TeX. There was PostScript. There were a LOT of things that make up the majority of the software tools still in use today, and most are very little changed since then.

Sure, git is better than CVS. A large part of that is due to the constraints of the available hardware, you simply couldn't have done git in 1985 with available hardware.

The basis for Object Oriented Languages was well established, as was the basis for multi-threading (see Path Pascal, C++, Smalltalk).

What's been done since then is to take advantage of the massive increase in speed and storage available. Sure, there have been some incremental improvements to languages and utilities and development environments, but the impact that's had compared to the hardware improvements is fairly small.

The main advances in programming have been with encryption and compression. Everything else would have fast-forwarded within a few years if today's hardware had all of a sudden been made available back then.

Re:Have you actually tried using Rust?

[serviscope_minor]

I think you have your timelines a bit wrong and/or a rosy view of the past. Firstly there's the question of what was widely available. The Mac 128 and unix systems were out of the reach of people like me back then, costing many thousands when thousands were worth a lot more. Unix was expensive and the compilers were outrageously expensive.

Price aside, things were very different. On unix, you had the frankly awful builtin tools which would do nice things like crash if you used a line over 100 chars long. Lots of time wasted there---the GNU project was only started 2 years prior so it wasn't yet a question of simply installing quality tools.

C wasn't how one would recognise it now. K&R was very much persent (and pushed more complexity on to the user) and standardisatio was 5 years away. C compilers were pretty divergent and there were all sorts of system-specific hacks like NEAR and FAR.

C++ ddn't exist in a remotely modern form. Most features were not even there yet and standardisation was 13 years off, and more like 18 years until it was widely supported.

X11 wasn't due out until 1987: earlier version just about existed but were not practically in use.

TeX did exist, though LaTeX was in a rather early beta and it was years before 2-e. There's a reson latex 2e became popular---it's much easier for most people to use.

CVS was most certainly not there: it didn't arrive until 1990. SCCS did, but that was only in the hands of a precious few people.

There were a LOT of things that make up the majority of the software tools still in use today, and most are very little changed since then.

The basics were there, or perhaps the raw elements. The form of them was vastly cruder than we have today. It's amazing what we take for granted now. However as something of a fan of retrocomputing, and it was originally something of a shock how primitive it was. I remember it and it felt advanced at the time, not primitive.

Seriously, go downloaf and emulator and have a play. For extra fun, disable the internet so you have access to similar information retreival systems and software for the time.

Re:Have you actually tried using Rust?

[lars_stefan_axelsson]

Indeed. I think these people are so in love with their own genius that they have overlooked that their tool is probably going to do a lot more harm than good. After several decades of research into software reliability and security it is clear that it is not a question of the tools used, although that flawed idea is strong in some academic and industrial quarters. What these people are basically saying is that if you have just the right kind of hammer, then you cannot hurt yourself with it anymore. Of course, that would be a Styrofoam hammer (or similar) that is also completely unfit for its primary purpose. The same is true for programming languages.

Well, having done (some very small part of) that research I think you're over egging your argument. While its true that tool users make the difference, and it's a poor carpenter etc. etc. the fact of the matter is that some tools are more likely to be used correctly in certain situations than others. If you look at the human factors work in e.g. aviation, esp. military aviation, then that becomes apparent. Much thought, research and experience goes into designing the cockpit interface for a fighter pilot, for example, and for good reason. The workload is already overwhelming and one mistake can kill you so anything that makes that mistake less likely is sought after. This has gotten to the point that one sticking point of buying a fighter aircraft from another country is that the interface won't necessarily fit, not your pilots, but your doctrine on how to fight! Your doctrine of course affecting how you train your pilots. (I have a nice reference for that, but unfortunately its in swedish.)

Now, I can't see why the same wouldn't be true of programming languages in spades, as the task is at least as complex, and probably orders of magnitude more complex in many cases as flying an air plane. Now, we basically don't know anything, at least in a structured way, of how a programming language should be designed to best fit certain programming task, but the anecdotal experience is telling (look for example at Ericsson's work with Erlang, experience that matches my own). Put another way, that 'C' should already be "perfect" by random chance is completely unlikely. We both know more about how to implement programming languages today (and hence can make more concessions to the programmer), and know more about programming in general.

Now of course, if you're argument is, to paraphrase the Erlang FAQ, that you can "still mess up an Erlang program by having hour long meetings about the colour of the project napkins" that's of course true. The best rifle doesn't win the fight, if you put it in the hands of untrained troops, especially if you have the worst trucks to take them to the front. BUT, all else being equal, the troops with the best rifles win, not every time, but more often than not. That's what it means to have a better tool, and its generally a worthwhile endeavour.

Re:Have you actually tried using Rust?

[tricorn]

I was programming in Pascal on a Lisa (dual boot to the Lisa command-line OS (Lisa Workshop) for development and MacOS for testing, occassionally booting to the Office environment). I bought it shortly before it came out as the MacXL, so had non-square pixels. I wasn't rich, and it wasn't any more expensive than a PC would have been with the same capacity.

The entire thing (Office 7/7, Workshop, MacWorks) plus system partitions for each was 10MB. System RAM was 1MB. I can compress and copy that whole system in a few seconds across a network now.

I'm sorry you were stuck with BASIC, but that wasn't exactly cutting edge in 1985, and there was lots of development in better environments.

A couple years later I started using Lightspeed/THINK C. No NEAR/FAR pointers thankfully. I avoided Intel stupidity for many years.

C really hasn't changed very much. The biggest change has been function prototypes. POSIX and ANSI certainly helped, especially with esoteric details of things like real-time and multi-threading/multi-processing, but that didn't enable much, just made it more portable. There are still plenty of incompatibilities despite all of that standardization (e.g. autoconf).

C++ as on object model was there. It was a poor model, and it still is. There are a lot more features now, but a lot of the "extra complexity" that modern hardware enables is spent dealing with the extra complexity C++ adds. I never used it, but maybe the world would be in a better place if THINK Object Pascal had caught on more.

CVS started out as shell scripts working with RCS. There were also plenty of other revision systems that had been around for a long time (eg NOS MODIFY). It's not that the concepts were unknown, just that the hardware simply didn't have the capacity and speed, and networking it all together was much slower and less available.

Thank you!

[Anonymous Coward]

Is there any reason why anyone would want to use Rust when they're already proficient in both C++ and Ada?

You'd think that Ada is already covering most if not everything what Rust is trying to cover here, especially the memory safety and concurrency aspects.

As I was looking at this, I was just wondering that if there are all these educated computers scientists doing these projects, how about having a new programming paradigm or even revisit something tried before that didn't work out well; like graphical programming?

These new languages that are coming out really aren't new. It's just a change in syntax and some compile or runtime features. Computer languages have been pretty stagnant for 30 years now and I haven't seen anything new in languages since OOP came to be.

Re: Thank you!

[Anonymous Coward]

I recommend taking a look at "factor" and "idris"

Re:Thank you!

[Anonymous Coward]

It's just a change in syntax and some compile or runtime features

Isn't that all a programming language is, syntax, compile features and runtime features?

Re:Thank you!

[drewm19801927]

The main hot newness in Rust is the borrow checker. It is the source of Rusts most notable strengh and also it's most notable weakness, but you won't see it at all if you just look at a code example online, or download an already-working code example. It's also interesting since it's the first language to really target the remaining C/C++ strongholds in a long time, and it does have an interesting mix of good ideas from other languages. As for graphical programming, I would have said that all the clicking (and not version controlling) puts an upper limit on program complexity, but who knows... people have designed some darn complex stuff in Minecraft; if someone designed a visual programming language for people with that temperament maybe they ~could write something like an operating system by clicking and dragging (and shoveling?).

Really

[Anonymous Coward]

Vala, Scala, Go, Python, Wolfgram they all purport to do something better, why all the god dam languages for fuck sake. Take a chill pill and stop making langugaes because you want them made here. Use the existing like 50 million languages already made and ready for production work. This language overload is fucking stupid, and you could contribute to an existing language and make it better rather than waste time on you fucking pet fucking shit language of the month project. You are all cunts.

Re:Really

[spauldo]

Did you get lost on your way to 4chan, little boy?

Pipe down, the adults are talking.

Re: Really

[Anonymous Coward]

indeed. what is the point of petrol carriages when we have these fine horses as companions and workers.

kaiser wilhelm of germany

Re:Really

[Bent Spoke]

Despite the colourful rhetoric, the point is well taken. How many spoken languages does the average person know? Yet when it comes to programming, we are all supposed to learn a new languages every week. This is one of the rationales behind JSI, a JavaScript Interpreter (http://jsish.org). ie. when it comes to web development, you should only ever need to know two languages C and javascript.

Re: Really

[Anonymous Coward]

I can do anything I want to with PHP. #notacunt

Re:Really

[shoor]

How many spoken languages does the average person know? Yet when it comes to programming, we are all supposed to learn a new languages every week.

Well, Rust is supposed to be a new Systems Language, not a language for the average person but something for Systems Programmers. I was a Systems Programmer back in the 1980s using C and various assembly languages, so maybe I'm biased, but I do think Systems Programming is kinda important. C was a big improvement in productivity over assembler not only because it was portable but also because it took fewer lines of code to write something and was therefore easier to read and somewhat less likely to have bugs (though it certainly had warts, how many times has somebody written "if (a = b)" when they meant "if (a == b)"? Bugs in systems programming can be very expensive in the commercial world, expensive to track down and fix, and expensive in the damage they do when they manifest themselves in a commercial environment, so it's worth a lot of money to come up with something that is a viable systems language (it gives precise control over the underlying hardware), is productive (You can write a program that does what you want in fewer lines of code and the code is readable by a human), and that is less likely to have quirks that lead to bugs.

Re: Really

[Anonymous Coward]

thanks for your comment. i would like to add unisys and hp used pascal and algol for os coding.

the portable assembler c is not the only option.

Re: Really

[CraigCruden]

And it went so well that these operating systems are still around today.... BTW which operating systems are we talking about?

Re:Really

[HiThere]

Snobol, Rascal, Mortran, Lisp, Fortran, Cobol, ... there's lots more. Some will succeed. Some will find niche applications. Some will disappear. (But Cobol is still around...though fading.)

You're just noticing the tip of the iceberg of current languages. There are more now than ever before because communication has gotten a lot easier, and because there are more programmers. But your current favorite language will someday be forgotten.

MIX, Icon, Icebol....

Re: Really

[shoor]

the portable assembler c is not the only option.

Glad to hear it.
I never had the honor of working at unisys or hp; 'the portable assembler c' is the only thing besides assembler itself that anybody was ever willing to pay to code in, but I know other languages were used for things, even Forth in embedded systems I think. (Shoot, even Basic got used in embedded systems didn't it?) I also vaguely remember hearing stories about Burroughs doing something with higher level languages, but for me those are anecdotes. Are there any old timers with real experience in any of that stuff willing to comment?

I needed to call the sleep function

[Anonymous Coward]

I couldn't find it in the online doc, then someone on stackoverflow informed me that "Rust Never Sleeps".

i was going to celebrate...

[indy_Muad'Dib]

rust finally going into beta but then some naked smashed my head in with a rock and stole my bow.

hey look another new programming language

[Anonymous Coward]

I don't give. a. fuck.

Automatic Reference Counting better...

[CraigCruden]

The end result is not going to "fragment" memory, it is about when and how memory management is done. Unfortunately for the sake of allowing programmers not to know what they are doing or what is going on they implemented garbage collection in object oriented languages like Java, which is generally fine in server applications that run in a VM.... but it has a cost to doing that. A better compromise (IMHO) is "Automatic Reference Counting" which is done at compile time and does not have to be programmed cluttering up your application..... BUT you have to be aware of memory management (which is a good thing for programmers to have to know) and not program cylindrical references where both references are strong. Best of both worlds (for the most part) without the unpredictable and resource "hungry" garbage collection running in the background. The side benefit is that you have C/C++ efficient code that can be compiled down to the machine level and not run in a vm

There are generally three options available:

Manual Memory Management:
- Cons:
1. Pain to code having to write code that does memory management and just adds extra bulk to a program
2. Easy to make simple mistakes that cause the system to crash or become unstable
- Benefits:
1. Instantly freed objects
2. Predictable behavour
3. Smooth Performance

Garbage Collection:
- Cons:
1. Garbage builds up
2. Nondeterministic
3. Performance stutters
4. Extra CPU cycles taken to have a process run in the background kicking in (drains battery on portable devices).

Benefits:
1. Development Ease
2. Don't have to understand Memory Management
3. Reduces Crashes

Automatic Reference Counting:
Cons:
1. Have to be aware of memory management and not program cylindrical references where both are strong references (actually have to understand what you are doing).
Benefits:
2. All of the Benefits AND Cons from the other two memory management schemes
3. "garbage" collection / memory management is inserted at compile time and is not a background thread running on your device.

Re:Automatic Reference Counting better...

[Nubbywubwub]

Alternatively, given the topic of this thread, you can take the Rust way, which gives you the benefits of manual memory management with the non-crashiness of GC, without imposing the refcount-bumping overhead of ARC (which isn't a lot, but it's non-zero). Not to knock Swift, which I actually think is maybe the best application programming language emerging today. If only it were open-source and cross-platform...

Re:Automatic Reference Counting better...

[CraigCruden]

Swift is a nice language, I get the feeling the creator/driving force behind it wants it open-source cross platform -- but no commitment yet (and likely will not be for years until it has completely matured). The only issue I have with Swift is that it does not fully embrace functional programming and is really an object-oriented programming language at heart (with some functional niceties) .... but then the language is designed for UI development and the UIs themselves are object-oriented.

I would really like some entity to get behind making an LLVM version of Scala -- or close to it (which would dump the JVM and of course the expectation of JVM garbage-collection).

Re:Automatic Reference Counting better...

[HiThere]

I was counting automatic reference counting as a form of garbage collection. And it does have some tradeoffs, but, IIUC, the loops of links problem is subject ot automatic handling. What you *can't* allow is casting between pointers and non-pointers. To me this seems like a minor limitation, and one that should probably be implemented anyway. (With, of course, some escape hole around the prohibition for those that really need to and really, really, know what they're doing.)

OTOH, be aware that Python used to use reference counting and finally decided that it was an inferior approach. It's a different target group of programs and programmers, but still...best to understand WHY they decided it was an inferior approach.

FWIW, having *some* form of garbage collection helps termendously when manipulating variable length strings and arrays.

Re:Automatic Reference Counting better...

[CraigCruden]

There is a vast difference between an interpreted language such as Python and a low level compiled language when you are talking about "reference counting". With a language such as Python it is really still garbage collection.

With a compiled language on the LLVM (high level transportable assembly language which in turn is turned into machine code) it is not actually a thread running garbage collection in the background it is the Clang/LLVM compiler inserting "free" memory calls used as it goes out of scope. This is of course a little simplified, but there is a difference.

Apple had garbage collection (optional) for use in objective-C up until they started releasing iDevices where it becomes a zero-sum game when it comes to inefficiency. When you are talking about a computer plugged into the wall -- you won't notice if an application is consuming n% more energy or not. When you have a finite amount of battery power, it becomes noticeable (especially for the iDevices, but it has had a knock on effect with laptops). Apple has worked hard both in the core operating system on how it implements cpu cycles through it's scheduling to save energy on laptops and in the application development platform itself to squeeze just a little more out of the battery which allows the battery to be smaller or the amount of time the system can operate on battery.

When java and smalltalk were created, a garbage collector solved more problems than it created since no one worried about efficiency.... but platforms have changed since that time and efficiency has to enter the equation.

Re:Automatic Reference Counting better...

[Anonymous Coward]

Scala isn't a functional programming language at heart either. It's every bit as object oriented as Swift. If you want to push functional programming, at least pick a language that isn't a complete trainwreck. Even Odersky admits that Scala is a disaster.

Re:Automatic Reference Counting better...

[CraigCruden]

It is functional at it's core but not purely functional. I could write purely functional code inside Scala, it is more difficult with Swift. Simple things like flow control in Swift is just that.... flow control.... not functions. if in Scala is a ternary function - similar to java ternary if - but more verbose. Switch - same. On things like optional values - I do not have access to map them to something else, I have to unwrap them using "if let" flow control structure. Swift could easily add most of these in effectively make Scala redundant, but as the designer of the language said.... it is not a priority at this time (aka don't count on it).

Yes, Scala is every bit object-oriented as Swift (actually more so since everything in Scala is an object, while in Swift the same cannot be said). I have NEVER heard Odersky admit Scala is a disaster. He has said that it needs a fundamental rethink as in make it simpler and moving things from core to non-core etc. All languages need that though. Java could really really use a rethink at it's core as well.... any aging language can. There are areas (edge cases) in Scala that are problematic. The compiling of the language is really slow. And of course the manufacture of the jvm has determined that they want to become a malware distributor....

What I am looking for is something along the lines of Scalas object-oriented / functional language balance in an LLVM based compiler -- that is cross-platform/open. Swift could easily get close enough if they wanted to. Scala can get there as long as they don't require exact language compatibility between the jvm version and an llvm offshoot.

Re:Automatic Reference Counting better...

[HiThere]

Your description of the particular technique used by the LLVM doesn't mean that this is the only approach. And in my opinion the garbage collector, of whatever nature, including reference counting, should run in a separate thread. Whether it's reasonable for a battery powered device I don't know. Clearly it means extra processing, but it also can mean less disk activity. I suspect that Apple has put much more thought into this than I ever would, but I also suspect that they were considering making things ROMable, and using the same code in both conditions would be an obvious win.

That said, I *do* think that it's quite reasonable to have a garbage collector be either or both of a program switch (changeable at run time) or a compiler switch, allowing optimization with garbage collector removed. I haven't, however, seen a language that supports this well. Many enable temporary disabling of the garbage collector, but few (if any) allow the compiler level switch. This is because, e.g., it does bad things to the handling of variable arrays. (C++ has proved you can do it anyway, of course. But my belief is that they are using refrence counted garbage collection, in this case probably "smart pointers". Which I count as garbage collection.)

Re:Automatic Reference Counting better...

[Anonymous Coward]

Have you ever heard of a programming language called Rust? You know, the programming language that this whole thread is about. It uses a fourth option. You should check it out.

Get me rewrite !!

[Anonymous Coward]

quote from the programming page
Rust's pointers are one of its more unique and compelling features.

Rust looks like an exciting addition...

[CraigCruden]

I spent the last 45 minutes watching an introductory video on Rust and I believe it is a new exciting language that is badly needed. Yes there is a lot of language competitors out there, but most of those languages are higher level than C / C++. C / C++ have had very little competition in their end of the language spectrum. They are old, not very safe. Rust on the other hand is type/memory safe by default -- although you can run "unsafe" code within there by explicitly stating so and then the compiler relaxes the checking a bit (a reasonable compromise). Most people will not need much if any "unsafe" code to be performant.

The fact that there is another LLVM, cross platform compiler is also a plus for me.

That said, I don't write much C / C++ code because nothing I am writing needs it -- but those languages are still necessary (and very popular) so coming up with a newer competitor (not 40+ year old language)..... is great.... and exciting.

That's some progress

[Anonymous Coward]

It just goes to show ... Rust never sleeps.

no one writes large enterprise systems in Java?

[kervin]

You must be a Java programmer. Garbage collection is generally a very bad idea for a systems language, because of the periodic stalls whilst it does the cleanup

Respectfully, you really need to research this if you believe that is the cause. Java is the enterprise systems language to beat today. And its Garbage collector does a fine job if you understand how it operates, just as with most other mature garbage collected runtimes.

Re:no one writes large enterprise systems in Java?

[BasilBrush]

You don't know what you are talking about. Enterprise systems are the very opposite of systems software. Systems languages are for writing kernels, drivers etc.

Re:no one writes large enterprise systems in Java?

[kervin]

Please read up on Utility Software, which has a very sizable list of examples written in Java. Personally, we have a list of utility software on the market written in Java.

Re:no one writes large enterprise systems in Java?

[BasilBrush]

I don't ned to read up on what I've been working with and occasionally on for 30 years.

Utilities are part UI and part drivers for the various hardware or OD level tasks they do. The UI might be OK to be written in Java. The drivers (which are the systems software part) will rarely, if ever be Java.