Environments aside, which one was best designed? Java, Microsoft's Java or Google's Java?

C# and the .NET framework are way better designed than Java.
As a single of many examples, when working with collections in C# I can expect to deal with IEnumerable and (sometimes) IQueryable regardless of the library I'm using. With Java, given how much it took for them to finally implement Streams, I find that many libraries just use their own custom collection types with their own custom methods.
If you add Kotlin into the mix (which is preferable over Java) then you have yet another way of using collections. It may seem a little thing, but the same happens in other parts of the standard library, which kinda brings back memories of dealing with binary data in JS.
And there's also the whole obsession with backwards compatibility, as if software that hasn't been updated since Java 2 will suddenly be upgraded to Java 11 and it will need to be upgraded in such a hurry that it should work as is. It's the same bullshit that plagues PHP.

C#

C# by far.

It's good for embedded hardware. That won't be going anywhere soon and it oaus super well. Your codebases are inherently smaller and less complex, too.

All trash

Best one out of those languages imo, but Java is more popular, so if you want something useful you should learn java.

Lmao.

More like if you're a faggot. Java is AIDS amd only useful for legacy code. Don't build new shit in Java

All shit. But the Wintoddlers on Jow Forums will shill C# for some reason.

Rust

Because it's probably the least obtuse of all the C-like OOP languages.

>Embedded
>C#
Embedded systems only run C and C++ you retard

the compatibility with F# also adds possibilities Java simply can't have

>Embedded systems only run C and C++ you retard
What is .NET Micro Framework?

Attached: dotnetmicro.png (1123x303, 31K)

>300k memory minimum
>nearly all embedded systems have less than 128k memory
kek

there's a lot of languages running on the JMV like clojure, scala and kotlin

Just looked on the ST website, seems you can get ULV MCUs with 640k memory. In any case, you claimed you can ONLY do embedded programming in C/C++, but you're wrong.

I programmed a couple of robots using lua and python

and you wasted all the RAM and flash of your microcontroller in just loading the python and lua interpreters

Presumably user was able to get the robot to do what he wanted though. So who gives a shit?

it raises the bar for the resources a user requires from a microcontroller, hence raising microcontroller costs
i thought Jow Forums was all about the most efficient way of doing things without throwing resources at problems?

C# still needs default interface methods desu
That was a comfy feature of Java

Both of them are fucking garbage.

I use C# when I need windows forms and C++ for everything else. Those are the 2 most based languages.

There's a big difference between "throwing a ton of resources at a problem"
And "using an Interpreted language"

You're just covering your ass because you were wrong and have to find a moral reason that you should have been right.

That's not the point though, you boldly claimed that you can only do embedded programming in C/C++ and that nearly all embedded applications only have 128k of memory.
Well user used python and lua to program a robot that presumably had more than 128k of memory, and I've seen you can easily find an MCU with 640k and that would be more than enough to use C#.

So actually you can use a variety of languages when developing for an embedded system, and you can find a few embedded systems with more than 128k of RAM.

>There's a big difference between "throwing a ton of resources at a problem" and "using an Interpreted language"
No there isn't. Using python instead of C to program a microcontroller because you only know python and not C is you throwing resources at the problem so that you can program in python. You literally throw memory (resources) at the problem (not knowing C).

>you boldly claimed that you can only do embedded programming in C/C++
I amend my claim so that it says "Nearly all embedded systems run on C/C++"

>[you claimed that] nearly all embedded applications only have 128k of memory
>you can find a few embedded systems with more than 128k of RAM
So what? Just because there are a few microcontrollers with a lot of RAM doesn't invalidate my point that nearly all embedded systems are resource constrained. If you go on ebay right now, you have to go out of your way to find high-resource low-cost bare-metal-friendly chips.

I only ever used C# out of the three - the experience was very good.

>I amend my claim
>So what?
Who is the retard now?

>You literally throw memory (resources) at the problem (not knowing C).
The problem the device (the robot) is meant to solve, is presumably teaching people the basics of either programming or embedded system development. Here the ability to use interpreted languages isn't a compromise but is actually a design parameter for the system.

