I've never met with (large) stack traces in Scala because throwing exceptions is NOT ok in Scala. But can you share your experience?

So you're not supposed to tell people where errors occur in Scala? Is that like Inigo Montoya fighting with his left hand, because otherwise it's too easy?

> So you're not supposed to tell people where errors occur in Scala?

You're supposed to use the types `Option` and `Either` or if you're into scalaz then \/ (http://eed3si9n.com/learning-scalaz/Either.html) and Validation (http://eed3si9n.com/learning-scalaz/Validation.html). Throwing exceptions is a childish way to handle errors in FP.

I don't see why anyone would find this superior to a stack trace.

> KDE is the only environment that can match in terms of tooling and UX, yet it is lacking some serious love nowadays.

KDE? Seriously? It's one of the worst DEs on linux. Any DE which isn't based on gnome is just cheap nowadays.

>Seriously? It's one of the worst DEs on linux. Any DE which isn't based on gnome is just cheap nowadays.

I'll take your hot opinion and replace it with mine: Gnome (3) is hands down the worst DE in the entire Linux ecosystem and is actively harming all others by merely existing due to the mentality driving its development: "fuck everyone that's not us, we set the standards and you will like them".

Currently KDE is the most polished and feature complete of the "batteries included" DEs. And even then as a developer I prefer a bare-bones tiling set-up, picking and choosing what I want and having an experience customized to my preferred workflow.

So which other DE on GNU/Linux does provide the same tooling and platform abstractions as KDevelop/Qt Creator do?

GNOME has a very nice HIG from UX point of view, but it is stuck in C + POSIX as technology stack in what concerns developer experience. Vala is still not there and I don't believe in JavaScript for native UIs.

> So which other DE on GNU/Linux does provide the same tooling and platform abstractions as KDevelop/Qt Creator do?

Same or similar? It doesn't matter what they provide because I'd go with ScalaFX(http://www.scalafx.org/) + IntelliJ or Vala|Genie + Vala IDE. Mono is also an option if you're into it.

> but it is stuck in C + POSIX as technology stack in what concerns developer experience.

Yes, GTK isn't the newest but it isn't hard at all to develop apps with Vala/Genie(https://wiki.gnome.org/Projects/Vala/GTKSample , https://wiki.gnome.org/Projects/Genie/GtkGuiTutorial ?)

> Vala is still not there and I don't believe in JavaScript for native UIs.

What do you mean? Vala is almost the defacto standard language for ubuntu/gnome apps.

ScalaFX(http://www.scalafx.org/) + IntelliJ and Mono are not exposing any GNU/Linux specific feature.

I can use the same toolchain in many other operating systems.

The last time I bothered to check GNOME, there was some ongoing discussion of JavaScript becoming the official language to pair with C.

Just checked Genie and Vala IDE web sites, they still need to do catch up with what Borland was doing in the 90's, let alone modern IDEs.

> You wanted to develop desktop apps, not gnome plugins, right?

Desktop apps that expose the features that make the platform unique.

> If you want RAD there's Glade(https://glade.gnome.org/) + GtkBuilder.

Not even close to Delphi and C++ Builder and we are talking about 90's here.

If I upgame to Blend + VS, XCode + Playgrounds, Android Studio then there is a lot of catch up to do.

@woflgke you're going off on a tangent: it's about the maturity of tools and not about "exposing" system features. That's unrelated to desktop apps.

No @woflgke is quite right.

Software development stack for desktop apps are all about exposing the features that make a platform desired to be used.

pjmlp asked:

> So which other DE on GNU/Linux does provide the same tooling and platform abstractions as KDevelop/Qt Creator do?

You answered:

> Why would you need specific features? You wanted to develop desktop apps, not gnome plugins, right?

Clearly KDevelop and At Creator expose GNU/Linux specific feature.

> No garbage collection, so no GC performance hiccups.

Swift has ARC(https://en.wikipedia.org/wiki/Automatic_Reference_Counting) which is a GC strategy. And I don't think it can compete with the performance of the JVM's G1 (currently).

> I wonder whether Java will get displaced by Swift on the server at some point. Anyone want to place bets?

I'd bet on Scala(http://scala-lang.org/) which has far more benefits compared to Swift - OOP+FP, higher kinds, typeclasses, implicits, (hygienic) macros etc. dotty(https://github.com/lampepfl/dotty) will have union- and intersection types with other useful stuff. There is a JS backend(https://www.scala-js.org/) and there'll be an LLVM(https://github.com/scala-native/scala-native) backend too.

Just to be clear: reference counting isn't a garbage collection strategy. It is, however, an automatic memory management strategy.

Reference counting is a form of garbage collection.

[1] https://news.ycombinator.com/item?id=11659863#up_11662144

[2] https://en.wikipedia.org/wiki/Reference_counting#Use_in_garb...

[3] https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf

Look at here: https://www.scala-js.org/

"The generated JavaScript is both fast and small, starting from 45kB gzipped for a full application." - 45kB... jQuery is ~80kB.

jQuery gzipped and minified is 25kb. You're comparing raw to compressed.

"Loading... The website doesn't respond. Do you want to restart?"

> This comment is patronizing and implies that liking Go makes someone a "junior varsity" programmer, or ignorant of alternative programming models.

Because that's the truth and that was intentional at its design.

> I'm well-versed in half a dozen other languages, many of which include generics.

It depends in which languages.

I disagree, my point remains that many people have different preferences than you in what they want from an OS, and many people do legitimately prefer Windows over OS X (or linux, but most people don't really know that's an option.)

No, it's OS X. For example - go and open any window from a "menu bar application" such as BetterTouchTool's settings window.

Now try switching to that window with they keyboard in OS X, without using any 3rd party helpers like HyperSwitch.

You can't do it.

Also try running 2 instances of the same app in OS X. You also can't do that.

OS X is garbage compared to Windows.

> Elixir's novelty, the pipe operator, is a fantastic approach to working with state in a functional manner. Instead of running readlines(fopen(user_input(), "r")).uppercase().split(), try the more readable user_input |> fopen("r") |> readlines |> uppercase |> split.

The pipe operator isn't Elixir's "novelty". Also, why is it better than the '.' syntax:

> fromFile(userInput).getLines.map(_.toUpperCase)

Do you get code completion for it as in an oop-ish language?

    A |> B |> C second_param

Is the same as:

    C(B(A()), second_param)

It's much more powerful than that because you can create chains of functions that pipe their output i.e.

   Some_data
   |> fetch_reports
   |> email_users
   |> setup_notifications
   |> IO.inspect
   |> affirm_elixir_pipes

It's 100% not the same as dot or arrow! IO.inspect allows you to print details of any data being passed but also returns the first argument passed.

Hope this is a clear explanation of what is happening.

> Shouldn't they support c an c++ over rust ?Shouldn't they support c#, coffeescript and go before scala or ruby ?

c/c++ are legacy. c# is an m$ thing, coffeescript and go are beginner languages. scala and ruby are used in production.

> All the latter programming languager are more mature, more used than the supported languages.

I wouldn't call c#/coffeescript/go more "mature" than scala. And popularism is unrelated to the topic.

String literals in Rust produce references to data living in static memory. The `String` type, which is dynamically-allocated and growable, is only created when requested due to the cost of dynamic allocation.

So, do you need to convert the string to a string whenever you want to use a mutable string?

If you have a string slice (&str) you need to convert it to a String you own before you can mutate it, yes. In some other languages strings are always immutable, and mutating them requires creating a copy. In Rust if you own the memory (and haven't given out any immutable references to anyone), you can mutate it.

String literals are an interesting case for the reason mentioned in the earlier comment: they reference memory that no code "owns", as in-place mutation of the executable would be unsafe.

Some languages have mutable strings but these are usually unsafe if used concurrently, or require locks. In Rust this is modeled in the type/borrow system.

> In some other languages strings are always immutable, and mutating them requires creating a copy.

Those languages used to introduce mutable wrappers and not a "to_string()" method.

> they reference memory that no code "owns", as in-place mutation of the executable would be unsafe.

Is that similar to the dynamics of uniqueness types?

> Those languages used to introduce mutable wrappers and not a "to_string()" method.

Yes! This is similar to, say, StringBuilder in Java. The difference is that ownership is intertwined with the type here. Strings are always owned, and as such you can choose to mutate them. String slices (references) are not owned by you (you borrow them), so you can't do anything that would be memory unsafe. You can borrow a mutable slice of the String (like a reference to the backing array), which you can alter in-place but you cannot do anything that would require reallocation (Strings being growable was mentioned earlier -- mutable slices are not). Slices which come from string literals are always immutable.

For probably-obvious reasons you can only take one mutable reference at once, while you can have as many immutable references as you like. Taking a mutable reference also prevents you taking any immutable references at the same time: https://doc.rust-lang.org/book/references-and-borrowing.html...

In my own experience this takes a bit of time to get used to, and in some cases the rules are still quite frustrating. People with more experience of the language report that they get used to it, though.

> Is that similar to the dynamics of uniqueness types?

I believe it's similar, but I'm not super-familiar with uniqueness types. This SO answer looks good: http://stackoverflow.com/questions/26309081/how-do-rusts-own...

TBQH, I do not have the slightest clue why I decided to implement that as a growable String type instead of a literal. Definitely warrants a change.