They got into Java as a hack to add the Stream methods into existing collection interfaces but without breaking custom implementations of those interfaces (that wouldn't compile without implementing the Stream methods).
Maybe I'm somewhat dogmatic, but interfaces should be that, interfaces without implementations.
Abstract classes are a nice alternative to default interface methods, but you can't extend from more than one abstract class (haven't needed to do so ever; I don't like complex class hierarchies).

>>I amend my claim
>>So what?
>Who is the retard now?
I do not understand the connection between those two statements. They do not come from the same context, nor do they contradict each other. What is the mistake I've made?

>The problem the device (the robot) is meant to solve, is presumably teaching people the basics of either programming or embedded system development.
>presumably
Neither I nor you know whether the person writing for the robot was writing for an end-goal product or for learning purposes, therefore, we both have to keep our mouths shut since we do not have enough information to further continue this discussion in the direction that it needs to go in.

C# and Java are very corporate languages. They are designed by committee, and typically show feature bloat (C# more than Java, since they have to sell you a new Visual studio license every 2-3 years they keep adding shit almost nobody will use in the real world). I wouldn't use any of them for personal or open source projects. They are just not fun to use and will make you hate programming and life.

> do not understand the connection between those two statements.
They both imply you concede that your initial statements were fallacies.
>we both have to keep our mouths shut since we do not have enough information to further continue this discussion in the direction that it needs to go in.
Oh now you're conscious about not having enough information to have an opinion? You should have kept your mouth shut in the first place.

>They both imply you concede that your initial statements were fallacies.
The first statement (which is "I amend my claim") does imply that the very first post was a fallacy, which is true. I was wrong.

The second statement (which is "So what?") does not imply that the relevant post was a fallacy. This is because I stated something true ("nearly all embedded systems have less than 128k memory"), and then you stated something irrelevant ("seems you can get ULV MCUs with 640k memory"). What does the reply have to do with my original statement? I say that most MCUs have less than 128k of memory, and you come in and say that there are some by ST that have 640k of memory. That is an irrelevant rebuttal to what I said, which is why I replied by saying "So what?". It's not proof that my original premise was false.

>Oh now you're conscious about not having enough information to have an opinion? You should have kept your mouth shut in the first place.
Doesn't this apply to you as well? You assumed that the person was learning about embedded ("presumably teaching people the basics of either programming or embedded system development"), without having the relevant evidence to support it.

the fuck are you going on about the board has favored functional programming over "muh efficient because pointers" since its creation

>almost nobody will use in the real world

I'm using c# 6 and 7 features so frequently I internally groan when I have to go on the projects that don't use higher than c#5.

Value tuples, null coalescing operator, out var all have been great in prettifying some aspects of my code. And I'm even looking forward to async enumerators which would be useful in the writing of some database seeders

>which is true. I was wrong.
And that's all that really needs to be said.
>It's not proof that my original premise was false.
You're falling back on technicalities with your wording, but you absolutely intended to imply that MCUs with more than 128k of RAM are so few in number they're an irrelevance. Which again, is wrong.
>Doesn't this apply to you as well?
I didn't start calling people retards after making a statement that was clearly wrong.
> without having the relevant evidence to support it.
That's why I said "presumably" and took an educated guess, instead of saying something like "obviously he was using a robot learning kit you fucking retard" with the same level of certainty as this post

Rust isn't anything like Java you retard.

Visual studio is free, you don't need it to program in C# either.
C# has been following F#'s trail for some time, thanks to the CLR it's fairly easy to implement features from a language into the other. This means C# is getting a lot love like pattern matching.

java to unlock clojure. lisps are the most powerful programming languages

unemployed noobs learning C# are shilling C# on this website for some reason.

Companies, which are the client that matters for MS, don't use the free version user. Mainly because legally the free version can't be used for commercial software.

this. .NET Core threads are even worse.

unemployed LARPers learning ANSI C are shilling LISP on this website for obvious reasons.

Attached: richard-stallman[1].jpg (1200x1200, 223K)

It can if your company has 5 or fewer developers =)

T. Man working at company that just hired it's sixth dev

Are you not a programmer?

>namefig
I still agree with this post. 7.x features came at the right time for me and holy shit do they kick ass.

Java with Guava library

C# is for fags who don't want a job

tfw when working in a 4 man team

Java for jobs + better performance

>Trying to get a job with Java when literally every university graduate has it on their CV

Nobody cares about those shitty poorfag "companies".

this. I'd shill for microsoft though, fuck java,

This is retarded on so many levels.
First of all everyone knows that universities only teach basic Java. Worse, they teach stone age versions of Java. Undergrads usually don't know shit about Java 8+ features, Spring, RxJava etc. Second of all, Java is still running everywhere. You''ll have trouble finding any big enterprise that doesn't rely on Java.

this
C# is the comfiest

>but you absolutely intended to imply that MCUs with more than 128k of RAM are so few in number they're an irrelevance.
Not really. You can't just say "you implied this because I said so!" and expect it to hold water

design is literally that brainlet

My enjoyment of C# is actually doubled by the amount of MS related seething you evil-MS era boomers spit out. It's not the same company anymore, grow up.

I can when you leave this post that open ended. If you don't want your posts to be interpreted, try using the power of language to be more concise.

"nearly all embedded systems have less than 128k memory" =/= "MCUs with more than 128k of RAM are so few in number they're an irrelevance"

>It's not the same company anymore
used to be a company one could do business with, now it's windows as service and please do the needful

Ah so what did "kek" mean in this context? Why was 300k kekable if you felt that there are relevant numbers of MCUs with that kind of RAM?

>It's not the same company anymore
Yea, it has become 10x worse.

If you care about performance you wouldn't be using Java anyway.

>i thought Jow Forums was all about the most efficient way of doing things
how fucking new are you

Actually you would
Java is the right mix of easy developing, safety and performance

techempower.com/benchmarks/#section=data-r18&hw=ph&test=query

Sir, please fuck off.

>gets btfo
>gets personal
lmfao poo.NET shill

Java because of the JVM and all the libs frameworks and laguages.

C# because more 'modern', 'coherent', and 100% interop with an actually good language (F#)

Drart is for lazy UI devs that are expecting flutter to take over everything. I honestly hope sharing kotlin commons wins that battle. Big frameworks that work ecerwhere like flutter and electron are a big cancer.

he's obviously a web developer

128k is still cheaper.
So using an intrepeter is wasting €.
If it's a divice that you plan to make millions, the hardware costs might be harder than the time using python/C# saves you.

>with an actually good language (F#)
implying Scala isn't better

Only fine tuned non-garbage collected code can beat JVM JIT.
Performance is about removing bottlenecks, you don't need everthing to be micromanaged. Only few things in a system will make you have the need to manage memory.

I'm a software engineer for a large defense contractor (you know them).
We use Java on a lot of our embedded devices.
Some use C#, some use C/C++, some use a mixture.

It depends on what the requirements are.

It's a mess, made worse by comunity split inside scala (fp vs oofp vs java++) and outside.
It doesn't know what it is supposed to be and it doesn't interact that well with the base language and libraries. Which isolates scala from the rest of the jvm ecosystem. Then it can be easily bad managed like C++ without a team standard/allowed subset. You would have different commiters commiting different 'scala ways'. Making codebases a mess.

F# is ML-like. Which makes it better for everthing FP. And it actually deals well with C#.

Based.

>Only fine tuned non-garbage collected code can beat JVM JIT.
this. The JVM already does a tremendous job out of the box but there are even different gc's which can be configured for specific use cases.
If you care about Java interoperability (even though I have never had any problems in this regard with Scala) you can use Kotlin as well.

It's more efficient in terms of human resources and time.

Yes.
At the end of the day you need to take everything into account. The price of making a device is not only the hardware but also making the software. You have to combine the 2, sometimes it's worth to use more expensive hardware to save time or to hire fewer devs or nore recruiting options.

Kotlin is not as great for FP stuff.
But if you used scala for java++ or a bit of OOFP, kotlin is a great choice.
There is a change comming to help implement typeclasses in kotlin, but I'm afraid kotlin would walk the path of scala and C++ bloat in terns of different approaches, styles, communities. A mess.

>Kotlin is not as great for FP stuff.
and why is that?

Have you seen the Odersky video about Scala 3?
youtube.com/watch?v=U2tjcwSag_0
I believe Dotty will make Scala way less of a mess and actually pleasant to use.
>F# is ML-like.
It's a fairly attractive language, but it lacks ML modules and HKT like in Scala or Haskell. You'd think they'd give you at least one of those.

>ml modules
You can use Accord

lol

>128k is still cheaper.
Irrelevant if the system requires an interpreted language for any reason. Again, my guess is it's one of those programmable robots they sometimes have in schools.